From report at bugs.python.org Thu Sep 1 00:42:41 2011 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Aug 2011 22:42:41 +0000 Subject: [issue12874] Rearrange descriptions of builtin types Message-ID: <1314830561.27.0.909082052318.issue12874@psf.upfronthosting.co.za> New submission from Nick Coghlan : Section 4 of the Standard Library reference currently includes the two following sections (amongst others): 4.6. Sequence Types ? str, bytes, bytearray, list, tuple, range 4.9. memoryview type This is crazy - memoryview, a fairly niche type, gets its own second tier section on the main table of contents, while str, one of the most important types in Python, is tucked away under the generic "Sequence Type" heading? I propose that these sections be rearranged as: 4.6 Sequence Types - list, tuple, range 4.7 Text Types - str 4.8 Binary Data Types - bytes, bytearray, memoryview The Set Types and Mapping Types sections would slide down to sections 4.9 and 4.10 to make room for the two new sections. ---------- assignee: docs at python components: Documentation messages: 143284 nosy: docs at python, ncoghlan priority: normal severity: normal status: open title: Rearrange descriptions of builtin types versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 00:43:02 2011 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Aug 2011 22:43:02 +0000 Subject: [issue12874] Rearrange descriptions of builtin types in the Library reference In-Reply-To: <1314830561.27.0.909082052318.issue12874@psf.upfronthosting.co.za> Message-ID: <1314830582.17.0.801696025562.issue12874@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- title: Rearrange descriptions of builtin types -> Rearrange descriptions of builtin types in the Library reference _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 00:43:21 2011 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Aug 2011 22:43:21 +0000 Subject: [issue12874] Rearrange descriptions of builtin types in the Library reference In-Reply-To: <1314830561.27.0.909082052318.issue12874@psf.upfronthosting.co.za> Message-ID: <1314830601.28.0.214327373665.issue12874@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 00:45:56 2011 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Aug 2011 22:45:56 +0000 Subject: [issue12874] Rearrange descriptions of builtin types in the Library reference In-Reply-To: <1314830561.27.0.909082052318.issue12874@psf.upfronthosting.co.za> Message-ID: <1314830756.34.0.997672310395.issue12874@psf.upfronthosting.co.za> Nick Coghlan added the comment: Better titles for the proposed new sections: 4.7 Text Data - str 4.8 Binary Data - bytes, bytearray, memoryview ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 00:56:32 2011 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 31 Aug 2011 22:56:32 +0000 Subject: [issue12874] Rearrange descriptions of builtin types in the Library reference In-Reply-To: <1314830561.27.0.909082052318.issue12874@psf.upfronthosting.co.za> Message-ID: <1314831392.02.0.135204174688.issue12874@psf.upfronthosting.co.za> Guido van Rossum added the comment: I agree on the subdivision, but I think they should still be grouped together somehow, since these all really *do* share some interfaces: __getitem__ (with slicing), __iter__, __len__, at least; arguably __contains__; probably some others (see collections/abc.py). ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 01:05:35 2011 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 31 Aug 2011 23:05:35 +0000 Subject: [issue12874] Rearrange descriptions of builtin types in the Library reference In-Reply-To: <1314830561.27.0.909082052318.issue12874@psf.upfronthosting.co.za> Message-ID: <1314831935.29.0.869216361793.issue12874@psf.upfronthosting.co.za> Nick Coghlan added the comment: Putting the new sections on tier 2 makes a big difference in discoverability, since that's the lowest level the main ToC page shows. Perhaps just including the phrase "Sequence Type" in the new section titles would provide enough logical grouping? Something like: 4.6 Sequence Types - list, tuple, range 4.7 Text Sequence Type - str 4.8 Binary Data Sequence Types - bytes, bytearray, memoryview ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 01:16:49 2011 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 31 Aug 2011 23:16:49 +0000 Subject: [issue12874] Rearrange descriptions of builtin types in the Library reference In-Reply-To: <1314831935.29.0.869216361793.issue12874@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: That sounds fine. Or list most of them at tier 2: 4.6 Sequence Types - list, tuple, range, str, bytes and friends 4.6.1 Sequence containers - list, tuple, range 4.6.2 Text Sequence Type - str 4.6.3 Binary Data Sequence Types - bytes, bytearray, memoryview Although including range() here feels a bit odd? (It's a much more specialized type -- actually the same can be said for memoryview.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 02:30:47 2011 From: report at bugs.python.org (kais58) Date: Thu, 01 Sep 2011 00:30:47 +0000 Subject: [issue12472] Build failure on IRIX In-Reply-To: <1309555786.28.0.894707521073.issue12472@psf.upfronthosting.co.za> Message-ID: <1314837047.36.0.943059532504.issue12472@psf.upfronthosting.co.za> kais58 added the comment: Apologies for not getting back to you sooner, I discovered some more pressing issues with the machine regarding gcc, I'll try and fix/hack it together as I have found some possible fixes for the headers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 02:58:28 2011 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 01 Sep 2011 00:58:28 +0000 Subject: [issue12874] Rearrange descriptions of builtin types in the Library reference In-Reply-To: <1314830561.27.0.909082052318.issue12874@psf.upfronthosting.co.za> Message-ID: <1314838708.13.0.0598806730673.issue12874@psf.upfronthosting.co.za> Nick Coghlan added the comment: 'Sequence Types - list, tuple, str, bytes, etc' *might* work, but I think part of the problem is that str's brevity is actually a downside in this case. I know I missed it when I was scanning the ToC earlier (I wanted to check if the internal Unicode repr for narrow builds was documented at all - it doesn't appear to be). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 03:09:55 2011 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 01 Sep 2011 01:09:55 +0000 Subject: [issue12874] Rearrange descriptions of builtin types in the Library reference In-Reply-To: <1314838708.13.0.0598806730673.issue12874@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: How about "list, tuple, text and binary strings" ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 03:12:28 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 01 Sep 2011 01:12:28 +0000 Subject: [issue12874] Rearrange descriptions of builtin types in the Library reference In-Reply-To: <1314830561.27.0.909082052318.issue12874@psf.upfronthosting.co.za> Message-ID: <1314839548.74.0.331878917681.issue12874@psf.upfronthosting.co.za> Ezio Melotti added the comment: I believe this is a duplicate of #4966. ---------- nosy: +ezio.melotti resolution: -> duplicate stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 03:40:46 2011 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 01 Sep 2011 01:40:46 +0000 Subject: [issue4966] Improving Lib Doc Sequence Types Section In-Reply-To: <1232149418.64.0.0450574767427.issue4966@psf.upfronthosting.co.za> Message-ID: <1314841246.1.0.887148940176.issue4966@psf.upfronthosting.co.za> Nick Coghlan added the comment: Bringing a suggestion over from #12874, I think it may be worth splitting the current "Sequence Types" section into 3 pieces that all appear in the top level table of contents for the library reference: 4.6 Sequence Types - list, tuple, range 4.7 Text Sequence Type - str 4.8 Binary Data Sequence Types - bytes, bytearray, memoryview ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 04:16:43 2011 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 Sep 2011 02:16:43 +0000 Subject: [issue12720] Expose linux extended filesystem attributes In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4eb0b1819bda by Benjamin Peterson in branch 'default': expose linux extended file system attributes (closes #12720) http://hg.python.org/cpython/rev/4eb0b1819bda ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 06:56:04 2011 From: report at bugs.python.org (David H. Gutteridge) Date: Thu, 01 Sep 2011 04:56:04 +0000 Subject: [issue6676] expat parser throws Memory Error when parsing multiple files In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za> Message-ID: <1314852964.61.0.379247056941.issue6676@psf.upfronthosting.co.za> David H. Gutteridge added the comment: Ned: My proposed wording is: "Note that only one document can be parsed by a given instance; it is not possible to reuse an instance to parse multiple files." To provide more detail, one could also add something like: "The isfinal argument of the Parse() method is intended to allow the parsing of a single file in fragments, not the submission of multiple files." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 06:59:14 2011 From: report at bugs.python.org (Brett Cannon) Date: Thu, 01 Sep 2011 04:59:14 +0000 Subject: [issue6560] socket sendmsg(), recvmsg() methods In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za> Message-ID: <1314853154.44.0.898177723325.issue6560@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon resolution: fixed -> stage: committed/rejected -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 07:01:50 2011 From: report at bugs.python.org (David H. Gutteridge) Date: Thu, 01 Sep 2011 05:01:50 +0000 Subject: [issue12829] pyexpat segmentation fault caused by multiple calls to Parse() In-Reply-To: <1314139504.06.0.542745003135.issue12829@psf.upfronthosting.co.za> Message-ID: <1314853310.0.0.312673515545.issue12829@psf.upfronthosting.co.za> David H. Gutteridge added the comment: Okay. I'd seen the earlier issue, but had submitted this separately because I wasn't sure if it was a security-related bug, whereas the older issue didn't mention anything of the sort. (In retrospect, I could've just added to it...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 07:05:51 2011 From: report at bugs.python.org (Ross Lagerwall) Date: Thu, 01 Sep 2011 05:05:51 +0000 Subject: [issue12494] subprocess: check_output() doesn't close pipes on error In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za> Message-ID: <1314853551.66.0.09710780709.issue12494@psf.upfronthosting.co.za> Ross Lagerwall added the comment: The second patch looks good. Tests? I think it would be better to kill the process than to let it carry on. But, it *probably* shouldn't be applied to 2.7 & 3.2 given that it is a behaviour change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 07:06:59 2011 From: report at bugs.python.org (Brett Cannon) Date: Thu, 01 Sep 2011 05:06:59 +0000 Subject: [issue12837] Patch for issue #12810 removed a valid check on socket ancillary data In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za> Message-ID: <1314853619.31.0.948232518666.issue12837@psf.upfronthosting.co.za> Brett Cannon added the comment: This is now generating a compiler warning under OS X because the older POSIX standard is followed where socklen_t can be unsigned. Attached is a patch to cast msg_controllen to a size big enough to hold either signed 2**31-1 or unsigned 2**32-1 (i.e., long long) to silence the compiler warning. I would check the patch in myself but test_socket is failing under OS X right now so I can't verify I didn't do something extremely stupid with the cast somehow. ---------- nosy: +brett.cannon resolution: fixed -> stage: committed/rejected -> commit review status: closed -> open Added file: http://bugs.python.org/file23080/socket_compiler_warning.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 07:07:01 2011 From: report at bugs.python.org (Meador Inge) Date: Thu, 01 Sep 2011 05:07:01 +0000 Subject: [issue6069] casting error from ctypes array to structure In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za> Message-ID: <1314853621.88.0.0203922033377.issue6069@psf.upfronthosting.co.za> Meador Inge added the comment: Hmmm ... Assuming a native VC++ compiler on an x86 machine running Windows, then it doesn't make sense to validate these test cases in such an environment. All the tests are all big-endian. 'ctypes' can't be expected to behave the same as the native compiler that compiled the Python interpreter for structures of non-native endianities produced by 'ctypes'. That doesn't make sense. The best we can do is document how 'ctypes' does handle non-native endianites on various platforms. FWIW, I did try the first set of tests (http://bugs.python.org/msg88145) with GCC for a 32-bit MIPS ELF target using the following test case: #include struct T { unsigned int x : 31; unsigned int y : 32; }; struct S { unsigned long long x : 31; unsigned long long y : 32; }; int main (int argc, char **argv) { unsigned char buf[8] = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55}; struct T *t = (struct T*)&buf; struct S *s = (struct S*)&buf; printf ("%X, %X\n", t->x, t->y); printf ("%X, %X\n", s->x, s->y); } The test output: Data0 is 0x2AAAAAAA, Data1 is 0x55555555 for uint Data0 is 0x2AAAAAAA, Data1 is 0xAAAAAAAA for ulonglong is correct with respect to that environment. The difference in the first case (uint) and the second case (ulonglong) is that the first is placed into two 4-byte unsigned integer units where as the second is placed into one 8-byte unsigned long long unit. I am slightly confused how issue12528 is going to address this, when there seems to be no bug; only what seems to be a test case problem. I think we should close this issue out. Another issue should be opened to enhance the documentation, though. We should document exactly how 'ctypes' does the structure layout for different endianities on different platforms. Something similar to how VC++ documents this ( http://msdn.microsoft.com/en-us/library/ewwyfdbe(v=vs.71).aspx ). ---------- assignee: theller -> nosy: +meadori -theller _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 07:17:08 2011 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 01 Sep 2011 05:17:08 +0000 Subject: [issue12875] backport re.compile flags default value documentation Message-ID: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za> New submission from Eli Bendersky : In the 2.7 docs, re.compile has this signature: re.compile(pattern[, flags]) >From here it isn't clear what the default value of 'flags' is, to be able to write code like this: re.compile(pattern, re.I if options['ignore_case'] else ) Of course, looking at the source shows immediately that the default flag value is 0 (which is kind-of implied by the flags being a bit-OR of flags, but not mentioned explicitly). I saw that in the latest 3K docs, it is documented properly: re.compile(pattern, flags=0) Naturally this applies to other methods of 're' that take 'flags'. I hope I'm not missing something and this really is just a documentation issue. If no objections arise, I will commit a fix to the docs of 're' in 2.7 ---------- assignee: docs at python components: Documentation messages: 143300 nosy: docs at python, eli.bendersky, ezio.melotti, pitrou priority: normal severity: normal status: open title: backport re.compile flags default value documentation versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 07:24:31 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 01 Sep 2011 05:24:31 +0000 Subject: [issue12875] backport re.compile flags default value documentation In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za> Message-ID: <1314854671.76.0.585244152204.issue12875@psf.upfronthosting.co.za> Ezio Melotti added the comment: I don't think you are missing anything, but using ints instead of flags is discouraged (see #11957). OTOH there's no re.NOFLAGS flag that can be used instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 07:34:12 2011 From: report at bugs.python.org (Remi Pointel) Date: Thu, 01 Sep 2011 05:34:12 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za> Message-ID: <1314855252.72.0.757975285253.issue12868@psf.upfronthosting.co.za> Remi Pointel added the comment: Hi, without-threads, it segfault: $ ./python -c "import faulthandler; faulthandler.enable(); faulthandler._stack_overflow()"; echo $? Fatal Python error: Segmentation fault Current thread 0x0000000000000000: File "", line 1 in zsh: segmentation fault (core dumped) ./python -c 139 Thanks, Remi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 07:39:49 2011 From: report at bugs.python.org (Remi Pointel) Date: Thu, 01 Sep 2011 05:39:49 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za> Message-ID: <1314855589.6.0.824508276697.issue12868@psf.upfronthosting.co.za> Remi Pointel added the comment: However, if I run test_faulthandler.py, it seems to be ok: $ ./python Lib/test/test_faulthandler.py test_disable (__main__.FaultHandlerTests) ... ok test_dump_traceback (__main__.FaultHandlerTests) ... ok test_dump_traceback_file (__main__.FaultHandlerTests) ... ok test_dump_traceback_threads (__main__.FaultHandlerTests) ... skipped 'need threads' test_dump_traceback_threads_file (__main__.FaultHandlerTests) ... skipped 'need threads' test_dump_tracebacks_later (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()' test_dump_tracebacks_later_cancel (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()' test_dump_tracebacks_later_file (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()' test_dump_tracebacks_later_repeat (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()' test_dump_tracebacks_later_twice (__main__.FaultHandlerTests) ... skipped 'need faulthandler.dump_tracebacks_later()' test_enable_file (__main__.FaultHandlerTests) ... ok test_enable_single_thread (__main__.FaultHandlerTests) ... ok test_fatal_error (__main__.FaultHandlerTests) ... ok test_gil_released (__main__.FaultHandlerTests) ... ok test_is_enabled (__main__.FaultHandlerTests) ... ok test_read_null (__main__.FaultHandlerTests) ... ok test_register (__main__.FaultHandlerTests) ... ok test_register_chain (__main__.FaultHandlerTests) ... ok test_register_file (__main__.FaultHandlerTests) ... ok test_register_threads (__main__.FaultHandlerTests) ... ok test_sigabrt (__main__.FaultHandlerTests) ... ok test_sigbus (__main__.FaultHandlerTests) ... ok test_sigfpe (__main__.FaultHandlerTests) ... ok test_sigill (__main__.FaultHandlerTests) ... ok test_sigsegv (__main__.FaultHandlerTests) ... ok test_stack_overflow (__main__.FaultHandlerTests) ... ok test_unregister (__main__.FaultHandlerTests) ... ok ---------------------------------------------------------------------- Ran 27 tests in 1.281s OK (skipped=7) Remi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 07:40:30 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 01 Sep 2011 05:40:30 +0000 Subject: [issue12875] backport re.compile flags default value documentation In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za> Message-ID: <1314855630.64.0.612117425136.issue12875@psf.upfronthosting.co.za> Ezio Melotti added the comment: Two more things: 1) Python 2 doc used to use the func(arg[, optional1[, optional2]]) notation, and with Python 3 we switched to func(arg, optional1=default1, optional2=default2). The latter is also used in Python 2 now, and the [] are still there in Python 3 in some places; 2) If you are going to fix it, you can probably backport the fix from py3k with "hg diff Doc/library/re.rst -c 106ee4eb5970"; ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 08:17:12 2011 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 01 Sep 2011 06:17:12 +0000 Subject: [issue12875] backport re.compile flags default value documentation In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za> Message-ID: <1314857832.42.0.429689467144.issue12875@psf.upfronthosting.co.za> Eli Bendersky added the comment: Ezio, "but using ints instead of flags is discouraged (see #11957). OTOH there's no re.NOFLAGS flag that can be used instead." Indeed, there's no re.NOFLAGS, and as I mentioned the 3k docs mention 0 as the default value, thus (in a way) encouraging passing the numeric value. Perhaps re.NOFLAGS should be added (at least in 3.3)? The docs can then be modified to specify it as the default value of 'flags' instead of 0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 08:17:59 2011 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 01 Sep 2011 06:17:59 +0000 Subject: [issue12875] backport re.compile flags default value documentation In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za> Message-ID: <1314857879.21.0.157585017328.issue12875@psf.upfronthosting.co.za> Eli Bendersky added the comment: Regarding backporting 106ee4eb5970 - it's probably a good thing to do but I wouldn't mix it with this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 08:37:47 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 01 Sep 2011 06:37:47 +0000 Subject: [issue12837] Patch for issue #12810 removed a valid check on socket ancillary data In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za> Message-ID: <1314859067.59.0.572218618715.issue12837@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: `long long` is not ANSI, but C99. Anyhow, I'm still not sure this check is necessary, because: 1) I really doubt any modern OS uses a signed socklen_t 2) even if it's the case, I don't see how we could possibly end up with a negative msg_controllen I'm adding Nick and Antoine to the noisy list to know what they think about this... ---------- nosy: +ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 08:45:09 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 01 Sep 2011 06:45:09 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314855252.72.0.757975285253.issue12868@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > without-threads, it segfault: > It's normal :-) _stack_overflow triggers - as it names implies - a stack overflow. However, as you can see in the output, faulthandler is now able to catch the SIGSEGV and display the backtrace (because it set up an alternate stack for the signal handler with sigaltstack). > However, if I run test_faulthandler.py, it seems to be ok: Yes: the test checks that the stack overflow was correctly caught by faulthandler. @Victor: can I commit the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 09:23:12 2011 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 01 Sep 2011 07:23:12 +0000 Subject: [issue12837] Patch for issue #12810 removed a valid check on socket ancillary data In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za> Message-ID: <1314861792.46.0.0483840229563.issue12837@psf.upfronthosting.co.za> Nick Coghlan added the comment: I tend to be fairly paranoid about operating systems doing occasionally bizarre things, so I like having clearly defined behaviour even when the OS does something arguably nuts, but permitted by the relevant standard. Hence I think keeping the check is the right thing to do, which means finding an alternative to silence the compiler warning on Mac OS X (and similar systems). The "right" way is probably a configure check, but that feels like overkill for something minor like this. Brett's patch seems like a reasonable alternative if an appropriate guaranteed-to-be-at-least-64-bits type can be found, but 'long long' isn't a valid cast target for this unless Guido is OK with PEP 7 being modified to include a small number of permitted C99 features. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 10:04:12 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 01 Sep 2011 08:04:12 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1314864252.85.0.599694103576.issue4153@psf.upfronthosting.co.za> Ezio Melotti added the comment: After the recent discussions on python-dev I went through the Unicode howto and fixed a few things, then I found this issue so I'm attaching the patch here. The patch addresses mostly markup issues, but it also removes the usage of 'byte string'. A few more things that should be done: * clarify some more terms (e.g. codepoints, code units, characters, possibly scalar values etc.); * mention the differences between narrow and wide builds, including: - a discussion about the UCS-2/UTF-16 implementation of narrow builds; - something about surrogates and surrogate pairs; - effects of slicing and indexing on narrow builds; - functions/methods that (don't) accept non-BMP chars on narrow builds; * something about Unicode supports in the re module (this probably can wait after the 'regex' inclusion). Also the codecs doc has a section about Unicode and encodings that might be moved to the howto. ---------- assignee: georg.brandl -> resolution: fixed -> stage: -> commit review versions: +Python 3.3 Added file: http://bugs.python.org/file23081/issue4153-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 10:18:20 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 08:18:20 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: Message-ID: <4E5F3FCB.7060101@haypocalc.com> STINNER Victor added the comment: > @Victor: can I commit the patch? I don't like the skip message. It doesn't tell that the problem comes from sigaltstack() and it doesn't contain the issue number. I would expect something like: "Issue #12868: sigaltstack() doesn't work on OpenBSD if Python is compiled with pthread". Do you think that the bug will be fixed in OpenBSD? If yes, we should test the OpenBSD version in the skip. But it looks like OpenBSD thread implementation is very different than operating systems (e.g. threads are run in user space), and I don't expect a new implementation before some months/years... Anyway, skip the test if the right fix for this issue. Python cannot fix kernel/libc bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 10:21:18 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 08:21:18 +0000 Subject: [issue12494] subprocess: check_output() doesn't close pipes on error In-Reply-To: <1314853551.66.0.09710780709.issue12494@psf.upfronthosting.co.za> Message-ID: <4E5F407E.40106@haypocalc.com> STINNER Victor added the comment: > The second patch looks good. Tests? Ok, I will try to write a new patch with tests. > But, it *probably* shouldn't be applied to 2.7& 3.2 given that it is a behaviour change. I consider that this issue is a bug, so it should be fixed in 2.7 and 3.2. I agree that *killing* the process is a behaviour change, but we can just close pipes on error for 2.7 and 3.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 10:49:04 2011 From: report at bugs.python.org (Ross Lagerwall) Date: Thu, 01 Sep 2011 08:49:04 +0000 Subject: [issue12494] subprocess: check_output() doesn't close pipes on error In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za> Message-ID: <1314866944.51.0.167345365834.issue12494@psf.upfronthosting.co.za> Ross Lagerwall added the comment: > I consider that this issue is a bug, so it should be fixed in 2.7 and > 3.2. I agree that *killing* the process is a behaviour change, but we > can just close pipes on error for 2.7 and 3.2. Yeah, that seems right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 11:11:12 2011 From: report at bugs.python.org (Danilo Segan) Date: Thu, 01 Sep 2011 09:11:12 +0000 Subject: [issue8409] gettext should honor $LOCPATH environment variable In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za> Message-ID: <1314868272.36.0.532060153467.issue8409@psf.upfronthosting.co.za> Danilo Segan added the comment: I believe it's invalid. GNU gettext itself doesn't honor the LOCPATH variable, LOCPATH is basically used by GNU libc for pointing to locale data. Even though this also includes LC_MESSAGES, gettext has never used it afaik. If it's not invalid (iow, gettext should use it), it'd first need to be fixed upstream in GNU gettext. FWIW, I've grepped for any occurrence of LOCPATH in upstream gettext git tree and it returned zero results. ---------- nosy: +dsegan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 12:42:21 2011 From: report at bugs.python.org (Wong Wah Meng) Date: Thu, 01 Sep 2011 10:42:21 +0000 Subject: [issue12876] Make Test Error : ImportError: No module named _sha256 Message-ID: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za> New submission from Wong Wah Meng : Hi there, I just build python 2.7.1 on my HP 11.31 Itanium 64 bit machine using gcc. When I finished the build and run "make test". It gives me error as depicted below:- $ ./python Lib/test/regrtest.py -v Traceback (most recent call last): File "Lib/test/regrtest.py", line 157, in import random File "/home/r32813/Build/2.7.1/Python-2.7.1/Lib/random.py", line 49, in import hashlib as _hashlib File "/home/r32813/Build/2.7.1/Python-2.7.1/Lib/hashlib.py", line 136, in globals()[__func_name] = __get_hash(__func_name) File "/home/r32813/Build/2.7.1/Python-2.7.1/Lib/hashlib.py", line 74, in __get_builtin_constructor import _sha256 ImportError: No module named _sha256 This is the server information. $ uname -a HP-UX zmy02hp3 B.11.31 U ia64 3240906838 unlimited-user license Here is other information in the configure.log file. Target: ia64-hp-hpux11.23 Configured with: /tmp/gcc-4.4.3.tar.gz/gcc-4.4.3/configure --host=ia64-hp-hpux11.23 --target=ia64-hp-hpux11.23 --build=ia64-hp-hpux11.23 --prefix=/opt/hp- gcc-4.4.3 --with-gnu-as --without-gnu-ld --enable-threads=posix --enable-languages=c,c++ --with-gmp=/proj/opensrc/be/ia64-hp-hpux11.23 --with-mpfr=/proj/o pensrc/be/ia64-hp-hpux11.23 SED=/usr/bin/sed Thread model: posix ---------- components: Tests messages: 143315 nosy: wah meng priority: normal severity: normal status: open title: Make Test Error : ImportError: No module named _sha256 type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 12:50:44 2011 From: report at bugs.python.org (Steffen Daode Nurpmeso) Date: Thu, 01 Sep 2011 10:50:44 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za> Message-ID: <1314874244.95.0.051945317109.issue12868@psf.upfronthosting.co.za> Steffen Daode Nurpmeso added the comment: Heya. OpenBSD does support 1:1 threads via the RThread library since 2005, thanks to tedu@ and more fantastic guys! It about to be super-stable (one commit in 2011, last "real fix" in april 2010). (There is a techtalk from tedu@ (Ted Unangst) about this library on YouTube, btw.) ---------- nosy: +sdaoden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 12:57:46 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 01 Sep 2011 10:57:46 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1314874666.09.0.257885060123.issue4153@psf.upfronthosting.co.za> Ezio Melotti added the comment: I also left a few comments on rietveld about other things that can be improved. Please reply and comment there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 13:22:15 2011 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 01 Sep 2011 11:22:15 +0000 Subject: [issue12876] Make Test Error : ImportError: No module named _sha256 In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za> Message-ID: <1314876135.39.0.588696690245.issue12876@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Please run the "make" command again. It will list the modules that were skipped and not compiled. Which modules do you see there? Also, which version of OpenSSL is installed? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 13:38:03 2011 From: report at bugs.python.org (Sebastian Wiesner) Date: Thu, 01 Sep 2011 11:38:03 +0000 Subject: [issue12873] 2to3 incorrectly handles multi-line imports from __future__ In-Reply-To: <1314827841.27.0.752701109449.issue12873@psf.upfronthosting.co.za> Message-ID: <1314877083.33.0.335337189479.issue12873@psf.upfronthosting.co.za> Changes by Sebastian Wiesner : ---------- nosy: +lunar _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 13:38:08 2011 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 01 Sep 2011 11:38:08 +0000 Subject: [issue8409] gettext should honor $LOCPATH environment variable In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za> Message-ID: <1314877088.38.0.788696217172.issue8409@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 14:07:49 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 12:07:49 +0000 Subject: [issue12837] Patch for issue #12810 removed a valid check on socket ancillary data In-Reply-To: <1314223005.88.0.145323709249.issue12837@psf.upfronthosting.co.za> Message-ID: <1314878869.14.0.301391190347.issue12837@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If you're casting to a larger signed type, then the semantics change, since there is a sign extension. For example (unsigned int) 0xFFFFFFFF could be cast to (long long) -1. You could cast to size_t instead and compare the result to SOCKLEN_T_MAX (which currently doesn't exist :-)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 14:22:19 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 12:22:19 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314874244.95.0.051945317109.issue12868@psf.upfronthosting.co.za> Message-ID: <4E5F78F8.5010507@haypocalc.com> STINNER Victor added the comment: > OpenBSD does support 1:1 threads via the RThread library > since 2005, thanks to tedu@ and more fantastic guys! > It about to be super-stable (one commit in 2011, last "real > fix" in april 2010). > (There is a techtalk from tedu@ (Ted Unangst) about this library > on YouTube, btw.) Does Python support the RThread library? If not, is it planned? Is anyone working on it? In Python 3.3, you can use sys.thread_info to check which threading library is used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 14:35:13 2011 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 01 Sep 2011 12:35:13 +0000 Subject: [issue12386] packaging fails in install_distinfo when writing RESOURCES In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za> Message-ID: <1314880513.71.0.492127086476.issue12386@psf.upfronthosting.co.za> Vinay Sajip added the comment: @?ric: I also noticed that your latest comment "All text is bytes, so we can do all I/O in bytes when writing resources and avoid special-casing." contradicts your earlier position: "I agree about the nonsense of opening in binary mode." If using text mode, we might lose any specific encoding used for the source script unless we do encoding-detection as the interpreter does, and preserve that across the change-shebang-and-save. Using binary does avoid this, and should be doable with simpler code, so perhaps it is preferable - as long as we do it correctly so as to avoid the TypeError :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 15:02:11 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 01 Sep 2011 13:02:11 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: <1314882131.66.0.258351109707.issue2771@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 15:03:53 2011 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 Sep 2011 13:03:53 +0000 Subject: [issue2771] Test issue In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 90586887032e by Ezio Melotti in branch 'default': test: change the content of the p file so http://hg.python.org/test/rev/90586887032e ---------- nosy: +python-dev status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 15:38:33 2011 From: report at bugs.python.org (Jonas H.) Date: Thu, 01 Sep 2011 13:38:33 +0000 Subject: [issue12877] Popen(...).stdout.seek(...) throws "Illegal seek" Message-ID: <1314884313.21.0.764506702479.issue12877@psf.upfronthosting.co.za> New submission from Jonas H. : from subprocess import Popen, PIPE p = Popen(['ls'], stdout=PIPE) p.wait() p.stdout.seek(0) Traceback (most recent call last): File "t.py", line 5, in p.stdout.seek(0) IOError: [Errno 29] Illegal seek Python 2.7.2, Arch Linux x86-64 (Kernel 3.0) ---------- messages: 143323 nosy: jonash priority: normal severity: normal status: open title: Popen(...).stdout.seek(...) throws "Illegal seek" versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 15:44:15 2011 From: report at bugs.python.org (Nadeem Vawda) Date: Thu, 01 Sep 2011 13:44:15 +0000 Subject: [issue12877] Popen(...).stdout.seek(...) throws "Illegal seek" In-Reply-To: <1314884313.21.0.764506702479.issue12877@psf.upfronthosting.co.za> Message-ID: <1314884655.91.0.23452596711.issue12877@psf.upfronthosting.co.za> Nadeem Vawda added the comment: This is expected behaviour - you cannot seek on a pipe. ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 15:44:32 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 13:44:32 +0000 Subject: [issue12877] Popen(...).stdout.seek(...) throws "Illegal seek" In-Reply-To: <1314884313.21.0.764506702479.issue12877@psf.upfronthosting.co.za> Message-ID: <1314884672.74.0.371385937539.issue12877@psf.upfronthosting.co.za> STINNER Victor added the comment: stdout is a PIPE. You cannot seek in a PIPE. Write stdout into a file, or use maybe BytesIO or StringIO? ---------- nosy: +haypo resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 15:48:51 2011 From: report at bugs.python.org (Wong Wah Meng) Date: Thu, 01 Sep 2011 13:48:51 +0000 Subject: [issue12876] Make Test Error : ImportError: No module named _sha256 In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za> Message-ID: <1314884931.63.0.410591534078.issue12876@psf.upfronthosting.co.za> Wong Wah Meng added the comment: Thanks for your reply: This is the output of the make, _ctypes and termios are failed to build. Python build finished, but the necessary bits to build these modules were not found: _bsddb _curses _curses_panel _sqlite3 _ssl _tkinter bsddb185 bz2 gdbm linuxaudiodev ossaudiodev readline spwd sunaudiodev zlib To find the necessary bits, look in setup.py in detect_modules() for the module's name. Failed to build these modules: _ctypes termios running build_scripts $ On version of OpenSSL on this server, I need to check with my Unix admin first, as I don't know what command to run to check what software and its version installed. :P. Will revert to you! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 15:56:06 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 13:56:06 +0000 Subject: [issue12876] Make Test Error : ImportError: No module named _sha256 In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za> Message-ID: <1314885366.59.0.447310872265.issue12876@psf.upfronthosting.co.za> STINNER Victor added the comment: Do you have OpenSSL headers? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 16:18:09 2011 From: report at bugs.python.org (Jonas H.) Date: Thu, 01 Sep 2011 14:18:09 +0000 Subject: [issue12877] Popen(...).stdout.seek(...) throws "Illegal seek" In-Reply-To: <1314884313.21.0.764506702479.issue12877@psf.upfronthosting.co.za> Message-ID: <1314886689.64.0.910923800206.issue12877@psf.upfronthosting.co.za> Jonas H. added the comment: Why does it have a 'seek' method then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 16:28:16 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 14:28:16 +0000 Subject: [issue12877] Popen(...).stdout.seek(...) throws "Illegal seek" In-Reply-To: <1314884313.21.0.764506702479.issue12877@psf.upfronthosting.co.za> Message-ID: <1314887296.59.0.6065710393.issue12877@psf.upfronthosting.co.za> STINNER Victor added the comment: > Why does it have a 'seek' method then? Python doesn't remove a method if the operation is forbidden. For example, Python doesn't remove write() method if the file is read only, and it doesn't remove most methods after close(). I prefer to have files with always the same API. I think that it's more practical. Note: Text files of the io module (TextIOWrapper) raises io.UnsupportedOperation on seek() if the file is not seekable (e.g. if the file is a pipe): $ ~/prog/python/default/python Python 3.3.0a0 (default:d26c7b18fc9d, Jul 22 2011, 12:04:31) >>> import os >>> a,b=os.pipe() >>> f=os.fdopen(a, 'rb') >>> f <_io.BufferedReader name=3> >>> f.seek(0) Traceback (most recent call last): File "", line 1, in IOError: [Errno 29] Illegal seek >>> f2=os.fdopen(a, 'r') >>> f2 <_io.TextIOWrapper name=3 mode='r' encoding='UTF-8'> >>> f2.seek(0) Traceback (most recent call last): File "", line 1, in io.UnsupportedOperation: underlying stream is not seekable ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 16:45:28 2011 From: report at bugs.python.org (Vlad Riscutia) Date: Thu, 01 Sep 2011 14:45:28 +0000 Subject: [issue6069] casting error from ctypes array to structure In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za> Message-ID: <1314888328.47.0.0138570653786.issue6069@psf.upfronthosting.co.za> Vlad Riscutia added the comment: Meador, I believe this was the first issue on the tracker that got me looking into bitfield allocation. I agree that big-endian on MSVC doesn't make too much sense but you can disregard that - using default endianess will still yield different sizes of bitfields when compiled with GCC and MSVC. Basically bitfield allocation is compiler specific and patch in issue12528 implements a way to select which allocation strategy to be used at runtime instead of hardcoding the one with which Python is compiled. This should improve cross-compiler interop. I wanted to hyperlink that patch to all other bitfield bugs, that's why I followed up with link to the patch. Feel free to close this, either as not an issue or as a duplicate of issue12528. And yes, this bit about bitfield allocation should be documented and I was planning to look into it at some point after 12528 gets committed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 17:50:58 2011 From: report at bugs.python.org (Steffen Daode Nurpmeso) Date: Thu, 01 Sep 2011 15:50:58 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <4E5F78F8.5010507@haypocalc.com> Message-ID: <20110901155049.GA41945@sherwood.local> Steffen Daode Nurpmeso added the comment: > In Python 3.3, you can use sys.thread_info to check which threading > library is used. Great! I didn't know that! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 17:58:47 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 15:58:47 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za> Message-ID: <1314892727.91.0.513474881112.issue12868@psf.upfronthosting.co.za> STINNER Victor added the comment: > Great! I didn't know that! It's a new feature of Python 3.3. I added it to skip a test on old FreeBDB, see test_threadsignal.py: ------------------------ USING_PTHREAD_COND = (sys.thread_info.name == 'pthread' and sys.thread_info.lock == 'mutex+cond') ... @unittest.skipIf(USING_PTHREAD_COND, 'POSIX condition variables cannot be interrupted') def test_lock_acquire_interruption(self): ------------------------ It is also used in test_os.py: --------------- if hasattr(sys, 'thread_info') and sys.thread_info.version: USING_LINUXTHREADS = sys.thread_info.version.startswith("linuxthreads") else: USING_LINUXTHREADS = False --------------- This "linux threads" check does already exist in Python 3.2, but is uses: --------------- libpthread = os.confstr("CS_GNU_LIBPTHREAD_VERSION") USING_LINUXTHREADS= libpthread.startswith("linuxthreads") --------------- See also the doc: http://docs.python.org/dev/library/sys.html#sys.thread_info ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 19:13:07 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 01 Sep 2011 17:13:07 +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: <1314897187.16.0.260921766823.issue2636@psf.upfronthosting.co.za> Ezio Melotti added the comment: I tried to run a test suite of 3kloc (not just about regex, but regex were used in several places) and I had only one failure: >>> s = u'void foo ( type arg1 [, type arg2 ] )' >>> re.sub('(?<=[][()]) |(?!,) (?!\[,)(?=[][(),])', '', s) u'void foo(type arg1 [, type arg2])' >>> regex.sub('(?<=[][()]) |(?!,) (?!\[,)(?=[][(),])', '', s) u'void foo ( type arg1 [, type arg2 ] )' Note than when the two patterns are used independently they both yield the same result on re and regex, but once they are combined the result is different: >>> re.sub('(?<=[][()]) ', '', s) u'void foo (type arg1 [, type arg2 ])' >>> regex.sub('(?<=[][()]) ', '', s) u'void foo (type arg1 [, type arg2 ])' >>> re.sub('(?!,) (?!\[,)(?=[][(),])', '', s) u'void foo( type arg1 [, type arg2])' >>> regex.sub('(?!,) (?!\[,)(?=[][(),])', '', s) u'void foo( type arg1 [, type arg2])' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 19:50:50 2011 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 01 Sep 2011 17:50:50 +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: <1314899450.27.0.345702317902.issue2636@psf.upfronthosting.co.za> Matthew Barnett added the comment: The regex module supports nested sets and set operations, eg. r"[[a-z]--[aeiou]]" (the letters from 'a' to 'z', except the vowels). This means that literal '[' in a set needs to be escaped. For example, re module sees "[][()]..." as: [ start of set ] literal ']' [() literals '[', '(', ')' ] end of set ... ... but the regex module sees it as: [ start of set ] literal ']' [()] nested set [()] ... ... Thus: >>> s = u'void foo ( type arg1 [, type arg2 ] )' >>> regex.sub(r'(?<=[][()]) |(?!,) (?!\[,)(?=[][(),])', '', s) u'void foo ( type arg1 [, type arg2 ] )' >>> regex.sub('(?<=[]\[()]) |(?!,) (?!\[,)(?=[]\[(),])', '', s) u'void foo(type arg1 [, type arg2])' If it can't parse it as a nested set, it tries again as a non-nested set (like re), but there are bound to be regexes where it could be either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 19:51:38 2011 From: report at bugs.python.org (Meador Inge) Date: Thu, 01 Sep 2011 17:51:38 +0000 Subject: [issue6069] casting error from ctypes array to structure In-Reply-To: <1314888328.47.0.0138570653786.issue6069@psf.upfronthosting.co.za> Message-ID: Meador Inge added the comment: On Thu, Sep 1, 2011 at 9:45 AM, Vlad Riscutia wrote: > Vlad Riscutia added the comment: > > Meador, I believe this was the first issue on the tracker that got me looking into bitfield allocation. > I agree that big-endian on MSVC doesn't make too much sense but you can disregard that - using default endianess will still yield > different sizes of bitfields when compiled with GCC and MSVC. Sure, but this particular issue is purporting that the layout of the structure is incorrect, not that the size is. > Basically bitfield allocation is compiler specific and patch in issue12528 implements a way to select which > allocation strategy to be used at runtime instead of hardcoding the one with which Python is compiled. This > should improve cross-compiler interop. I wanted to hyperlink that patch to all other bitfield bugs, that's why I > followed up with link to the patch. Yes, it is very compiler specific. I have some thoughts about making this configurable, but I will comment on issue12528 with those. > Feel free to close this, either as not an issue or as a duplicate of issue12528. I will open a documentation bug and close this one out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:09:36 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 01 Sep 2011 18:09:36 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za> Message-ID: <1314900576.94.0.477936321927.issue12868@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Here's a patch with an updated skip message. As for rthreads support, a quick search seems to indicate that its API is exactly the same as pthreads, and it's even binary compatible. Python will automatically use it when run on a OpenBSD system with rthreads enabled. ---------- Added file: http://bugs.python.org/file23082/openbsd_sigaltstack-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:10:16 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 01 Sep 2011 18:10:16 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za> Message-ID: <1314900616.79.0.656748470227.issue12868@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file23078/openbsd_sigaltstack.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:12:44 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 01 Sep 2011 18:12:44 +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: <1314900764.54.0.497634516656.issue2636@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks for the explanation, but isn't this a backward incompatible feature? I think it should be enabled only when the re.NEW flag is passed. The idiom [][...] is also quite common, so I think it might break different programs if regex has a different behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:14:55 2011 From: report at bugs.python.org (Vlad Riscutia) Date: Thu, 01 Sep 2011 18:14:55 +0000 Subject: [issue6069] casting error from ctypes array to structure In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za> Message-ID: <1314900895.78.0.257575940501.issue6069@psf.upfronthosting.co.za> Vlad Riscutia added the comment: Sounds good. Please nosy me in the doc bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:15:25 2011 From: report at bugs.python.org (Meador Inge) Date: Thu, 01 Sep 2011 18:15:25 +0000 Subject: [issue12528] Implement configurable bitfield allocation strategy In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za> Message-ID: <1314900925.52.0.194354257186.issue12528@psf.upfronthosting.co.za> Meador Inge added the comment: As stated, how a particular compiler allocates bitfields is *extremely* implementation specific. There can be differences in implementations between different compilers, different *versions* of the same compiler, and different invocations of the same compiler where the options are varied. I am wondering whether adding this feature will open up a can of worms that we don't want to deal with. There are other options beyond MSVC and GCC that seem reasonable. For example, GCC packs bitfields together on structures defined with '__attribute__((packed))'. Do we need a GCCPACKED option now? Also, GCC 4.4 fixed a bug that can lead to differences in structure layout from previous versions. See -Wpacked-bitfield-compat option [1]. Do we need a GCC44 option now? Finally, structure layout is architecture specific. GCC for x86, for example, has the 'ms_struct' attribute extensions for x86 [2]. Does this mean that for a GCC compiled Python that the MSVC option will only work for an x86 host? My point is that there are many, many variations on how a *single* compiler can allocate bitfields. So just saying "GCC allocation" strategy is not adequate. So, lets take a step back. What exact problem is this feature trying to solve? Is one of the use cases that 'ctypes' for a Windows hosted Python built with MSVC++ can interop with C code compiled with a Windows hosted GCC (e.g. cygwin)? If so, then is that realistic? ISTM, that there are other ABI differences that would prevent that from working. It seem perfectly reasonable to me that ctypes will only interact with bits that were constructed with the exact same compiler (and options) as the interpreter itself. If it is not already, then we should document this. [1] http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html [2] http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html ---------- nosy: +meadori _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:18:26 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 18:18:26 +0000 Subject: [issue2636] Adding a new regex module (compatible with re) In-Reply-To: <1314900764.54.0.497634516656.issue2636@psf.upfronthosting.co.za> Message-ID: <1314900952.3617.21.camel@localhost.localdomain> Antoine Pitrou added the comment: > Thanks for the explanation, but isn't this a backward incompatible > feature? > I think it should be enabled only when the re.NEW flag is passed. > The idiom [][...] is also quite common, so I think it might break > different programs if regex has a different behavior. As someone said, I'd rather have a re.COMPAT flag. re.NEW will look silly in a few years. Also, we can have a warning about unescaped brackets during a transitional period. However, it really needs the warning to be enabled by default, IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:23:38 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 18:23:38 +0000 Subject: [issue12876] Make Test Error : ImportError: No module named _sha256 In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za> Message-ID: <1314901418.15.0.732150982306.issue12876@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:27:17 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 18:27:17 +0000 Subject: [issue12850] [PATCH] stm.atomic In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za> Message-ID: <1314901637.36.0.295424331679.issue12850@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm worried that by allowing users to pass function pointers here, we are allowing all kinds of uses that we will have to more or less support later. What exactly "taking the GIL" means and when exactly it is done in the execution process is an implementation detail. Armin, is there a way to implement what you want to do with a more constraining API? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:29:33 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 18:29:33 +0000 Subject: [issue7171] Add inet_ntop and inet_pton support for Windows In-Reply-To: <1255994426.45.0.89635983538.issue7171@psf.upfronthosting.co.za> Message-ID: <1314901773.89.0.815453664203.issue7171@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Library (Lib) -IO, Windows keywords: +easy versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:30:34 2011 From: report at bugs.python.org (Vlad Riscutia) Date: Thu, 01 Sep 2011 18:30:34 +0000 Subject: [issue12528] Implement configurable bitfield allocation strategy In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za> Message-ID: <1314901834.84.0.11701101769.issue12528@psf.upfronthosting.co.za> Vlad Riscutia added the comment: Well currently we pack bitfields with an algorithm that uses #ifdefs for GCC and MSVC builds. This feature tries to remove the hardcoded behavior and implement it as a runtime option. This should improve interop with other compilers. Currently I provided these for MSVC-style and GCC-style bitfield allocations. These, of course, can be extended with other strategies. I am not sure that the fact that GCC has different types of bitfield allocations in different versions is a point against this feature. Consider that in our current code we don't use compiler bitfield allocation, we create the structure layout using our own algorithm, interop might be broken even if Python gets built with same version of GCC as the binary we want to interop with as long as algorithm is out of date. This patch should provide some flexibility in this matter. Wouldn't a GCC44 constant provided at API level be better than saying "you can't interop with anything build with GCC 4.4 and up"? Or vice-versa, anything built with GCC < 4.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:40:00 2011 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 01 Sep 2011 18:40:00 +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: <1314902400.86.0.107660407722.issue2636@psf.upfronthosting.co.za> Ezio Melotti added the comment: Changing the name of the flag is fine with me. Having a warning for unescaped brackets that trigger set operations might also be a solution (once escaped they will still work on the old re). Maybe the same could also be done for scoped flags. FWIW I tried to come up with a simpler regex that makes some sense and triggers unwanted set operations and I didn't come up with anything except: >>> regex.findall('[[(]foo[)]]', '[[foo] (foo)]') ['f', 'o', 'o', '(', 'f', 'o', 'o', ')'] >>> re.findall('[[(]foo[)]]', '[[foo] (foo)]') ['(foo)]'] (but this doesn't make too much sense). Complex regex will still break though, so the issue needs to be addressed somehow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 20:47:09 2011 From: report at bugs.python.org (Eric Promislow) Date: Thu, 01 Sep 2011 18:47:09 +0000 Subject: [issue12878] io.StringIO doesn't provide a __dict__ field Message-ID: <1314902829.02.0.266212831864.issue12878@psf.upfronthosting.co.za> New submission from Eric Promislow : I see that going from Python 3.1.1 to 3.1.2 instances of io.StringIO no longer have a __dict__ field. Why? Is this to make them unpicklable? ---------- components: IO messages: 143344 nosy: ericp priority: normal severity: normal status: open title: io.StringIO doesn't provide a __dict__ field type: behavior versions: Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 21:40:47 2011 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 01 Sep 2011 19:40:47 +0000 Subject: [issue12876] Make Test Error : ImportError: No module named _sha256 In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za> Message-ID: <1314906047.4.0.320440624023.issue12876@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The fact that it called __get_builtin_constructor implies that the ssl backed _hashlib module was not available. It looks like the non-openssl standalone _sha256 module (and likely the _sha512 module) both failed to be compiled. I would not expect that to ever happen when using gcc regardless of the OS and crazy architecture. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 21:41:14 2011 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 Sep 2011 19:41:14 +0000 Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 385c2ec78f16 by Antoine Pitrou in branch '3.2': Issue #12802: the Windows error ERROR_DIRECTORY (numbered 267) is now http://hg.python.org/cpython/rev/385c2ec78f16 New changeset d72d5c942232 by Antoine Pitrou in branch 'default': Issue #12802: the Windows error ERROR_DIRECTORY (numbered 267) is now http://hg.python.org/cpython/rev/d72d5c942232 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 21:43:00 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 19:43:00 +0000 Subject: [issue12802] Windows error code 267 should be mapped to ENOTDIR, not EINVAL In-Reply-To: <1313887590.17.0.197838525474.issue12802@psf.upfronthosting.co.za> Message-ID: <1314906180.8.0.108303698762.issue12802@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed now. Hopefully it won't break anything! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 21:54:04 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 19:54:04 +0000 Subject: [issue12878] io.StringIO doesn't provide a __dict__ field In-Reply-To: <1314902829.02.0.266212831864.issue12878@psf.upfronthosting.co.za> Message-ID: <1314906844.47.0.854814157394.issue12878@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure why that is. Note that you can still set and get arbitrary attributes, so there must be a dict somewhere, but it isn't exposed. Also, there wasn't any significant change in StringIO in the 3.1 line. Benjamin, do you have any idea? >>> s = io.StringIO() >>> s.x = 5 >>> s.x 5 >>> s.__dict__ Traceback (most recent call last): File "", line 1, in AttributeError: '_io.StringIO' object has no attribute '__dict__' ---------- nosy: +amaury.forgeotdarc, benjamin.peterson, pitrou versions: +Python 3.2, Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 21:55:41 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 19:55:41 +0000 Subject: [issue12879] "method-wrapper" objects are difficult to inspect Message-ID: <1314906941.68.0.862588142823.issue12879@psf.upfronthosting.co.za> New submission from Antoine Pitrou : This is a bit unhelpful: >>> s = io.StringIO() >>> s.__getattribute__ >>> dir(s.__getattribute__) Traceback (most recent call last): File "", line 1, in TypeError: object does not provide __dir__ ---------- components: Interpreter Core messages: 143349 nosy: amaury.forgeotdarc, benjamin.peterson, pitrou priority: normal severity: normal status: open title: "method-wrapper" objects are difficult to inspect type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 22:02:50 2011 From: report at bugs.python.org (Doug Hellmann) Date: Thu, 01 Sep 2011 20:02:50 +0000 Subject: [issue11879] TarFile.chown: should use TarInfo.uid if user lookup fails In-Reply-To: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za> Message-ID: <1314907370.96.0.297740218858.issue11879@psf.upfronthosting.co.za> Changes by Doug Hellmann : ---------- nosy: +doughellmann _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 22:12:58 2011 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 01 Sep 2011 20:12:58 +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: <1314907978.17.0.243959479844.issue2636@psf.upfronthosting.co.za> Matthew Barnett added the comment: I think I need a show of hands. Should the default be old behaviour (like re) or new behaviour? (It might be old now, new later.) Should there be a NEW flag (as at present), or an OLD flag, or a VERSION parameter (0=old, 1=new, 2=?)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 22:13:11 2011 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 01 Sep 2011 20:13:11 +0000 Subject: [issue12528] Implement configurable bitfield allocation strategy In-Reply-To: <1310327557.36.0.947857913804.issue12528@psf.upfronthosting.co.za> Message-ID: <1314907991.15.0.43709269752.issue12528@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As a (Windows) user, I would like to be able to download any working pre-compiled shared library (.dll) and access it via ctypes. The particular compiler used to compile cpythonx.y.z should not determine whether a Pythonx.y program works. The use of VSC2008 is not part of the Python3.2 definition. So I am in favor of features than makes ctypes more likely to work. I understand that this should be easy if the datatypes sent and received are standard ints, floats, and arrays thereof, since the bit patterns are then knowable. I gather that the problem with custom bitfields is that the resulting bit pattern format is not only not documented in the .dll, but is also not determined by the external documentation (the .h files). Does anyone know how Cython, for instance, handles this problem? Stephen Behnel recommends it as an alternative to ctypes. Does it even try to deal with bitfields? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 22:13:26 2011 From: report at bugs.python.org (Justin Wehnes) Date: Thu, 01 Sep 2011 20:13:26 +0000 Subject: [issue12537] mailbox's _become_message is very fragile In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za> Message-ID: <1314908006.67.0.137044209222.issue12537@psf.upfronthosting.co.za> Changes by Justin Wehnes : ---------- nosy: +jwehnes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 22:16:57 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 20:16:57 +0000 Subject: [issue2636] Adding a new regex module (compatible with re) In-Reply-To: <1314907978.17.0.243959479844.issue2636@psf.upfronthosting.co.za> Message-ID: <1314908064.3617.34.camel@localhost.localdomain> Antoine Pitrou added the comment: > I think I need a show of hands. > > Should the default be old behaviour (like re) or new behaviour? (It > might be old now, new later.) > > Should there be a NEW flag (as at present), or an OLD flag, or a > VERSION parameter (0=old, 1=new, 2=?)? VERSION might be best, but then it should probably be a separate argument rather than a flag. "old now, new later" doesn't solve the issue unless we have a careful set of warnings to point out problematic regexes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 22:21:27 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 20:21:27 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314900576.94.0.477936321927.issue12868@psf.upfronthosting.co.za> Message-ID: <201109012221.07683.victor.stinner@haypocalc.com> STINNER Victor added the comment: > As for rthreads support, a quick search seems to indicate that its API is > exactly the same as pthreads, and it's even binary compatible. Python will > automatically use it when run on a OpenBSD system with rthreads enabled. Well... not exactly. I asked on #openbsd: 22:07 < haypo> hi. what is the status of rthread? it looks like it is not available by default 22:14 < tp76> I might be wrong, but I don't think much work has been done on that in a while. 22:15 < haypo> tp76: i'm working on Python. Python is linked to pthread. I would like to know if we can link Python to rthread 22:16 < farhaven> no, you can't 22:17 < farhaven> rthreads is not (yet) a drop in replacement for pthreads and it basically works only if you use it for kernel threads 22:17 < farhaven> at least the manpage for rfork() advises against using it in userspace to create rthreads 22:18 < haypo> farhaven: does rthread have a userland API, similar to pthread, to manage threads? 22:18 < farhaven> nope, not that i know of 22:18 < haypo> i cannot find informations about rthread, only some old documents (2005) 22:18 < farhaven> afaik the only thing exposed to userland is rfork()'s RFTHREAD 22:19 < farhaven> i think tedu made a presentation about rthreads a while ago 22:19 < farhaven> but yeah, i wondered about that too one or two months ago 22:19 < farhaven> and it turned out, rthreads are not exactly usable :D Your last patch is correct. Go ahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 22:43:08 2011 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 01 Sep 2011 20:43:08 +0000 Subject: [issue12879] "method-wrapper" objects are difficult to inspect In-Reply-To: <1314906941.68.0.862588142823.issue12879@psf.upfronthosting.co.za> Message-ID: <1314909788.67.0.0481493898686.issue12879@psf.upfronthosting.co.za> Benjamin Peterson added the comment: 51e27f42beda and friends. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 22:57:58 2011 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Thu, 01 Sep 2011 20:57:58 +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: <1314910678.75.0.658015621738.issue2636@psf.upfronthosting.co.za> Jeffrey C. Jacobs added the comment: On 1 September 2011 16:12, Matthew Barnett wrote: > > Matthew Barnett added the comment: > > I think I need a show of hands. For my part, I recommend literal flags, i.e. re.VERSION222, re.VERSION300, etc. Then you know exactly what you're getting and although it may be confusing, we can then slowly deprecate re.VERSION222 so that people can get used to the new syntax. Returning to lurking on my own issue. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 23:08:14 2011 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 Sep 2011 21:08:14 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a29b72950795 by Charles-Fran?ois Natali in branch 'default': Issue #12868: Skip test_faulthandler.test_stack_overflow() on OpenBSD: http://hg.python.org/cpython/rev/a29b72950795 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 23:11:33 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 01 Sep 2011 21:11:33 +0000 Subject: [issue12868] test_faulthandler.test_stack_overflow() failed on OpenBSD In-Reply-To: <1314777333.36.0.543394824681.issue12868@psf.upfronthosting.co.za> Message-ID: <1314911493.21.0.331621347586.issue12868@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed. R?mi, thanks once again for this report! ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 23:41:22 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 01 Sep 2011 21:41:22 +0000 Subject: [issue8813] SSLContext doesn't support loading a CRL In-Reply-To: <1274735830.03.0.714974872377.issue8813@psf.upfronthosting.co.za> Message-ID: <1314913282.67.0.74778853204.issue8813@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is it enough to just load a CRL file, or is other functionality usually needed? The following APIs should help us do it: - X509_STORE *SSL_CTX_get_cert_store(const SSL_CTX *ctx); - int X509_STORE_add_crl(X509_STORE *ctx, X509_CRL *x); - X509_CRL *d2i_X509_CRL_fp(FILE *fp,X509_CRL **crl); And also for configuration (enable CRL checking on the context): - X509_VERIFY_PARAM *X509_STORE_CTX_get0_param(X509_STORE_CTX *ctx); - int X509_VERIFY_PARAM_set_flags(X509_VERIFY_PARAM *param, unsigned long flags); ---------- stage: -> needs patch versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 23:54:29 2011 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 Sep 2011 21:54:29 +0000 Subject: [issue12494] subprocess: check_output() doesn't close pipes on error In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 86b7f14485c9 by Victor Stinner in branch 'default': Issue #12494: Close pipes and kill process on error in subprocess functions http://hg.python.org/cpython/rev/86b7f14485c9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 23:57:19 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 21:57:19 +0000 Subject: [issue12494] subprocess: check_output() doesn't close pipes on error In-Reply-To: <1309817625.67.0.269796238759.issue12494@psf.upfronthosting.co.za> Message-ID: <1314914239.3.0.678486093745.issue12494@psf.upfronthosting.co.za> STINNER Victor added the comment: > The second patch looks good. Tests? I don't see how to test that the pipes are closed, because the Popen object (and its stdout and stderr attributes) are not visible outside the patched functions. > I consider that this issue is a bug, so it should be fixed in 2.7 > and 3.2. I tried to write a patch, but I chose to keep the code unchanged. I prefer to keep this little tricky bug, instead of introducing another more important regression. Reopen the issue if you have a script to test the fix, or if you really want a backport. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 1 23:58:35 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 21:58:35 +0000 Subject: [issue6560] socket sendmsg(), recvmsg() methods In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za> Message-ID: <1314914315.09.0.498460564199.issue6560@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 00:06:09 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 22:06:09 +0000 Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled without threads In-Reply-To: <1314813822.31.0.567192327773.issue12871@psf.upfronthosting.co.za> Message-ID: <1314914769.65.0.203629815307.issue12871@psf.upfronthosting.co.za> STINNER Victor added the comment: > For example, the following snippet builds correctly on Linux It builds correctly with -pthread or -lpthread, but it fails to build without these options. sched_get_priority_max() and sched_get_priority_min() come from libpthread on OpenBSD, whereas Python only checks for "#ifdef HAVE_SCHED_H". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 00:06:33 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 22:06:33 +0000 Subject: [issue12871] Disable sched_get_priority_min/max on OpenBSD if Python is compiled without threads In-Reply-To: <1314813822.31.0.567192327773.issue12871@psf.upfronthosting.co.za> Message-ID: <1314914793.79.0.827040441509.issue12871@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Disable sched_get_priority_min/max if Python is compiled without threads -> Disable sched_get_priority_min/max on OpenBSD if Python is compiled without threads _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 01:05:23 2011 From: report at bugs.python.org (Roundup Robot) Date: Thu, 01 Sep 2011 23:05:23 +0000 Subject: [issue12636] IDLE ignores -*- coding -*- with -r option In-Reply-To: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset fe7777f1ed14 by Victor Stinner in branch '3.2': Issue #12636: IDLE reads the coding cookie when executing a Python script. http://hg.python.org/cpython/rev/fe7777f1ed14 New changeset a8748022504f by Victor Stinner in branch 'default': Merge 3.2: Issue #12636: IDLE reads the coding cookie when executing a Python script. http://hg.python.org/cpython/rev/a8748022504f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 01:06:50 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 23:06:50 +0000 Subject: [issue12636] IDLE ignores -*- coding -*- with -r option In-Reply-To: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za> Message-ID: <1314918410.05.0.528156181856.issue12636@psf.upfronthosting.co.za> STINNER Victor added the comment: Fixed, thanks for the report. Python 2.7 is not affected by this bug. ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 01:09:04 2011 From: report at bugs.python.org (STINNER Victor) Date: Thu, 01 Sep 2011 23:09:04 +0000 Subject: [issue12636] IDLE ignores -*- coding -*- with -r option In-Reply-To: <1311587575.82.0.250460007364.issue12636@psf.upfronthosting.co.za> Message-ID: <1314918544.3.0.0384371890387.issue12636@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: works for me -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 02:26:00 2011 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Sep 2011 00:26:00 +0000 Subject: [issue10278] add time.wallclock() method In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za> Message-ID: <1314923160.98.0.215533597973.issue10278@psf.upfronthosting.co.za> STINNER Victor added the comment: clock_gettime.patch: add time.clock_gettime() function and time.CLOCK_xxx constants. The patch requires to rerun "autoconf". For the documentation, I don't know the availability of this function. Is it available on Windows? CLOCK_REALTIME doc contains "Setting this clock requires appropriate privileges": this sentence might be removed if we don't expose clock_settime. The constants are not defined if the function is not available. timemodule.c and datetimemodule.c are no more linked to libm. I don't know why libm was used? Copy/paste failure? On Linux, clock_gettime() requires librt. I chose to check for librt in configure.in. To get this info in setup.py, I close to use the TIMEMODULE_LIBS define (in pyconfig.h). I don't know if there is something simpler. time.clock_gettime() returns a float. It would be nice to keep nanoseconds as an integer, but I chose a float to mimic other time functions. If we need nanosecond resolution, a new function can be added. The unit test is very simple, but less than time.clock() test :-) ---------- Added file: http://bugs.python.org/file23083/clock_gettime.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 02:27:14 2011 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Sep 2011 00:27:14 +0000 Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0 In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za> Message-ID: <1314923234.05.0.417380226214.issue12852@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: test_posix.test_fdlistdir() segfault on OpenBSD -> POSIX level issues in posixmodule.c on OpenBSD 5.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 02:39:07 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 02 Sep 2011 00:39:07 +0000 Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0 In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za> Message-ID: <1314923947.84.0.053962448787.issue12852@psf.upfronthosting.co.za> Antoine Pitrou added the comment: R?mi : what happens if you manually add extern DIR *fdopendir(int fd); at the beginning of posixmodule.c? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 03:30:32 2011 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 02 Sep 2011 01:30:32 +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: <1314927032.58.0.423190804709.issue2636@psf.upfronthosting.co.za> Ezio Melotti added the comment: In order to replace the re module, regex must have the same behavior (except for bugs, where the correct behavior is most likely preferred, even if it's different). Having re.OLD and warnings active by default in 3.3 (and possibly 3.4) should give enough time to fix the regex if/when necessary (either by changing the regex or by adding the re.OLD flag manually). In 3.4 (or 3.5) we can then change the default behavior to the new semantics. In this way we won't have to keep using the re.NEW flag on every regex. I'm not sure if a version flag is useful, unless you are planning to add more incompatible changes. Also each new version *flag* means one more path to add/maintain in the code. Having a simple .regex_version attribute might be a more practical (albeit less powerful) solution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:13:11 2011 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 02 Sep 2011 02:13:11 +0000 Subject: [issue2636] Adding a new regex module (compatible with re) In-Reply-To: <1314907978.17.0.243959479844.issue2636@psf.upfronthosting.co.za> Message-ID: <4E603BAC.9010303@pearwood.info> Steven D'Aprano added the comment: Matthew Barnett wrote: > Matthew Barnett added the comment: > > I think I need a show of hands. > > Should the default be old behaviour (like re) or new behaviour? (It might be old now, new later.) > > Should there be a NEW flag (as at present), or an OLD flag, or a VERSION parameter (0=old, 1=new, 2=?)? I prefer Antoine's suggested spelling, COMPAT, rather than OLD. How would you write the various options? After the transition is easy: # Get backwards-compatible behaviour: compile(string, COMPAT) compile(string, VERSION0) # Get regex non-compatible behaviour: compile(string) # will be the default in the future compile(string, VERSION1) But what about during the transition, when backwards-compatible behaviour is the default? There needs to be a way to turn compatibility mode off, not just turn it on. # Get backwards-compatible behaviour: compile(string) # will be the default for a release or two compile(string, COMPAT) compile(string, VERSION0) # Get regex non-compatible behaviour: compile(string, VERSION1) So I guess my preference is VERSION0 and VERSION1 flags, even if there is never going to be a VERSION2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:14:55 2011 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 02 Sep 2011 02:14:55 +0000 Subject: [issue10882] Add os.sendfile() In-Reply-To: <1294691268.76.0.727179568007.issue10882@psf.upfronthosting.co.za> Message-ID: <1314929695.17.0.315427567156.issue10882@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +Yury.Selivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:23:35 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 02:23:35 +0000 Subject: [issue12528] Implement configurable bitfield allocation strategy In-Reply-To: <1314901834.84.0.11701101769.issue12528@psf.upfronthosting.co.za> Message-ID: Meador Inge added the comment: Hi Vlad, On Thu, Sep 1, 2011 at 1:30 PM, Vlad Riscutia wrote: > Vlad Riscutia added the comment: > > Well currently we pack bitfields with an algorithm that uses #ifdefs for GCC and MSVC builds. This feature tries to remove the > hardcoded behavior and implement it as a runtime option. This should improve interop with other compilers. Currently I provided these > for MSVC-style and GCC-style bitfield allocations. These, of course, can be extended with other strategies. Yup, I understand what the feature is doing. I just wanted to reiterate (as I am sure you already know) that typically the rules for implementing bit fields in a particular compiler are pretty complex. I just wanted to make sure that the use cases are out there to justify the complexity. issue11920 really does seem like a use case where someone would otherwise be stuck without a runtime configurable allocation strategy. BTW, out of curiosity I explored the packed case that I mentioned earlier with GCC more (reproduction case attached): [meadori at motherbrain ctypes]$ make clean; make rm -f foo.o libfoo.so.1.0 gcc -Wall -fPIC -c foo.c gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 foo.o python repro.py In Python: (85, 85) >From C: (85, 85) >From Python: (85, 85) [meadori at motherbrain ctypes]$ make clean; CFLAGS=-DPACK=1 make rm -f foo.o libfoo.so.1.0 gcc -Wall -fPIC -DPACK=1 -c foo.c gcc -shared -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0 foo.o python repro.py In Python: (85, 85) >From C: (85, 85) >From Python: (85, 170) This shows that there are already cases that can't be handled with packed bit fields and GCC. This runtime configuration feature, could fix this case as well. However, it is probably better to wait for a real world use case before implementing some pathological case that I cooked up ;-) > Wouldn't a GCC44 constant provided at API level be better than saying "you can't interop with anything build with GCC 4.4 and up"? Or > vice-versa, anything built with GCC < 4.4. Yeah, probably so. I think the compiler constraint I stated before is probably a bit too strong. I need to think about it more. But, again, my point is that there are a lot of different variations when it comes to bit field allocations. I don't think we want to end up implementing all of them. ---------- Added file: http://bugs.python.org/file23084/ctypes-packed-bitfields.tar.bz2 _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: ctypes-packed-bitfields.tar.bz2 Type: application/x-bzip2 Size: 1077 bytes Desc: not available URL: From report at bugs.python.org Fri Sep 2 04:34:11 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 02:34:11 +0000 Subject: [issue12880] ctypes: clearly document how structure bit fields are allocated Message-ID: <1314930851.91.0.112444630543.issue12880@psf.upfronthosting.co.za> New submission from Meador Inge : As issues like issue6069 and issue11920 allude to, figuring out how 'ctypes' allocates bit-fields is not very clear. The documentation should be enhanced to flesh this out in more detail. As an example, Microsoft documents the VC++ implementation in a reasonably clear manner ( http://msdn.microsoft.com/en-us/library/ewwyfdbe(v=vs.71).aspx ). ---------- assignee: docs at python components: Documentation messages: 143369 nosy: docs at python, meadori, terry.reedy, vladris priority: normal severity: normal stage: needs patch status: open title: ctypes: clearly document how structure bit fields are allocated type: feature request versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:36:37 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 02:36:37 +0000 Subject: [issue6069] casting error from ctypes array to structure In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za> Message-ID: <1314930997.84.0.00442514147646.issue6069@psf.upfronthosting.co.za> Meador Inge added the comment: I opened issue12880 for the doc bug. Closing this one out ... ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:42:24 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 02:42:24 +0000 Subject: [issue11920] ctypes: Strange bitfield structure sizing issue In-Reply-To: <1303750376.54.0.894731507231.issue11920@psf.upfronthosting.co.za> Message-ID: <1314931344.91.0.39945965988.issue11920@psf.upfronthosting.co.za> Meador Inge added the comment: Hi Steve, There is currently no way to deal with this situation. Vlad has opened issue12528 with a proposal to make the allocation strategy configurable from the 'ctypes' API. Please follow that issue if you are still interested. I am closing this issue. ---------- nosy: +meadori resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Implement configurable bitfield allocation strategy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:43:23 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 02:43:23 +0000 Subject: [issue6069] casting error from ctypes array to structure In-Reply-To: <1242815548.73.0.540935568828.issue6069@psf.upfronthosting.co.za> Message-ID: <1314931403.73.0.0232739935959.issue6069@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- stage: test needed -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:49:15 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 02:49:15 +0000 Subject: [issue9030] ctypes variable limits In-Reply-To: <1276892210.09.0.679201213154.issue9030@psf.upfronthosting.co.za> Message-ID: <1314931755.34.0.410656042816.issue9030@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- nosy: -theller stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:51:09 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 02:51:09 +0000 Subject: [issue9175] ctypes doesn't build on hp-ux In-Reply-To: <1278407736.6.0.642117116261.issue9175@psf.upfronthosting.co.za> Message-ID: <1314931869.11.0.68636887115.issue9175@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- assignee: theller -> nosy: -theller priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:58:57 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 02:58:57 +0000 Subject: [issue6980] fix ctypes build failure on armel-linux-gnueabi with -mfloat-abi=softfp In-Reply-To: <1253730625.9.0.970320332999.issue6980@psf.upfronthosting.co.za> Message-ID: <1314932337.99.0.211826013925.issue6980@psf.upfronthosting.co.za> Meador Inge added the comment: This was, in fact, committed already. ---------- assignee: theller -> nosy: +meadori -theller resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 04:59:28 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 02:59:28 +0000 Subject: [issue6980] fix ctypes build failure on armel-linux-gnueabi with -mfloat-abi=softfp In-Reply-To: <1253730625.9.0.970320332999.issue6980@psf.upfronthosting.co.za> Message-ID: <1314932368.18.0.662711504689.issue6980@psf.upfronthosting.co.za> Meador Inge added the comment: Whoops. I meant to post a link to the commit before. It is here: http://hg.python.org/cpython/rev/584db03e5248. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 05:00:50 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 03:00:50 +0000 Subject: [issue5718] Problem compiling ffi part of build on AIX 5.3. In-Reply-To: <1239117342.9.0.186105014374.issue5718@psf.upfronthosting.co.za> Message-ID: <1314932450.07.0.372470065965.issue5718@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- assignee: theller -> nosy: -theller priority: normal -> low stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 05:04:27 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 03:04:27 +0000 Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za> Message-ID: <1314932667.9.0.618616465888.issue6006@psf.upfronthosting.co.za> Changes by Meador Inge : ---------- assignee: theller -> nosy: -theller priority: normal -> low stage: -> patch review type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 05:28:11 2011 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Fri, 02 Sep 2011 03:28:11 +0000 Subject: [issue12819] PEP 393 - Flexible Unicode String Representation In-Reply-To: <1314039095.43.0.38343392107.issue12819@psf.upfronthosting.co.za> Message-ID: <1314934091.52.0.207427156406.issue12819@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 05:38:13 2011 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 02 Sep 2011 03:38:13 +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: <1314934693.27.0.143552775936.issue2636@psf.upfronthosting.co.za> Ezio Melotti added the comment: Also note that some behaviors are not "old" or "compatible", but just different. For example why inline flags should be the old (or new) behavior? Or e.g. the behavior of version 2 but not 0 and 1? Also what if I want zero-width splits but not nested sets and sets operations? Or if I want inline flags but not zero-width splits? A new set of "features" flags might be an alternative approach. It will also make possible to add new features that are not backward compatible that can be turned on explicitly with their flag. It would be fine for me if I had to turn on explicitly e.g. nested sets if/when I'll need to use them, and keep having the "normal" behavior otherwise. OTOH there are three problems with these approach: 1) it's not compatible with regex (I guess people will use the external module in Python <3.3 and the included one in 3.3+, probably expecting the same semantics). This is also true with the OLD/COMPAT flag though; 2) it might require other inline feature-flags; 3) the new set of flags might be added to the other flags or be separate, so e.g. re.compile(pattern, flags=re.I|re.NESTEDSETS) or re.compile(pattern, flags=re.I, features=re.NESTEDSETS). I'm not sure it's a good idea to add another arg though. Matthew, is there a comprehensive list of all the bugfix/features that have a different behavior from re? We should first check what changes are acceptable and what aren't, and depending on how many and what they are we can then decide what is the best approach (a catch-all flag or several flags to change the behavior, transition period + warning before setting it as default, etc.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 05:45:40 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 03:45:40 +0000 Subject: [issue12764] segfault in ctypes.Struct with bad _fields_ In-Reply-To: <1313526117.08.0.584705454362.issue12764@psf.upfronthosting.co.za> Message-ID: <1314935140.41.0.152027374498.issue12764@psf.upfronthosting.co.za> Meador Inge added the comment: Vlad, Thanks for the patch. A few nits: 1. The test case is in 'test_bitfields.py'. I think it should go in 'test_structures.py'. 2. The test case would probably be cleaner using a 'with' context manager: with self.assertRaises(TypeError): class S(Structure): _fields_ = [(b"x", c_int)] A few more test cases might be nice too. 3. The TypeError message display something like: "structure field name must be string not bytes" maybe the following would be more understandable: "field name must be an object of type str not bytes" 4. The 'ptr', 'len', and 'buf' initializers are unnecessary. Otherwise, looks good. ---------- nosy: +meadori stage: -> patch review versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 05:50:52 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 03:50:52 +0000 Subject: [issue12881] ctypes: segfault with large structure field names Message-ID: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za> New submission from Meador Inge : Reproduced on Fedora 15 with tip Python: [meadori at motherbrain cpython]$ ./python Python 3.3.0a0 (default:3102951cc1ce+, Sep 1 2011, 22:19:06) [GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes [68588 refs] >>> class S(ctypes.Structure): ... _fields_ = [('x' * 10000000, ctypes.c_int)] ... Segmentation fault (core dumped) ---------- components: ctypes messages: 143376 nosy: amaury.forgeotdarc, belopolsky, meadori priority: normal severity: normal stage: needs patch status: open title: ctypes: segfault with large structure field names type: crash versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 06:04:15 2011 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 02 Sep 2011 04:04:15 +0000 Subject: [issue2636] Adding a new regex module (compatible with re) In-Reply-To: <1314934693.27.0.143552775936.issue2636@psf.upfronthosting.co.za> Message-ID: <4E6055B4.2000800@pearwood.info> Steven D'Aprano added the comment: Ezio Melotti wrote: > Ezio Melotti added the comment: > > Also note that some behaviors are not "old" or "compatible", but just different. For example why inline flags should be the old (or new) behavior? Or e.g. the behavior of version 2 but not 0 and 1? > Also what if I want zero-width splits but not nested sets and sets operations? Or if I want inline flags but not zero-width splits? I think this is adding excessive complexity. Please consider poor Matthew's sanity (or whoever ends up maintaining the module long term), not to mention that of the users of the module. I think it is reasonable to pick a *set* of features as a whole: "I want the regex module to behave exactly the same as the re module" or "I don't care about the re module, give me all the goodies offered by the regex module" but I don't think it is reasonable to expect to pick and choose individual features: "I want zero-width splits but not nested sets or inline flags, and I want the locale flag to act like the re module, and ASCII characters to be treated just like in Perl, but non-ASCII characters to be treated just like grep, and a half double decaff half-caf soy mocha with a twist of lemon with a dash of half-fat unsweetened whipped cream on the side." If you don't want a feature, don't use it. "Feature flags" leads to a combinational explosion that makes comprehensive testing all but impossible. If you have four features A...D, then for *each* feature you need sixteen tests: A with flags 0000 A with flags 0001 A with flags 0010 A with flags 0011 [...] A with flags 1111 to ensure that there are no side-effects from turning features off. The alternative is hard to track down bugs: "this regular expression returns the wrong result, but only if you have flags A, B and G turned on and C and F turned off." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 07:17:11 2011 From: report at bugs.python.org (Abhijit Bhattacharjee) Date: Fri, 02 Sep 2011 05:17:11 +0000 Subject: [issue12882] mmap crash on Windows Message-ID: <1314940631.31.0.750108382526.issue12882@psf.upfronthosting.co.za> New submission from Abhijit Bhattacharjee : The following Code causes Python to crash import os import mmap data = mmap.mmap(open(,"r+").fileno(),os.path.getsize()) assuming is present in the current working directory ---------- components: Interpreter Core, Windows messages: 143378 nosy: itabhijitb priority: normal severity: normal status: open title: mmap crash on Windows type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 07:33:01 2011 From: report at bugs.python.org (Armin Rigo) Date: Fri, 02 Sep 2011 05:33:01 +0000 Subject: [issue12850] [PATCH] stm.atomic In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za> Message-ID: <1314941581.69.0.473849794886.issue12850@psf.upfronthosting.co.za> Armin Rigo added the comment: Antoine: we could take two lines from the current implementation of these hook from stm/transactionmodule.c, and move them to the interpreter core. CPython would end up with containing the core logic for transactions. A possible API would look like that: /* stops all threads different from 'tstate' at their next bytecode, at which point the given callback is invoked */ _PyEval_SetThreadStopper(PyThreadState *tstate, void (*callback)(void)); Such a function can also be tested in CPython, e.g. with ctypes. Still maybe a different name would be better, like _PyEval_InternalThreadStopper(). Or, if that's still a callback too much: /* stops all threads different from 'tstate' at their next bytecode, at which point they wait for the 'lock' to be available */ _PyEval_SetThreadStopper(PyThreadState *tstate, PyThread_lock_type lock); ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 07:36:45 2011 From: report at bugs.python.org (Remi Pointel) Date: Fri, 02 Sep 2011 05:36:45 +0000 Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0 In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za> Message-ID: <1314941805.79.0.452688445055.issue12852@psf.upfronthosting.co.za> Remi Pointel added the comment: > R?mi : what happens if you manually add > extern DIR *fdopendir(int fd); > at the beginning of posixmodule.c? Hello, it seems to correctly work: ./python Lib/test/test_posix.py testNoArgFunctions (__main__.PosixTester) ... ok test_access (__main__.PosixTester) ... ok test_chdir (__main__.PosixTester) ... ok test_chflags (__main__.PosixTester) ... ok test_chown (__main__.PosixTester) ... ok test_confstr (__main__.PosixTester) ... ok test_cpu_set_basic (__main__.PosixTester) ... skipped "don't have sched affinity support" test_cpu_set_bitwise (__main__.PosixTester) ... skipped "don't have sched affinity support" test_cpu_set_cmp (__main__.PosixTester) ... skipped "don't have sched affinity support" test_dup (__main__.PosixTester) ... ok test_dup2 (__main__.PosixTester) ... ok test_environ (__main__.PosixTester) ... ok test_faccessat (__main__.PosixTester) ... ok test_fchmodat (__main__.PosixTester) ... ok test_fchown (__main__.PosixTester) ... ok test_fchownat (__main__.PosixTester) ... ok test_fdlistdir (__main__.PosixTester) ... ok test_fexecve (__main__.PosixTester) ... skipped 'test needs posix.fexecve()' test_fstat (__main__.PosixTester) ... ok test_fstatat (__main__.PosixTester) ... ok test_fstatvfs (__main__.PosixTester) ... ok test_ftruncate (__main__.PosixTester) ... ok test_futimens (__main__.PosixTester) ... ok test_futimes (__main__.PosixTester) ... ok test_futimesat (__main__.PosixTester) ... skipped 'test needs posix.futimesat()' test_get_and_set_scheduler_and_param (__main__.PosixTester) ... skipped "can't change scheduler" test_getcwd_long_pathnames (__main__.PosixTester) ... ok test_getgrouplist (__main__.PosixTester) ... ok test_getgroups (__main__.PosixTester) ... ok test_getresgid (__main__.PosixTester) ... ok test_getresuid (__main__.PosixTester) ... ok test_initgroups (__main__.PosixTester) ... ok test_lchflags_regular_file (__main__.PosixTester) ... skipped 'test needs os.lchflags()' test_lchflags_symlink (__main__.PosixTester) ... skipped 'test needs os.lchflags()' test_lchown (__main__.PosixTester) ... ok test_linkat (__main__.PosixTester) ... ok test_listdir (__main__.PosixTester) ... ok test_listdir_default (__main__.PosixTester) ... ok test_lockf (__main__.PosixTester) ... ok test_lutimes (__main__.PosixTester) ... skipped 'test needs posix.lutimes()' test_mkdirat (__main__.PosixTester) ... ok test_mkfifo (__main__.PosixTester) ... ok test_mkfifoat (__main__.PosixTester) ... ok test_mknod (__main__.PosixTester) ... ok test_mknodat (__main__.PosixTester) ... ok test_openat (__main__.PosixTester) ... ok test_oscloexec (__main__.PosixTester) ... ok test_osexlock (__main__.PosixTester) ... ok test_osshlock (__main__.PosixTester) ... ok test_pipe (__main__.PosixTester) ... ok test_pipe2 (__main__.PosixTester) ... skipped 'test needs os.pipe2()' test_posix_fadvise (__main__.PosixTester) ... skipped 'test needs posix.posix_fadvise()' test_posix_fallocate (__main__.PosixTester) ... skipped 'test needs posix.posix_fallocate()' test_pread (__main__.PosixTester) ... ok test_pwrite (__main__.PosixTester) ... ok test_readlinkat (__main__.PosixTester) ... ok test_readv (__main__.PosixTester) ... ok test_renameat (__main__.PosixTester) ... ok test_sched_affinity (__main__.PosixTester) ... skipped "don't have sched affinity support" test_sched_priority (__main__.PosixTester) ... ok test_sched_rr_get_interval (__main__.PosixTester) ... skipped 'no function' test_sched_yield (__main__.PosixTester) ... ok test_setresgid (__main__.PosixTester) ... ok test_setresgid_exception (__main__.PosixTester) ... ok test_setresuid (__main__.PosixTester) ... ok test_setresuid_exception (__main__.PosixTester) ... ok test_stat (__main__.PosixTester) ... ok test_statvfs (__main__.PosixTester) ... ok test_strerror (__main__.PosixTester) ... ok test_symlinkat (__main__.PosixTester) ... ok test_truncate (__main__.PosixTester) ... ok test_umask (__main__.PosixTester) ... ok test_unlinkat (__main__.PosixTester) ... ok test_utime (__main__.PosixTester) ... ok test_utimensat (__main__.PosixTester) ... ok test_waitid (__main__.PosixTester) ... skipped 'test needs posix.waitid()' test_writev (__main__.PosixTester) ... ok test_initgroups (__main__.PosixGroupsTester) ... skipped 'not enough privileges' test_setgroups (__main__.PosixGroupsTester) ... skipped 'not enough privileges' ---------------------------------------------------------------------- Ran 79 tests in 0.801s OK (skipped=17) And this command now works: $ ./python -c 'import os; print(os.fdlistdir(os.open("/tmp", os.O_RDONLY)))' ['.X11-unix', '.ICE-unix', 'orbit-remi', '.X0-lock', 'dbus-WWfX2JhDtb'] Attached file patch-Modules_posixmodule_c is the patch to do this. Thanks a lot, Remi. ---------- Added file: http://bugs.python.org/file23085/patch-Modules_posixmodule_c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 07:51:16 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 02 Sep 2011 05:51:16 +0000 Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled without threads In-Reply-To: <1314914769.65.0.203629815307.issue12871@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > It builds correctly with -pthread or -lpthread, but it fails to build without these options. > Not on Linux: this is specific to OpenBSD. > sched_get_priority_max() and sched_get_priority_min() come from libpthread on OpenBSD, whereas Python only checks for "#ifdef HAVE_SCHED_H". > That's exactly what I said in my previous message ;-) I'll post a patch later. ---------- title: Disable sched_get_priority_min/max on OpenBSD if Python is compiled without threads -> Disable sched_get_priority_min/max if Python is compiled without threads _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 08:02:17 2011 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 02 Sep 2011 06:02:17 +0000 Subject: [issue12850] [PATCH] stm.atomic In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za> Message-ID: <1314943337.88.0.944459476918.issue12850@psf.upfronthosting.co.za> Nick Coghlan added the comment: I quite like the last idea. Something like: _PyEval_SuspendOtherThreads(PyThreadState *tstate, PyThread_lock_type lock); All threads other than tstate will be prevented from executing further interpreter bytecodes until "lock" is released. Offering this API might pose a problem for various "superinstruction" concepts in the future, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 08:20:12 2011 From: report at bugs.python.org (Armin Rigo) Date: Fri, 02 Sep 2011 06:20:12 +0000 Subject: [issue12850] [PATCH] stm.atomic In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za> Message-ID: <1314944412.22.0.664387567438.issue12850@psf.upfronthosting.co.za> Armin Rigo added the comment: That's why I don't really know which concept is the best: the core of transactionmodule.c is just about one page in length, so there are only so many ways to split this code between CPython and the module... Attached the latest suggestion. I am also fine if this function is not called _PyEval_SuspendOtherThreads() but _PyEval_InternalUseOnlyYouShouldReallyNotUseThis()... ---------- Added file: http://bugs.python.org/file23086/stm3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 09:08:52 2011 From: report at bugs.python.org (Wong Wah Meng) Date: Fri, 02 Sep 2011 07:08:52 +0000 Subject: [issue12876] Make Test Error : ImportError: No module named _sha256 In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za> Message-ID: <1314947332.81.0.700619444059.issue12876@psf.upfronthosting.co.za> Wong Wah Meng added the comment: Hi there, thanks for the reply. I need a bit more clue on what else I can do, other than I have these 3 items in my checklist:- 1.) I will have HP-UX ANSI C/C++ Compiler soon. I can recompile using that compiler later if this is a gcc related thing. 2.) If I am not using my python to perform any SSL user authentication function, can I skip correcting this? 3.) I am still checking with my Unix admin on the OpenSSL Header and version thing. Will revert. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 09:29:06 2011 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 02 Sep 2011 07:29:06 +0000 Subject: [issue12876] Make Test Error : ImportError: No module named _sha256 In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za> Message-ID: <1314948546.61.0.926398182944.issue12876@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The setup.py script does not look correct when openssl is not installed: the _sha256 and _sha512 modules are compiled under this condition:: if COMPILED_WITH_PYDEBUG or openssl_ver < min_sha2_openssl_ver: By comparison, the _md5 module adds the condition: "or not have_usable_openssl" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 09:34:57 2011 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 02 Sep 2011 07:34:57 +0000 Subject: [issue12861] PyOS_Readline uses single lock In-Reply-To: <1314724555.55.0.18633205677.issue12861@psf.upfronthosting.co.za> Message-ID: <1314948897.48.0.91282151575.issue12861@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Well, readline is supposed to be used with a console, and there is only one usually. Why would you want to use readline from multiple threads? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 10:03:58 2011 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 02 Sep 2011 08:03:58 +0000 Subject: [issue12878] io.StringIO doesn't provide a __dict__ field In-Reply-To: <1314902829.02.0.266212831864.issue12878@psf.upfronthosting.co.za> Message-ID: <1314950638.74.0.530779647151.issue12878@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Actually it already fails with 3.1 (I tried "hg up v3.1") Then I played with "hg bisect", and unsurprisingly it answered: Traceback (most recent call last): File "", line 1, in AttributeError: '_io.StringIO' object has no attribute '__dict__' Changeset 51991:3049ac17e256: bad The first bad revision is: changeset: 51991:3049ac17e256 user: Benjamin Peterson date: Wed Mar 04 00:14:51 2009 +0000 summary: merge the io-c branch: C implementation of the io module ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 10:11:14 2011 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Sep 2011 08:11:14 +0000 Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled without threads In-Reply-To: Message-ID: <4E608F9E.7050407@haypocalc.com> STINNER Victor added the comment: >> It builds correctly with -pthread or -lpthread, but it fails to build without these options. >> > > Not on Linux: this is specific to OpenBSD. Oh, I forgot to specify: yes, I tested on OpenBSD (5.0). >> sched_get_priority_max() and sched_get_priority_min() come from libpthread on OpenBSD, whereas Python only checks for "#ifdef HAVE_SCHED_H". >> > > That's exactly what I said in my previous message ;-) > I'll post a patch later. Yep, it's just that I have the confirmation with my tests. ---------- title: Disable sched_get_priority_min/max if Python is compiled without threads -> Disable sched_get_priority_min/max if Python is compiled without threads _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 10:45:13 2011 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 02 Sep 2011 08:45:13 +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: <1314953113.14.0.595142481165.issue2636@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I think this is adding excessive complexity. It really depends on how many incompatible features there are, and how difficult it is to turn them on/off. > I think it is reasonable to pick a *set* of features as a whole It's probably more practical, but otherwise I'm not sure why you would want to activate 2-5 unrelated features that might require you to rewrite your regex (assuming you are aware of what the features are, what are their side effects, how to fix your regex) just because you need one. The idea is to make the transition smoother and not having a pre-regex world and an incompatible post-regex world, divided by a single flag. > If you don't want a feature, don't use it. With only one flag you are forced to enable all the new features, including the ones you don't want. > "Feature flags" leads to a combinational explosion that makes > comprehensive testing all but impossible. We already have several flags and the tests are working fine. If the features are orthogonal they can be tested independently. > The alternative is hard to track down bugs: > "this regular expression returns the wrong result, but only if you > have flags A, B and G turned on and C and F turned off." What about: "X works, Y works, and X|Y works, but when I use NEW flag to enable an inline flag X|Y stops to work while X and Y keep working" (hint: the NEW also enabled nested set -- see msg143333). I'm not saying that having multiple flag is the best solution (or even a viable one), but it should be considered depending on how many incompatible features there are and what they are. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 10:57:37 2011 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 02 Sep 2011 08:57:37 +0000 Subject: [issue11879] TarFile.chown: should use TarInfo.uid if user lookup fails In-Reply-To: <1303229015.7.0.433519463198.issue11879@psf.upfronthosting.co.za> Message-ID: <1314953857.45.0.85003213748.issue11879@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Issue #12841 is a duplicate of this one, but I give it precedence because it comes with a working patch. ---------- resolution: -> duplicate status: open -> closed versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 10:58:20 2011 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Fri, 02 Sep 2011 08:58:20 +0000 Subject: [issue12841] Incorrect tarfile.py extraction In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za> Message-ID: <1314953900.05.0.603929872296.issue12841@psf.upfronthosting.co.za> Changes by Lars Gust?bel : ---------- versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 12:04:02 2011 From: report at bugs.python.org (Michael Sulyaev) Date: Fri, 02 Sep 2011 10:04:02 +0000 Subject: [issue12883] xml.sax.xmlreader.AttributesImpl allows empty string as attribute names Message-ID: <1314957842.78.0.391568748992.issue12883@psf.upfronthosting.co.za> New submission from Michael Sulyaev : I can get not-well-formed XML output (attribute name must not be empty string): AttributeImpl must ignore dict entries that may not be cast to valid XML attributes. Code: #!/usr/bin/python from xml.sax.xmlreader import AttributesImpl as Attrs from xml.sax.saxutils import XMLGenerator as Gen g = Gen() a = Attrs(dict([('k1','v1'),('','v_for_empty_name')])) g.startDocument() g.startElement('root',a) g.endElement('root') g.endDocument() print ---------- components: XML messages: 143391 nosy: Michael.Sulyaev priority: normal severity: normal status: open title: xml.sax.xmlreader.AttributesImpl allows empty string as attribute names type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 12:05:15 2011 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 02 Sep 2011 10:05:15 +0000 Subject: [issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za> Message-ID: <1314957915.25.0.476621110173.issue12729@psf.upfronthosting.co.za> Ezio Melotti added the comment: > To start with, no code point which when bitwise added with 0xFFFE > returns 0xFFFE can never appear in a valid UTF-* stream, but Python > allow this without any error. > That means that both 0xNN_FFFE and 0xNN_FFFF are illegal in all > planes, where NN is 00 through 10 in hex. So that's 2 noncharacters > times 17 planes = 34 code points illegal for interchange that Python > is passing through illegally. > The remaining 32 nonsurrogate code points illegal for open interchange > are 0xFDD0 through 0xFDEF. Those are not allowed either, but Python > doesn't seem to care. It's not entirely clear to me what the UTF-8 codec is supposed to do with this. For example U+FFFE is in UTF-8, and this is valid according to table 3-7, Chapter 03[0]: """ Code points 1st byte 2nd byte 3rd byte U+E000..U+FFFF EE..EF 80..BF 80..BF """ Chapter 16, section 16.7 "Noncharacters" says[1]: """ Noncharacters are code points that are permanently reserved in the Unicode Standard for internal use. They are forbidden for use in open interchange of Unicode text data. """ and """ Applications are free to use any of these noncharacter code points internally but should never attempt to exchange them. """ seem to suggest that encoding them is forbidden. """ If a noncharacter is received in open interchange, an application is not required to interpret it in any way. It is good practice, however, to recognize it as a noncharacter and to take appropriate action, such as replacing it with U+FFFD replacement character, to indicate the problem in the text. It is not recommended to simply delete noncharacter code points from such text, because of the potential security issues caused by deleting uninterpreted characters. """ here decoding seems allowed, possibly with a replacement (that would depend on the error handler used though, so the default 'strict' would turn this in an error). Chapter 03, after D14, says: """ In general, a conforming process may indicate the presence of a code point whose use has not been designated (for example, by showing a missing glyph in rendering or by signaling an appropriate error in a streaming protocol), even though it is forbidden by the standard from interpreting that code point as an abstract character. """ and in C7: """ If a noncharacter that does not have a specific internal use is unexpectedly encountered in processing, an implementation may signal an error or replace the noncharacter with U+FFFD replacement character. If the implementation chooses to replace, delete or ignore a noncharacter, such an action constitutes a modification in the interpretation of the text. In general, a noncharacter should be treated as an unassigned code point. """ This doesn't mention clearly what the codec is supposed to do. On one hand, it suggests that an error can be raised, i.e. consider the noncharacter invalid like out-of-range codepoints (>U+10FFFF) or lone surrogates. On the other hand it says that they should be treated as an unassigned code point, i.e. encoded/decoded normally, and doesn't list them as invalid in table 3-7. [0]: http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf [1]: http://www.unicode.org/versions/Unicode6.0.0/ch16.pdf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 12:13:53 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 02 Sep 2011 10:13:53 +0000 Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0 In-Reply-To: <1314941805.79.0.452688445055.issue12852@psf.upfronthosting.co.za> Message-ID: <1314958278.3600.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > And this command now works: > > $ ./python -c 'import os; print(os.fdlistdir(os.open("/tmp", os.O_RDONLY)))' > ['.X11-unix', '.ICE-unix', 'orbit-remi', '.X0-lock', 'dbus-WWfX2JhDtb'] > > Attached file patch-Modules_posixmodule_c is the patch to do this. Thank you. It would be nice if you could find out in which header file fdopendir() is defined. A recursive grep in /usr/include (?) should do the trick, I think. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 12:15:00 2011 From: report at bugs.python.org (Doug Hellmann) Date: Fri, 02 Sep 2011 10:15:00 +0000 Subject: [issue12841] Incorrect tarfile.py extraction In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za> Message-ID: <1314958500.32.0.678587263571.issue12841@psf.upfronthosting.co.za> Changes by Doug Hellmann : ---------- nosy: +doughellmann _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 13:08:01 2011 From: report at bugs.python.org (Albert Zeyer) Date: Fri, 02 Sep 2011 11:08:01 +0000 Subject: [issue12861] PyOS_Readline uses single lock In-Reply-To: <1314724555.55.0.18633205677.issue12861@psf.upfronthosting.co.za> Message-ID: <1314961681.43.0.306435761339.issue12861@psf.upfronthosting.co.za> Albert Zeyer added the comment: You might have opened several via `openpty`. I am doing that here: https://github.com/albertz/PyTerminal ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 13:10:09 2011 From: report at bugs.python.org (sbt) Date: Fri, 02 Sep 2011 11:10:09 +0000 Subject: [issue12882] mmap crash on Windows In-Reply-To: <1314940631.31.0.750108382526.issue12882@psf.upfronthosting.co.za> Message-ID: <1314961809.47.0.471452903288.issue12882@psf.upfronthosting.co.za> sbt added the comment: You are not doing anything to stop the file object being garbage collected (and therefore closed) before the mmap is created. Try import os import mmap f = open(,"r+") size = os.path.getsize()) data = mmap.mmap(f.fileno(), size) ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 13:13:56 2011 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Sep 2011 11:13:56 +0000 Subject: [issue12882] mmap crash on Windows In-Reply-To: <1314940631.31.0.750108382526.issue12882@psf.upfronthosting.co.za> Message-ID: <1314962036.23.0.392328042732.issue12882@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 15:40:40 2011 From: report at bugs.python.org (VUIUI) Date: Fri, 02 Sep 2011 13:40:40 +0000 Subject: [issue12884] Re Message-ID: <1314970840.62.0.309443881007.issue12884@psf.upfronthosting.co.za> Changes by VUIUI : ---------- files: unnamed nosy: VUIUI priority: normal severity: normal status: open title: Re Added file: http://bugs.python.org/file23087/unnamed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 15:42:27 2011 From: report at bugs.python.org (VUIUI) Date: Fri, 02 Sep 2011 13:42:27 +0000 Subject: [issue12884] Re Message-ID: <1314970947.7.0.308226272992.issue12884@psf.upfronthosting.co.za> New submission from VUIUI : Botay ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 15:43:03 2011 From: report at bugs.python.org (VUIUI) Date: Fri, 02 Sep 2011 13:43:03 +0000 Subject: [issue12882] mmap crash on Windows In-Reply-To: <1314940631.31.0.750108382526.issue12882@psf.upfronthosting.co.za> Message-ID: <1314970983.73.0.601897414041.issue12882@psf.upfronthosting.co.za> VUIUI added the comment: Botay ---------- nosy: +VUIUI _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 15:44:23 2011 From: report at bugs.python.org (VUIUI) Date: Fri, 02 Sep 2011 13:44:23 +0000 Subject: [issue12884] Re In-Reply-To: <1314970947.7.0.308226272992.issue12884@psf.upfronthosting.co.za> Message-ID: <1314971063.92.0.575936633809.issue12884@psf.upfronthosting.co.za> VUIUI added the comment: hj ---------- components: +2to3 (2.x to 3.0 conversion tool) resolution: -> fixed type: -> crash versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 15:49:24 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 02 Sep 2011 13:49:24 +0000 Subject: [issue12882] mmap crash on Windows In-Reply-To: <1314940631.31.0.750108382526.issue12882@psf.upfronthosting.co.za> Message-ID: <1314971364.62.0.661722928344.issue12882@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- Removed message: http://bugs.python.org/msg143397 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 15:57:23 2011 From: report at bugs.python.org (Alexander Dutton) Date: Fri, 02 Sep 2011 13:57:23 +0000 Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x Message-ID: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za> New submission from Alexander Dutton : If there are any broken symlinks in the same directory as a setup.py when e.g. sdist is run, findall() will fall over when attempting to os.stat() the symlink: Traceback (most recent call last): File "setup.py", line 81, in run _sdist.run(self) File "/usr/lib/python2.6/distutils/command/sdist.py", line 144, in run self.get_file_list() File "/usr/lib/python2.6/distutils/command/sdist.py", line 238, in get_file_list self.filelist.findall() File "/usr/lib/python2.6/distutils/filelist.py", line 47, in findall self.allfiles = findall(dir) File "/usr/lib/python2.6/distutils/filelist.py", line 297, in findall stat = os.stat(fullname) OSError: [Errno 2] No such file or directory: 'debian/tmp/usr/share/somepath/somesymlink' Solutions would include replacing the call to os.stat() with one to os.lstat() (probably backwards-incompatible), or trying one and then the other. This bug is present in Pythons 2.6.6 (Debian 6.0.2) and 2.7 (Fedora 14). When attempting to reproduce in Python 3.1.2 (on Fedora) no error was encountered. However, looking at distutils/filelist.py, the same unadulterated call to os.stat() is present. I'll presume that for whatever reason distutils in Py3.1.2 never has cause to stat my broken symlink. ---------- assignee: tarek components: Distutils messages: 143399 nosy: Alexander.Dutton, eric.araujo, tarek priority: normal severity: normal status: open title: distutils.filelist.findall() fails on broken symlink in Py2.x type: behavior versions: Python 2.6, Python 2.7, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 16:19:21 2011 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 02 Sep 2011 14:19:21 +0000 Subject: [issue12884] Re In-Reply-To: <1314970947.7.0.308226272992.issue12884@psf.upfronthosting.co.za> Message-ID: <1314973161.7.0.42140970311.issue12884@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: -2to3 (2.x to 3.0 conversion tool) resolution: fixed -> invalid stage: -> committed/rejected status: open -> closed type: crash -> versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 16:33:27 2011 From: report at bugs.python.org (=?utf-8?q?Hei=C3=B0ar_Rafn_Har=C3=B0arson?=) Date: Fri, 02 Sep 2011 14:33:27 +0000 Subject: [issue12886] datetime.strptime parses input wrong Message-ID: <1314974007.55.0.285568781981.issue12886@psf.upfronthosting.co.za> New submission from Hei?ar Rafn Har?arson : When using datetime.strptime or time.strptime to parse string representing timestamp with the format string '%Y%m%dT%H%M%S' then a strange behavior happens when the input string does not contain the seconds: the minute part is split and first digit used as minutes and second digit as seconds ! According to documentation %M shall contain Minute as a decimal number [00,59] and %S shall contain Second as a decimal number [00,61] Here are few examples to show this: ------------------ Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.datetime.strptime('20110817T1234','%Y%m%dT%H%M%S') datetime.datetime(2011, 8, 17, 12, 3, 4) =>ERROR no seconds in input string: minute=3, second=4 =>I would expect exception ValueError or datetime.datetime(2011, 8, 17, 12, 34, 00) >>> datetime.datetime.strptime('20110817T123456','%Y%m%dT%H%M%S') datetime.datetime(2011, 8, 17, 12, 34, 56) =>CORRECT >>> datetime.datetime.strptime('20110817T123456','%Y%m%dT%H%M') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.6/_strptime.py", line 328, in _strptime data_string[found.end():]) ValueError: unconverted data remains: 56 =>CORRECT >>> datetime.datetime.strptime('20110817T1234','%Y%m%dT%H%M') datetime.datetime(2011, 8, 17, 12, 34) => CORRECT ------------------ I have tested this with python 2.6 and 2.7 This also happens on when playing with %H%M format string and omit minutes from the input. ---------- components: Library (Lib) messages: 143400 nosy: heidar.rafn priority: normal severity: normal status: open title: datetime.strptime parses input wrong type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 16:50:24 2011 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Sep 2011 14:50:24 +0000 Subject: [issue12886] datetime.strptime parses input wrong In-Reply-To: <1314974007.55.0.285568781981.issue12886@psf.upfronthosting.co.za> Message-ID: <1314975024.26.0.793023160684.issue12886@psf.upfronthosting.co.za> STINNER Victor added the comment: > ERROR no seconds in input string: minute=3, second=4 If you specificy "%S" in the format string, strptime() *requires* seconds. If seconds are optional in your format, you should call strptime() twice: first without '%S', then with '%S' if the first failed. I don't consider your examples as bugs. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 16:54:19 2011 From: report at bugs.python.org (STINNER Victor) Date: Fri, 02 Sep 2011 14:54:19 +0000 Subject: [issue12886] datetime.strptime parses input wrong In-Reply-To: <1314974007.55.0.285568781981.issue12886@psf.upfronthosting.co.za> Message-ID: <1314975259.12.0.675192176707.issue12886@psf.upfronthosting.co.za> STINNER Victor added the comment: Example: --- import datetime def test(text): try: d = datetime.datetime.strptime(text, '%Y%m%dT%H%M') except ValueError: pass else: print("%s without seconds => %s" % (text, d)) return d = datetime.datetime.strptime(text, '%Y%m%dT%H%M%S') print("%s with seconds => %s" % (text, d)) test('20110817T1234') test('20110817T12345') test('20110817T123456') --- Output: 20110817T1234 without seconds => 2011-08-17 12:34:00 20110817T12345 with seconds => 2011-08-17 12:34:05 20110817T123456 with seconds => 2011-08-17 12:34:56 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 17:42:48 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 15:42:48 +0000 Subject: [issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib, test_imp, test_distutils, test_packaging, test_runpy, test_import In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za> Message-ID: <1314978168.69.0.282803130165.issue12117@psf.upfronthosting.co.za> ?ric Araujo added the comment: Is this still relevant? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 17:45:02 2011 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 Sep 2011 15:45:02 +0000 Subject: [issue10454] Clarify compileall command-line options In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 755a57f987ca by ?ric Araujo in branch '3.2': #10454: a few edits to compileall help messages http://hg.python.org/cpython/rev/755a57f987ca New changeset 892e0ee4ca32 by ?ric Araujo in branch 'default': Merge doc changes from 3.2 (#10454, #12298) http://hg.python.org/cpython/rev/892e0ee4ca32 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 17:45:02 2011 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 Sep 2011 15:45:02 +0000 Subject: [issue12298] Sphinx glitch in library/functions In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 7a05cb3beddf by ?ric Araujo in branch '3.2': Fix a few links in the table of built-in functions (#12298) http://hg.python.org/cpython/rev/7a05cb3beddf New changeset 58dd7addef3a by ?ric Araujo in branch '3.2': Add links from library/functions to other docs. http://hg.python.org/cpython/rev/58dd7addef3a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:03:04 2011 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 Sep 2011 16:03:04 +0000 Subject: [issue10454] Clarify compileall command-line options In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 4ae85348e3e8 by ?ric Araujo in branch '2.7': Clarify compileall command-line options (#10454). http://hg.python.org/cpython/rev/4ae85348e3e8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:05:23 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:05:23 +0000 Subject: [issue10191] scripts files are not RECORDed. In-Reply-To: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za> Message-ID: <1314979523.53.0.394351587879.issue10191@psf.upfronthosting.co.za> ?ric Araujo added the comment: I have added tests for scripts in RECORD and they pass. Closing, please reopen if you can reproduce the bug. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:07:42 2011 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 02 Sep 2011 16:07:42 +0000 Subject: [issue12882] mmap crash on Windows In-Reply-To: <1314940631.31.0.750108382526.issue12882@psf.upfronthosting.co.za> Message-ID: <1314979662.98.0.797730546056.issue12882@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Is it a crash, or do you get a exception with a nice message? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:10:00 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:10:00 +0000 Subject: [issue8754] quote bad module name in ImportError-like messages In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za> Message-ID: <1314979800.54.0.477715158265.issue8754@psf.upfronthosting.co.za> ?ric Araujo added the comment: Victor changed ImportError some time ago for #3080, so my patch now only touches a few stdlib modules. ---------- components: +Library (Lib) -Interpreter Core title: ImportError: quote bad module name in message -> quote bad module name in ImportError-like messages Added file: http://bugs.python.org/file23088/import-repr-lib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:13:48 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:13:48 +0000 Subject: [issue12840] "maintainer" value clear the "author" value when register In-Reply-To: <1314256955.86.0.420020912731.issue12840@psf.upfronthosting.co.za> Message-ID: <1314980028.64.0.0804117818714.issue12840@psf.upfronthosting.co.za> ?ric Araujo added the comment: This was already explained in #962772. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed superseder: -> when both maintainer and author provided, author discarded _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:15:08 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:15:08 +0000 Subject: [issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid) In-Reply-To: <1306440850.45.0.221932335134.issue12191@psf.upfronthosting.co.za> Message-ID: <1314980108.65.0.875288610646.issue12191@psf.upfronthosting.co.za> ?ric Araujo added the comment: I have added 'chown' in shutil.__all__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:20:05 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:20:05 +0000 Subject: [issue12884] Re In-Reply-To: <1314970947.7.0.308226272992.issue12884@psf.upfronthosting.co.za> Message-ID: <1314980405.55.0.405499521174.issue12884@psf.upfronthosting.co.za> Changes by ?ric Araujo : Removed file: http://bugs.python.org/file23087/unnamed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:20:15 2011 From: report at bugs.python.org (Bill Janssen) Date: Fri, 02 Sep 2011 16:20:15 +0000 Subject: [issue6560] socket sendmsg(), recvmsg() methods In-Reply-To: <1314293281.07.0.192116643154.issue6560@psf.upfronthosting.co.za> Message-ID: Bill Janssen added the comment: I'll take a look at this next week, when I'm more on-line again. Bill 2011/8/25 Charles-Fran?ois Natali : > > Charles-Fran?ois Natali added the comment: > >> The OS X buildbots show some failures: > > It seems to fail consistently on every OS X version. > I've had another look both at the code and the test, and couldn't find anything wrong with it. > Since there are a number of known bugs pertaining to FD passing on OS X - even on recent versions - I'd suggest to skip those tests on this platform. > As for sendto/sendmsg not being interrupted by the signal, I'd be curious to see if running test_socket alone solves the problem (just to make sure no other thread is running, which might receive the signal). > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:44:41 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:44:41 +0000 Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za> Message-ID: <1314981881.04.0.868522364253.issue12885@psf.upfronthosting.co.za> ?ric Araujo added the comment: Symlinks are barely supported by distutils; the only mention you can find in the doc is that the MANIFEST file can contain symlinks. In the light of that, one could argue that broken symlinks are not supported nor ignored, and that you just should not have them. Is there a valid use case for having broken symlinks in a Python project? (About versions: I?m removing 2.6 which only gets security fixes, and adding 3.x to add regression tests to them, even if the bug isn?t there now.) ---------- components: +Distutils2 nosy: +alexis versions: +3rd party, Python 3.2, Python 3.3 -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:54:06 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:54:06 +0000 Subject: [issue12298] Sphinx glitch in library/functions In-Reply-To: <1307635612.57.0.782200385704.issue12298@psf.upfronthosting.co.za> Message-ID: <1314982446.23.0.606221638308.issue12298@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I agree that all table entries should link to the entry in the same file. This is fixed in 3.2 and 3.3, with a bit of reST kludgery. I?ll backport to 2.7 if there is no negative feedback. > range() definitely needs a forward reference to 4.6 sequence types > bool() lacks forward references; it could have one to 4.2 Bool ops and 4.11.9 Bool values I have added links in a subsequent commit. > object() -- no where to go. > type(n,b,d) has no forward references as there is no where to go exactly I think this deserves another report. > slice() only has a reference to the glossary; it has no entry in Ch.4. "Slice objects have > read-only data attributes start, stop and step which merely return the argument values (or > their default). They have no other explicit functionality" is slightly wrong since there > is the .indices method. Ditto. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:55:25 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:55:25 +0000 Subject: [issue12862] ConfigParser does not implement "comments need to be preceded by a whitespace character" correctly In-Reply-To: <1314725453.99.0.502494798896.issue12862@psf.upfronthosting.co.za> Message-ID: <1314982525.77.0.160603044704.issue12862@psf.upfronthosting.co.za> ?ric Araujo added the comment: (Adding 3.x versions because we?ll want to add tests to them.) ---------- nosy: +eric.araujo, lukasz.langa versions: +Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:56:08 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:56:08 +0000 Subject: [issue12860] http client attempts to send a readable object twice In-Reply-To: <1314723930.88.0.607695250414.issue12860@psf.upfronthosting.co.za> Message-ID: <1314982568.4.0.848940647965.issue12860@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:58:52 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:58:52 +0000 Subject: [issue12863] py32 > Lib > xml.minidom > usage feedback > overrides In-Reply-To: <1314730258.77.0.934592208452.issue12863@psf.upfronthosting.co.za> Message-ID: <1314982732.14.0.55069176999.issue12863@psf.upfronthosting.co.za> ?ric Araujo added the comment: For general discussion or questions about usage, you are welcome to use mailing lists such as python-list and xml-sig. This tracker is dedicated to bug reports and feature requests, and unless I?m misreading your report contains neither, so I?m closing it. Have fun with Python and XML! ---------- nosy: +eric.araujo resolution: -> invalid stage: -> committed/rejected status: open -> closed versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 18:59:43 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 16:59:43 +0000 Subject: [issue12864] 2to3 creates illegal code on import a.b inside a package In-Reply-To: <1314741561.82.0.752843827348.issue12864@psf.upfronthosting.co.za> Message-ID: <1314982783.23.0.722546495961.issue12864@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +benjamin.peterson stage: -> needs patch versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:04:15 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 17:04:15 +0000 Subject: [issue12866] Want to submit our Audioop.c patch for 24bit audio In-Reply-To: <1314744712.67.0.770855933698.issue12866@psf.upfronthosting.co.za> Message-ID: <1314983055.6.0.376897228734.issue12866@psf.upfronthosting.co.za> ?ric Araujo added the comment: Welcome and thanks for your contribution! If I understand correctly, support for 24-bit files would be a new feature for audioop, so our development policy excludes 2.7, a stable release which only gets bug fixes. If you would like to turn your code into a patch (see guidelines in the devguide), it could be considered for inclusion in the next version. If you think your improvements would be useful for 2.7 users, you could rename your module to audioop2 and publish it on PyPI (pay attention to proper attribution and licensing). Feel free to ask any question! :) ---------- nosy: +eric.araujo versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:06:43 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 17:06:43 +0000 Subject: [issue12873] 2to3 incorrectly handles multi-line imports from __future__ In-Reply-To: <1314827841.27.0.752701109449.issue12873@psf.upfronthosting.co.za> Message-ID: <1314983203.35.0.119412683363.issue12873@psf.upfronthosting.co.za> ?ric Araujo added the comment: I don?t understand what the bug is. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:08:34 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 17:08:34 +0000 Subject: [issue12875] backport re.compile flags default value documentation In-Reply-To: <1314854228.49.0.163476055978.issue12875@psf.upfronthosting.co.za> Message-ID: <1314983314.9.0.117744460503.issue12875@psf.upfronthosting.co.za> ?ric Araujo added the comment: +1 to backporting [flags=0]. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:12:55 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 17:12:55 +0000 Subject: [issue12876] Make Test Error : ImportError: No module named _sha256 In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za> Message-ID: <1314983575.66.0.0390112452189.issue12876@psf.upfronthosting.co.za> ?ric Araujo added the comment: > 1.) I will have HP-UX ANSI C/C++ Compiler soon. I can recompile using > that compiler later if this is a gcc related thing. On the contrary, Gregory said that gcc should work (it?s what most of us use, I think). > 2.) If I am not using my python to perform any SSL user authentication function, > can I skip correcting this? This bug is about hashlib (http://docs.python.org/2.7/library/hashlib), a module providing checksum functions. It is not related to SSL, but merely uses code from the OpenSSL project. > The setup.py script does not look correct when openssl is not installed: The full openssl or only headers? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:13:57 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 17:13:57 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1314983637.55.0.790506500894.issue4153@psf.upfronthosting.co.za> ?ric Araujo added the comment: > something about Unicode supports in the re module (this probably can > wait after the 'regex' inclusion). I?d prefer documentation for the re module now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:38:28 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 17:38:28 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1314985108.53.0.427698864143.issue4153@psf.upfronthosting.co.za> ?ric Araujo added the comment: > it also removes the usage of 'byte string'. I see you?ve replaced it with ?byte object?. I?m -0, as ?byte[s] string? is not ambiguous IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:40:14 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 17:40:14 +0000 Subject: [issue1170] shlex have problems with parsing unicode In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za> Message-ID: <1314985214.83.0.487891133613.issue1170@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- components: +Documentation -Library (Lib), Unicode keywords: +easy stage: test needed -> needs patch versions: +Python 2.7 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:40:22 2011 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 02 Sep 2011 17:40:22 +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: <1314985222.1.0.38352557658.issue2636@psf.upfronthosting.co.za> Matthew Barnett added the comment: The least disruptive change would be to have a NEW flag for the new behaviour, as at present, and an OLD flag for the old behaviour. Currently the default is old behaviour, but in the future it will be new behaviour. The differences would be: Old behaviour : New behaviour ------------- ------------- Global inline flags : Positional inline flags Can't split on zero-width match : Can split on zero-width match Simple sets : Nested sets and set operations The only change would be that nested sets wouldn't be supported in the old behaviour. There are also additional escape sequences, eg \X is no longer treated as "X", but as they look like escape sequences you really shouldn't be relying on that. (It's similar to writing Windows paths in non-raw string literals: "\T" == "\\T", but "\t" == chr(9).) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:42:14 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 17:42:14 +0000 Subject: [issue4256] argparse: provide a simple way to get a programmatically useful list of options In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za> Message-ID: <1314985334.55.0.53888504809.issue4256@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- title: optparse/argparse: provide a simple way to get a programmatically useful list of options -> argparse: provide a simple way to get a programmatically useful list of options versions: +Python 3.3 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:44:30 2011 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 02 Sep 2011 17:44:30 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1314985470.66.0.538445778546.issue4153@psf.upfronthosting.co.za> Ezio Melotti added the comment: There was some discussion a while ago on python-dev about it. AFAIR the outcome was that using "bytes *strings*" should be avoided because bytes are bytes, and not strings (until they get decoded at least). Using 'string' for both might lead people to think that there are two kinds of strings, bytes and Unicode (like in python 2) while they should think that there are only Unicode strings and they can be converted to a bytes object (or simply to 'bytes'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:52:25 2011 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 02 Sep 2011 17:52:25 +0000 Subject: [issue12873] 2to3 incorrectly handles multi-line imports from __future__ In-Reply-To: <1314827841.27.0.752701109449.issue12873@psf.upfronthosting.co.za> Message-ID: <1314985945.93.0.167754599301.issue12873@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: If import from __future__ is written in multiple lines, then a parser internally used by 2to3 recognizes only the first line. (However Python interpreter properly supports multi-line imports from __future__.) test1.py contains multi-line import from __future__. test2.py contains single-line import from __future__. 2to3 properly handles test2.py and improperly handles test1.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 19:58:08 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 02 Sep 2011 17:58:08 +0000 Subject: [issue4153] Unicode HOWTO up to date? In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za> Message-ID: <1314986288.86.0.429796961047.issue4153@psf.upfronthosting.co.za> ?ric Araujo added the comment: Ah, I see: you?re equating ?string? with ?text string? or ?character string?, whereas I read ?bytes string? as ?finite sequence of bytes?. With this definition, there *are* two string types in Python 3, it?s just that they?re much more divorced than in 2.x. > they should think that there are only Unicode strings I?d say they should think that text processing should only happen with the one type dedicated to text, i.e. str. > they can be converted to a bytes object (or simply to 'bytes') Okay, +0 to use only ?bytes object? (or ?bytes? when it sounds better). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 20:09:55 2011 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 Sep 2011 18:09:55 +0000 Subject: [issue12781] Mention SO_REUSEADDR near socket doc examples In-Reply-To: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset fe60689d6a2e by Sandro Tosi in branch '2.7': #12781: Mention SO_REUSEADDR flag near socket examples http://hg.python.org/cpython/rev/fe60689d6a2e New changeset c4588cd2d59a by Sandro Tosi in branch '3.2': #12781: Mention SO_REUSEADDR flag near socket examples http://hg.python.org/cpython/rev/c4588cd2d59a New changeset eb9a9a043f13 by Sandro Tosi in branch 'default': #12781: merge with 3.2 http://hg.python.org/cpython/rev/eb9a9a043f13 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 20:10:41 2011 From: report at bugs.python.org (Sandro Tosi) Date: Fri, 02 Sep 2011 18:10:41 +0000 Subject: [issue12781] Mention SO_REUSEADDR near socket doc examples In-Reply-To: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za> Message-ID: <1314987041.68.0.147065998954.issue12781@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 Fri Sep 2 20:13:00 2011 From: report at bugs.python.org (Sandro Tosi) Date: Fri, 02 Sep 2011 18:13:00 +0000 Subject: [issue12887] Documenting all SO_* constants in socket module Message-ID: <1314987180.49.0.607596056761.issue12887@psf.upfronthosting.co.za> New submission from Sandro Tosi : spinning off msg142613 - it would be interesting to have in the socket module documentation also an explanation of all the several SO_ flags available; even a compact table could be ok; or even a link to a remote reference for them. ---------- assignee: docs at python components: Documentation messages: 143428 nosy: docs at python, eric.araujo, ezio.melotti, sandro.tosi priority: normal severity: normal stage: needs patch status: open title: Documenting all SO_* constants in socket module versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 20:21:02 2011 From: report at bugs.python.org (Sebastian Wiesner) Date: Fri, 02 Sep 2011 18:21:02 +0000 Subject: [issue12873] 2to3 incorrectly handles multi-line imports from __future__ In-Reply-To: <1314827841.27.0.752701109449.issue12873@psf.upfronthosting.co.za> Message-ID: <1314987662.09.0.736620472759.issue12873@psf.upfronthosting.co.za> Sebastian Wiesner added the comment: More precisely, the bug is, that 2to3 refactors the "print()" invocation in "test1.py" though it shouldn't because a "print_function" future import is present at the beginning of "test1.py". The cross-check with "test2.py" shows that this is due to the multi-line future import in "test1.py" because the line-break in the import statement is the only difference between both files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 20:44:13 2011 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 Sep 2011 18:44:13 +0000 Subject: [issue12764] segfault in ctypes.Struct with bad _fields_ In-Reply-To: <1313526117.08.0.584705454362.issue12764@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset b8acee08283c by Amaury Forgeot d'Arc in branch '3.2': Issue #12764: Fix a crash in ctypes when the name of a Structure field is not http://hg.python.org/cpython/rev/b8acee08283c New changeset 1ed1ea0f4cd8 by Amaury Forgeot d'Arc in branch 'default': Merge from 3.2: Issue #12764: Fix a crash in ctypes when the name of a http://hg.python.org/cpython/rev/1ed1ea0f4cd8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 20:44:16 2011 From: report at bugs.python.org (Roundup Robot) Date: Fri, 02 Sep 2011 18:44:16 +0000 Subject: [issue12764] segfault in ctypes.Struct with bad _fields_ In-Reply-To: <1313526117.08.0.584705454362.issue12764@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 73827c23cdde by Amaury Forgeot d'Arc in branch '2.7': Issue #12764: Fix a crash in ctypes when the name of a Structure field is not http://hg.python.org/cpython/rev/73827c23cdde ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 21:24:23 2011 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 02 Sep 2011 19:24:23 +0000 Subject: [issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za> Message-ID: <1314991463.17.0.368545554887.issue12729@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ezio, that is a lot of nice work to track down those pieces of the standard. I think the operative phrase in many of those quotes is 'open interchange'. Codecs are also used for private storage. If I use the unassigned or private-use code points in a private project, I would use utf-8 to save the work between active sessions. That is quite fine under the standard. But I should not put files with such codings on the net for 'open interchange'. And if I receive them, the one thing I should not do is interpret them as meaningful abstract characters. So the codec should allow for both public and private use. I have the impression that is does so now. A Python programmer should know whether the codec is being used for private (or local group) files or random stuff from the net, and therefore, what the appropriate error handling is. If they do not now, the docs could suggest that public text should normally be decoded with 'strict' or 'replace' and that 'ignore' should normally be reserved for local text that is known to intentionally have 'errors'. I am pretty sure that the intent of prohibiting non-standard interpretation of code points as abstract characters is to prevent 'organic' evolution of the code point -- abstract character mapping in which anyone (or any company) who wants to do so creates a new pairing and promotes its wide recognition around the world. Conforming implementations are strict in both what they produce (publicly) *and* in what they accept (from public sources). Many now think that liberal acceptance of sloppy html promoted sloppy production of html. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 21:28:47 2011 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 02 Sep 2011 19:28:47 +0000 Subject: [issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug In-Reply-To: <1314991463.17.0.368545554887.issue12729@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: > So the codec should allow for both public and private use. IIUC we have (or are planning) codecs that support the private use. They are not called "utf-8" though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 23:08:40 2011 From: report at bugs.python.org (Yves Dorfsman) Date: Fri, 02 Sep 2011 21:08:40 +0000 Subject: [issue12888] html.parser.HTMLParser.unescape works only with the first 128 entities Message-ID: <1314997720.87.0.621504034674.issue12888@psf.upfronthosting.co.za> New submission from Yves Dorfsman : html.parser.HTMLParser.unescape works only with the first 128 entities, it leaves the other ones as they are. ---------- components: None messages: 143434 nosy: yves at zioup.com priority: normal severity: normal status: open title: html.parser.HTMLParser.unescape works only with the first 128 entities versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 23:11:58 2011 From: report at bugs.python.org (Brett Cannon) Date: Fri, 02 Sep 2011 21:11:58 +0000 Subject: [issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib, test_imp, test_distutils, test_packaging, test_runpy, test_import In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za> Message-ID: <1314997918.28.0.0955108560935.issue12117@psf.upfronthosting.co.za> Brett Cannon added the comment: Unless someone cares enough to decorate the tests that should not write the bytecode (I think I have one such decorator in the importlib tests, but I think it is more for other VMs than for this situation) then I wouldn't worry about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 23:12:37 2011 From: report at bugs.python.org (Remi Pointel) Date: Fri, 02 Sep 2011 21:12:37 +0000 Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0 In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za> Message-ID: <1314997957.3.0.142809321598.issue12852@psf.upfronthosting.co.za> Remi Pointel added the comment: > It would be nice if you could find out in which header file fdopendir() is defined. Hi, fdopendir() is in /usr/include/dirent.h: #if __POSIX_VISIBLE >= 200809 DIR *fdopendir(int); #endif You could find the file dirent.h here: http://www.openbsd.org/cgi-bin/cvsweb/src/include/dirent.h. Thanks, Remi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 23:25:35 2011 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 02 Sep 2011 21:25:35 +0000 Subject: [issue12862] ConfigParser does not implement "comments need to be preceded by a whitespace character" correctly In-Reply-To: <1314725453.99.0.502494798896.issue12862@psf.upfronthosting.co.za> Message-ID: <1314998735.87.0.257093821691.issue12862@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Daniel, thank you for your report. Indeed, 3.2+ has an updated configparser where we turned off support for inline comments (e.g. comments after option values). This was decided after we discovered how inconsistent it is. Your report shows this decision was the right one. As for 2.7 unfortunately it's long in maintenance mode now so no functional changes are possible. I've prepared a backport of the 3.2+ configparser for 2.6+. It is available on PyPI: http://pypi.python.org/pypi/configparser. Have a look, might solve your problem (and quite a bunch of others I suppose). ?ric, the docs clearly state that currently only full-line comments are enabled by default. ---------- resolution: -> wont fix stage: -> committed/rejected status: open -> closed versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 23:26:12 2011 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Fri, 02 Sep 2011 21:26:12 +0000 Subject: [issue12881] ctypes: segfault with large structure field names In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za> Message-ID: <1314998772.2.0.426526514917.issue12881@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Certainly the effect of some "alloca" call with a large value, then the stack overflows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 2 23:41:06 2011 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 02 Sep 2011 21:41:06 +0000 Subject: [issue12850] [PATCH] stm.atomic In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za> Message-ID: <1314999666.26.0.27436036689.issue12850@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Semi-seriously, _PyEval_ForArminRigoOnly_ /* This function does whatever Armin Rigo wants it to do. He may change it at any time. Do not use it. */ This would let you experiment with the boundary as you will (with review, of course) and relieve us of any obligation to anyone else who uses it. CPython got the Don Beaudry metaclass hook sometime before 1.5. (I have no idea of its internal name or implementation.) It was also used, at his own risk, by Jim Fulton. Much later, in 2.2, it because the basis for new-style classes, which are now simply Python 3 classes. http://www.python.org/doc/essays/metaclasses/ ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 00:00:37 2011 From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=) Date: Fri, 02 Sep 2011 22:00:37 +0000 Subject: [issue12844] Support more than 255 arguments In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za> Message-ID: <1315000837.9.0.517980613171.issue12844@psf.upfronthosting.co.za> Andreas St?hrk added the comment: Attached is a patch that removes the limit and that allows passing an arbitrary number of positional and keyword arguments. Lacks tests for now. ---------- keywords: +patch nosy: +Trundle Added file: http://bugs.python.org/file23089/issue12844_arbitrary_arguments.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 00:25:39 2011 From: report at bugs.python.org (Meador Inge) Date: Fri, 02 Sep 2011 22:25:39 +0000 Subject: [issue12881] ctypes: segfault with large structure field names In-Reply-To: <1314998772.2.0.426526514917.issue12881@psf.upfronthosting.co.za> Message-ID: Meador Inge added the comment: On Fri, Sep 2, 2011 at 4:26 PM, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc added the comment: > > Certainly the effect of some "alloca" call with a large value, then the stack overflows. Yeah, I noticed that too. I was actually pretty surprised to see "alloca" in there :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 00:39:51 2011 From: report at bugs.python.org (Vlastimil Brom) Date: Fri, 02 Sep 2011 22:39:51 +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: <1315003191.36.0.590348799185.issue2636@psf.upfronthosting.co.za> Vlastimil Brom added the comment: I'd agree with Steven ( msg143377 ) and others, that there probably shouldn't be a large library-specific set of new tags just for "housekeeping" purposes between re and regex. I would personally prefer, that these tags also be settable in the pattern (?...), which would probably be problematic with versioned flags. Although I am trying to take advantage of the new additions, if applicable, I agree, that there should be a possibility to use regex in an unreflected way with the same behaviour like re (maybe except for the fixes of what will be agreed on to be a bug (enough)). On the other hand, it seems to me, that the enhancements/additions can be enabled at once, as an user upgrading the regexes for the new library consciously (or a new user not knowing re) can be supposed to know the new features and their implications. I guess, it is mostly trivially possible to fix/disambiguate the problematic patterns, e.g. by escaping. As for setting the new/old behaviour, would there be a possibility to distinguish it just by importing (possibly through some magic, without the need to duplicate the code?), import re_in_compat_mode as re vs: import re_with_all_the_new_features as re Unfortunately, i have no idea, whether this is possible or viable... with this option, the (user) code update could be just the change of the imports instead of adding the flags to all relevant places (and to take them away as redundant, as the defaults evolve with the versions...). However, it is not clear, how this "aliasing" would work out with regard to the transition, maybe the long differenciated "module" names could be kept and the meaning of "import re" would change, allong with the previous warnings, in some future version. just a few thoughts... vbr ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 01:07:33 2011 From: report at bugs.python.org (=?utf-8?q?Dr=2E_Georg_Str=C3=B6hlein?=) Date: Fri, 02 Sep 2011 23:07:33 +0000 Subject: [issue12889] struct.pack('d'... problem Message-ID: <1315004853.67.0.138940038832.issue12889@psf.upfronthosting.co.za> New submission from Dr. Georg Str?hlein : Hi all, I think there is a long-standing bug (it has made it into books on Google...) in the struct.pack() function, at least if the 'd' format string is selected. On both Win and Ubuntu the string returned for pack('!d',1.2345) is '?\xf3\xc0\x83\x12n\x97\x8d', whereas the correct 8 (!!) bytes are 3F F3 C0 83 12 6E 97 8D. Link to a published VBA UDF for Excel is in the file; that UDF reproduces the examples given in wikipedia on the IEEE 754 / DP pages correctly. Regards, Schorsch ---------- files: python-error.txt messages: 143443 nosy: SchorschMCMLX priority: normal severity: normal status: open title: struct.pack('d'... problem type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file23090/python-error.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 01:15:20 2011 From: report at bugs.python.org (=?utf-8?q?Dr=2E_Georg_Str=C3=B6hlein?=) Date: Fri, 02 Sep 2011 23:15:20 +0000 Subject: [issue12889] struct.pack('d'... problem In-Reply-To: <1315004853.67.0.138940038832.issue12889@psf.upfronthosting.co.za> Message-ID: <1315005320.88.0.81705808546.issue12889@psf.upfronthosting.co.za> Dr. Georg Str?hlein added the comment: link is here: http://carolomeetsbarolo.files.wordpress.com/2011/08/double_2_hex.pdf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 02:17:40 2011 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 03 Sep 2011 00:17:40 +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: <1315009060.51.0.862990737924.issue2636@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Being able to set which behavior you want in a (?XXX) flag at the start of the regex is valuable so that applications that take a regex can support the new syntax automatically when the python version they are running on is updated. The (?XXX) should override whatever re.XXX flag was provided to re.compile(). Notice I said XXX. I'm not interested in a naming bikeshed other than agreeing with the fact that NEW will seem quaint 10 years from now so its best to use non-temporal names. COMPAT, VERSION2, VERSION3, WITH_GOATS, PONY, etc. are all non-temporal and do allow us to change the default away from "old" behavior at a future date beyond 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 02:28:03 2011 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 03 Sep 2011 00:28:03 +0000 Subject: [issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za> Message-ID: <1315009683.69.0.880749172262.issue12729@psf.upfronthosting.co.za> Ezio Melotti added the comment: Or they are still called UTF-8 but used in combination with different error handlers, like surrogateescape and surrogatepass. The "plain" UTF-* codecs should produce data that can be used for "open interchange", rejecting all the invalid data, both during encoding and decoding. Chapter 03, D79 also says: """ To ensure that the mapping for a Unicode encoding form is one-to-one, all Unicode scalar values, including those corresponding to noncharacter code points and unassigned code points, must be mapped to unique code unit sequences. Note that this requirement does not extend to high-surrogate and low-surrogate code points, which are excluded by definition from the set of Unicode scalar values. """ and this seems to imply that the only unencodable codepoint are the non-scalar values, i.e. surrogates and codepoints >U+10FFFF. Noncharacters shouldn't thus receive any special treatment (at least during encoding). Tom, do you agree with this? What does Perl do with them? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 02:30:51 2011 From: report at bugs.python.org (Matthew Barnett) Date: Sat, 03 Sep 2011 00:30:51 +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: <1315009851.39.0.824707935624.issue2636@psf.upfronthosting.co.za> Matthew Barnett added the comment: So, VERSION0 and VERSION1, with "(?V0)" and "(?V1)" in the pattern? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 02:32:21 2011 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 03 Sep 2011 00:32:21 +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: <1315009941.95.0.932075875843.issue2636@psf.upfronthosting.co.za> Ezio Melotti added the comment: If these are the only 3 non-backward compatible features and the nested set one is moved under the NEW flag, I guess the approach might work without having per-feature flags. The "NEW" could be kept for compatibility for regex (if necessary), possibly aliasing it with VERSION1 or whatever name wins the bikeshed. If you want to control that at import time, maybe a from __future__ import new_re_semantics could be used instead of a flag, but I'm not sure about that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 04:22:01 2011 From: report at bugs.python.org (Jeff McNeil) Date: Sat, 03 Sep 2011 02:22:01 +0000 Subject: [issue12890] cgitb displays

tags when executed in text mode Message-ID: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za> New submission from Jeff McNeil : If cgitb.enable is ran with a logdir set and a format='text' argument, then a trailing message is printed that includes

tags. This should only happen if the format requested is HTML. The following tiny script shows the problem: import cgitb cgitb.enable(format='text', logdir='/tmp') 1/0 Attaching a small patch which addresses. This is against tip on the default branch. mcjeff at macbook:~/cpython$ ./python.exe --version Python 3.3.0a0 ---------- components: Library (Lib) files: head-cgitb-display.patch keywords: patch messages: 143449 nosy: mcjeff priority: normal severity: normal status: open title: cgitb displays

tags when executed in text mode versions: Python 3.3 Added file: http://bugs.python.org/file23091/head-cgitb-display.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 05:26:48 2011 From: report at bugs.python.org (Meador Inge) Date: Sat, 03 Sep 2011 03:26:48 +0000 Subject: [issue12764] segfault in ctypes.Struct with bad _fields_ In-Reply-To: <1313526117.08.0.584705454362.issue12764@psf.upfronthosting.co.za> Message-ID: <1315020408.8.0.616727225362.issue12764@psf.upfronthosting.co.za> Meador Inge added the comment: This has been fixed. I verified tip and 2.7. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 05:32:08 2011 From: report at bugs.python.org (David Benjamin) Date: Sat, 03 Sep 2011 03:32:08 +0000 Subject: [issue12844] Support more than 255 arguments In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za> Message-ID: <1315020728.1.0.563669029808.issue12844@psf.upfronthosting.co.za> David Benjamin added the comment: I don't think that patch works. Consider a dict subclass which has overridden update. Or perhaps a list subclass which has overridden addition. It would be quite poor if Python's behavior here w.r.t. which overrides are followed switched as you added more arguments. ---------- nosy: +davidben _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 07:04:04 2011 From: report at bugs.python.org (Meador Inge) Date: Sat, 03 Sep 2011 05:04:04 +0000 Subject: [issue5149] syntactic sugar: type coercion on pointer assignment In-Reply-To: <1233710403.4.0.267443476473.issue5149@psf.upfronthosting.co.za> Message-ID: <1315026244.52.0.00780968473244.issue5149@psf.upfronthosting.co.za> Meador Inge added the comment: This is busted for plain old assignment too: Python 3.3.0a0 (default:6374b4ffe00c, Sep 2 2011, 23:50:39) [GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import * >>> buff = create_string_buffer(b'foo') >>> p = c_char_p() >>> p.value = addressof(buff) >>> print(p.value) b'foo' >>> p.value = buff.value >>> print(p.value) b'foo' >>> p.value = buff Traceback (most recent call last): File "", line 1, in TypeError: string or integer address expected instead of c_char_Array_4 instance I think having the conversion is an entirely reasonable request. It is the equivalent of: char buff[128] = "foo"; char *p = buff; in C. I imagine a lot of C programmers would expect this behavior. Also, 'ctypes' already does this type of conversion for function parameters. Consider a function exported from a shared library 'libfoo' called 'print_string': void print_string (char *str) { printf ("%s\n", str); } The following all work fine: >>> libfoo = CDLL("./libfoo.so.1.0") >>> buff = create_string_buffer("foo") >>> libfoo.print_string(buff) foo >>> libfoo.print_string("foo") foo >>> libfoo.print_string(addressof(buff)) foo I am working on a patch for this. I will post it soon. ---------- assignee: theller -> nosy: +amaury.forgeotdarc, belopolsky, meadori -theller stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 09:05:04 2011 From: report at bugs.python.org (Armin Rigo) Date: Sat, 03 Sep 2011 07:05:04 +0000 Subject: [issue12850] [PATCH] stm.atomic In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za> Message-ID: <1315033504.45.0.313654392441.issue12850@psf.upfronthosting.co.za> Armin Rigo added the comment: :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 09:22:45 2011 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 03 Sep 2011 07:22:45 +0000 Subject: [issue12889] struct.pack('d'... problem In-Reply-To: <1315004853.67.0.138940038832.issue12889@psf.upfronthosting.co.za> Message-ID: <1315034565.89.0.757336924861.issue12889@psf.upfronthosting.co.za> Mark Dickinson added the comment: I agree with you on the correct 8 output bytes. And those expected bytes are exactly what struct.pack is producing here: Python 2.7.2 |EPD 7.1-1 (32-bit)| (default, Jul 3 2011, 15:40:35) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "packages", "demo" or "enthought" for more information. >>> import struct >>> struct.pack('!d', 1.2345) '?\xf3\xc0\x83\x12n\x97\x8d' >>> len(struct.pack('!d', 1.2345)) 8 >>> struct.pack('!d', 1.2345).encode('hex') '3ff3c083126e978d' I suspect that the confusion arises from the way the output string is displayed: the 8 bytes in the output string are escaped if they're not printable ASCII characters, and are displayed directly otherwise (notice the '?' and the 'n', with codes 0x3f and 0x63 respectively). ---------- nosy: +mark.dickinson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 09:25:33 2011 From: report at bugs.python.org (Georg Brandl) Date: Sat, 03 Sep 2011 07:25:33 +0000 Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2' In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za> Message-ID: <1315034733.4.0.0990626982542.issue12326@psf.upfronthosting.co.za> Georg Brandl added the comment: I've updated 3.2 docs in e11b4c945f7e (currently in the release clone, will be merged to upstream after the release of 3.2.2.) Please commit a similar change to the 2.7 branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 09:26:16 2011 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 03 Sep 2011 07:26:16 +0000 Subject: [issue12889] struct.pack('d'... problem In-Reply-To: <1315004853.67.0.138940038832.issue12889@psf.upfronthosting.co.za> Message-ID: <1315034776.8.0.102087171979.issue12889@psf.upfronthosting.co.za> Mark Dickinson added the comment: > with codes 0x3f and 0x63 respectively Whoops: that should be '... 0x3f and 0x6e ...'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 10:35:20 2011 From: report at bugs.python.org (Yves Dorfsman) Date: Sat, 03 Sep 2011 08:35:20 +0000 Subject: [issue12888] html.parser.HTMLParser.unescape works only with the first 128 entities In-Reply-To: <1314997720.87.0.621504034674.issue12888@psf.upfronthosting.co.za> Message-ID: <1315038920.78.0.107593351068.issue12888@psf.upfronthosting.co.za> Yves Dorfsman added the comment: Added a test case: http://hg.zioup.org/cpython/rev/4accd3181061 If you set the loop < 128 then the test passes (set at 1000 right now). ---------- hgrepos: +65 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 11:18:27 2011 From: report at bugs.python.org (=?utf-8?q?Dr=2E_Georg_Str=C3=B6hlein?=) Date: Sat, 03 Sep 2011 09:18:27 +0000 Subject: [issue12889] struct.pack('d'... problem In-Reply-To: <1315004853.67.0.138940038832.issue12889@psf.upfronthosting.co.za> Message-ID: <1315041507.02.0.31533536239.issue12889@psf.upfronthosting.co.za> Dr. Georg Str?hlein added the comment: Thank you, Mark, for explaining the details of how to "correctly" format the output of that command to me... Regards, Schorsch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 12:15:21 2011 From: report at bugs.python.org (Peter Otten) Date: Sat, 03 Sep 2011 10:15:21 +0000 Subject: [issue12888] html.parser.HTMLParser.unescape works only with the first 128 entities In-Reply-To: <1314997720.87.0.621504034674.issue12888@psf.upfronthosting.co.za> Message-ID: <1315044921.45.0.947280837762.issue12888@psf.upfronthosting.co.za> Peter Otten <__peter__ at web.de> added the comment: The unescape() method uses re.sub(regex, sub, re.ASCII), but the third argument is count, not flags. Fix is easy: use re.sub(regex, sub, flags=re.ASCII). ---------- keywords: +patch nosy: +potten Added file: http://bugs.python.org/file23092/unescape_bug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 13:55:23 2011 From: report at bugs.python.org (Nam Nguyen) Date: Sat, 03 Sep 2011 11:55:23 +0000 Subject: [issue5876] __repr__ returning unicode doesn't work when called implicitly In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za> Message-ID: <1315050923.08.0.188625459661.issue5876@psf.upfronthosting.co.za> Changes by Nam Nguyen : ---------- nosy: +Nam.Nguyen _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 14:48:26 2011 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 03 Sep 2011 12:48:26 +0000 Subject: [issue12888] html.parser.HTMLParser.unescape works only with the first 128 entities In-Reply-To: <1314997720.87.0.621504034674.issue12888@psf.upfronthosting.co.za> Message-ID: <1315054106.68.0.167246099723.issue12888@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti nosy: +ezio.melotti stage: -> commit review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 15:32:32 2011 From: report at bugs.python.org (Roundup Robot) Date: Sat, 03 Sep 2011 13:32:32 +0000 Subject: [issue12878] io.StringIO doesn't provide a __dict__ field In-Reply-To: <1314902829.02.0.266212831864.issue12878@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8ec8a4579788 by Benjamin Peterson in branch '3.2': add a __dict__ descr for IOBase (closes #12878) http://hg.python.org/cpython/rev/8ec8a4579788 New changeset fe0497bd7354 by Benjamin Peterson in branch 'default': merge 3.2 (#12878) http://hg.python.org/cpython/rev/fe0497bd7354 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 17:01:18 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 03 Sep 2011 15:01:18 +0000 Subject: [issue7219] Unhelpful error message when a distutils package install fails due to a permissions error In-Reply-To: <1256647071.1.0.815334810123.issue7219@psf.upfronthosting.co.za> Message-ID: <1315062078.25.0.642241513884.issue7219@psf.upfronthosting.co.za> ?ric Araujo added the comment: I have a patch that needs testing on Cpython Windows and if possible IPython. The test makes sure that the error message contains the path to the file (which the incomplete error message you report also does, BTW), and an explanation of the error (to address the OP?s concern that the message must be helpful): it looks for the string 'denied'; if this is not cross-platform, I won?t commit this line. (Antoine, I?ve made you nosy because I think you may have expertise on that last point.) (BTW, I have tracked down the source of the mysterious None (I?m getting better at these things, but my mental sanity takes a toll each time): core.setup catches the exception and wants to display exc.filename and exc.strerror.) ---------- assignee: tarek -> eric.araujo components: +Distutils, Distutils2 keywords: +needs review, patch nosy: +alexis, higery, pitrou stage: needs patch -> patch review versions: +3rd party, Python 3.3 -Python 3.1 Added file: http://bugs.python.org/file23093/fix-7219.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 17:07:47 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 03 Sep 2011 15:07:47 +0000 Subject: [issue12891] Clean up traces of manifest template in packaging Message-ID: <1315062467.17.0.194525671954.issue12891@psf.upfronthosting.co.za> New submission from ?ric Araujo : With distutils2/packaging, extra files to be included in sdists are defined in setup.cfg, no more in a manifest template. However, the Manifest class and the sdist command still have code to deal with manifest templates. I propose to remove it. ---------- assignee: tarek components: Distutils2 messages: 143462 nosy: alexis, eric.araujo, tarek priority: normal severity: normal stage: needs patch status: open title: Clean up traces of manifest template in packaging versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 18:00:56 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 03 Sep 2011 16:00:56 +0000 Subject: [issue12862] ConfigParser does not implement "comments need to be preceded by a whitespace character" correctly In-Reply-To: <1314725453.99.0.502494798896.issue12862@psf.upfronthosting.co.za> Message-ID: <1315065656.07.0.988141007924.issue12862@psf.upfronthosting.co.za> ?ric Araujo added the comment: > ?ric, the docs clearly state that currently only full-line comments > are enabled by default. Wow, I missed that. I use such comments in some config files or config file examples in documentation :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 18:07:00 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 03 Sep 2011 16:07:00 +0000 Subject: [issue10914] Python sub-interpreter test In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za> Message-ID: <1315066020.23.0.216731159222.issue10914@psf.upfronthosting.co.za> ?ric Araujo added the comment: BTW, about this comment in the code: # XXX only tested under Unix checkouts It is possible to install the _testembed.c file alongside xxmodule.c and compile it at test time. To test under Windows, I?ve re-read your first patch using distutils and it?s not that long or hard to read after all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 18:11:57 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 03 Sep 2011 16:11:57 +0000 Subject: [issue12386] packaging fails in install_distinfo when writing RESOURCES In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za> Message-ID: <1315066317.57.0.328852019955.issue12386@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I also noticed that your latest comment > "All text is bytes, so we can do all I/O in bytes when writing > resources and avoid special-casing." > contradicts your earlier position: > "I agree about the nonsense of opening in binary mode." It does :) My earlier position was wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 18:12:49 2011 From: report at bugs.python.org (Meador Inge) Date: Sat, 03 Sep 2011 16:12:49 +0000 Subject: [issue12881] ctypes: segfault with large structure field names In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za> Message-ID: <1315066369.72.0.165460244327.issue12881@psf.upfronthosting.co.za> Meador Inge added the comment: Here is a patch that replaces the 'alloca' call with 'PyMem_Malloc'. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file23094/issue12881.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 18:22:56 2011 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Sat, 03 Sep 2011 16:22:56 +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: <1315066976.02.0.236942821193.issue2636@psf.upfronthosting.co.za> Jeffrey C. Jacobs added the comment: Although V1, V2 is less wordy, technically the current behavior is version 2.2.2, so logically this should be re.VERSION222 vs. re.VERSION3 vs. re.VERSIONn, with corresponding "(?V222)", "(?V3)" and future "(?Vn)". But that said, I think 2.2.2 can be shorthanded to 2, so basically start counting from there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 18:42:03 2011 From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=) Date: Sat, 03 Sep 2011 16:42:03 +0000 Subject: [issue12659] Add tests for packaging.tests.support In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za> Message-ID: <1315068123.96.0.554629604198.issue12659@psf.upfronthosting.co.za> Francisco Mart?n Brugu? added the comment: Hi ?ric, sorry but I've not received that email. Could you simply paste/send me the link (I've not used Rietveld already and I can not to find that review). Thanks ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 18:56:50 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 03 Sep 2011 16:56:50 +0000 Subject: [issue7219] Unhelpful error message when a distutils package install fails due to a permissions error In-Reply-To: <1315062078.25.0.642241513884.issue7219@psf.upfronthosting.co.za> Message-ID: <1315068853.3531.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > The test makes sure that the error message contains the path to the > file (which the incomplete error message you report also does, BTW), > and an explanation of the error (to address the OP?s concern that the > message must be helpful): it looks for the string 'denied'; if this is > not cross-platform, I won?t commit this line. I really don't think C error messages are portable, so you shouldn't test for them :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 19:02:09 2011 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 03 Sep 2011 17:02:09 +0000 Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2' In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za> Message-ID: <1315069329.39.0.941001109838.issue12326@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Please delete Lib/plat-linux3 directories on 2.7 and 3.2 branches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 19:59:54 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 03 Sep 2011 17:59:54 +0000 Subject: [issue12815] Coverage of smtpd.py In-Reply-To: <1314001507.51.0.00455911966964.issue12815@psf.upfronthosting.co.za> Message-ID: <1315072794.98.0.217403913926.issue12815@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +barry, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 20:20:30 2011 From: report at bugs.python.org (Vlastimil Brom) Date: Sat, 03 Sep 2011 18:20: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: <1315074030.48.0.498605829832.issue2636@psf.upfronthosting.co.za> Vlastimil Brom added the comment: Not that it matters in any way, but if the regex semantics has to be distinguished via "non-standard" custom flags; I would prefer even less wordy flags, possibly such that the short forms for the in-pattern flag setting would be one-letter (such as all the other flags) and preferably some with underlying plain English words as base, to get some mnemotechnics (which I don't see in the numbered versions requiring one to keep track of the rather internal library versioning). Unfortunately, it might be difficult to find suitable names, given the objections expressed against the already discussed ones. (FOr what it is worth, I thought e.g. of [t]raditional and [e]nhanced, but these also suffer from some of the mentioned disadvantages... vbr ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 3 21:23:14 2011 From: report at bugs.python.org (Piet van Oostrum) Date: Sat, 03 Sep 2011 19:23:14 +0000 Subject: [issue12008] HtmlParser non-strict goes wrong with unquoted attributes In-Reply-To: <1304592448.01.0.0813052297129.issue12008@psf.upfronthosting.co.za> Message-ID: <1315077794.99.0.944042935771.issue12008@psf.upfronthosting.co.za> Piet van Oostrum added the comment: I was bitten by this bug today. Hope it will be solved in the next release of Python 3. It is also possible to use the third argument of search in line 285: m = attrfind_tolerant.search(rawdata, k, endpos) This seems to me to be a more `natural' solution. ---------- nosy: +pietvo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 06:20:14 2011 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 04 Sep 2011 04:20:14 +0000 Subject: [issue12508] Codecs Anomaly In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za> Message-ID: <1315110014.35.0.231303484438.issue12508@psf.upfronthosting.co.za> Ezio Melotti added the comment: IIUC this happens because StreamReader calls codecs.utf_8_decode without passing final=1 [0], so when the decoder finds the trailing F4 it doesn't decode it yet because it waits from the other 3 bytes (F4 is the start byte of a 4-bytes UTF-8 sequence): >>> b = b'A\xf5BC\xf4' >>> chars, decnum = codecs.utf_8_decode(b, 'replace', 0) # final=0 >>> chars, decnum ('A?BC', 4) # F4 not decoded yet >>> b = b[decnum:] >>> b b'\xf4' # F4 still here >>> chars, decnum = codecs.utf_8_decode(b, 'replace', 0) >>> chars, decnum ('', 0) # additional calls keep waiting for the other 3 bytes >>> chars, decnum = codecs.utf_8_decode(b, 'replace', 1) # final=1 >>> chars, decnum ('?', 1) # when final=1 is passed F4 is decoded, but it never happens While passing 1 makes the attached script work as expected, it breaks several other test in test_codecs (apparently not all the decoders accept the 'final' argument). Also passing 1 should be done only for the last call: read can be called several times with a specific size, and it shouldn't use final=1 until the last call to avoid errors mid-stream. [0]: see Lib/codecs.py:482 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:41:30 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:41:30 +0000 Subject: [issue5301] add mimetype for image/vnd.microsoft.icon (patch) In-Reply-To: <1234907792.31.0.00254559526039.issue5301@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset cba2558b73ee by Sandro Tosi in branch '3.2': #5301: add image/vnd.microsoft.icon (.ico) MIME type http://hg.python.org/cpython/rev/cba2558b73ee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:41:30 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:41:30 +0000 Subject: [issue12678] test_packaging and test_distutils failures under Windows In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6fe19f421a16 by Nadeem Vawda in branch '3.2': Issue #12678: Fix distutils sdist test on Windows. http://hg.python.org/cpython/rev/6fe19f421a16 New changeset b173cfbf49a0 by ?ric Araujo in branch '3.2': Fix distutils tests on Windows (#12678). http://hg.python.org/cpython/rev/b173cfbf49a0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:41:51 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:41:51 +0000 Subject: [issue12213] BufferedRandom: issues with interlaced read-write In-Reply-To: <1306723959.59.0.759374279051.issue12213@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8de8945ebfc3 by Antoine Pitrou in branch '3.2': Issue #12213: make it clear that BufferedRWPair shouldn't be called with the http://hg.python.org/cpython/rev/8de8945ebfc3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:41:51 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:41:51 +0000 Subject: [issue11360] In documentation of getopt, advertise argparse instead of optparse In-Reply-To: <1298982503.08.0.830578820579.issue11360@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset dff0f4db67da by ?ric Araujo in branch '3.2': Remove outdated pointer to optparse (fixes #11360). http://hg.python.org/cpython/rev/dff0f4db67da ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:41:55 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:41:55 +0000 Subject: [issue12141] sysconfig.get_config_vars('srcdir') fails in specific cases In-Reply-To: <1306017151.29.0.46445476318.issue12141@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 402c4bbedf9c by ?ric Araujo in branch '3.2': Refactor the copying of xxmodule.c in distutils tests (#12141). http://hg.python.org/cpython/rev/402c4bbedf9c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:41:55 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:41:55 +0000 Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2' In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 265da863d017 by Victor Stinner in branch '3.2': Issue #12326: sys.platform is now always 'linux2' on Linux http://hg.python.org/cpython/rev/265da863d017 New changeset e11b4c945f7e by Georg Brandl in branch '3.2': Update sys.platform doc for #12326. http://hg.python.org/cpython/rev/e11b4c945f7e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:41:58 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:41:58 +0000 Subject: [issue12333] test_distutils and test_packaging failures under Solaris In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 137e45f15c0b by Antoine Pitrou in branch '3.2': Issue #12333: fix test_distutils failures under Solaris and derivatives http://hg.python.org/cpython/rev/137e45f15c0b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:41:59 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:41:59 +0000 Subject: [issue12672] Some problems in documentation extending/newtypes.html In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8083e51522ee by Eli Bendersky in branch '3.2': Issue #12672: remove confusing part of sentence in documentation http://hg.python.org/cpython/rev/8083e51522ee ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:42:00 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:42:00 +0000 Subject: [issue9651] ctypes crash when writing zerolength string buffer to file In-Reply-To: <1282324201.94.0.528743574069.issue9651@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f19d00b5220a by Amaury Forgeot d'Arc in branch '3.2': Issue #9651: Fix a crash when ctypes.create_string_buffer(0) was passed to http://hg.python.org/cpython/rev/f19d00b5220a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:42:00 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:42:00 +0000 Subject: [issue12761] Typo in Doc/license.rst In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5b21312c3800 by Sandro Tosi in branch '3.2': #12761: fix wording of zlib license section http://hg.python.org/cpython/rev/5b21312c3800 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:56:36 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:56:36 +0000 Subject: [issue12781] Mention SO_REUSEADDR near socket doc examples In-Reply-To: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 126069a5ecf6 by Sandro Tosi in branch '3.2': #12781: Mention SO_REUSEADDR flag near socket examples http://hg.python.org/cpython/rev/126069a5ecf6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:56:36 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:56:36 +0000 Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?= =?utf-8?q?subcommands?= In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset a78629c62ee8 by ?ric Araujo in branch '3.2': Make bdist_* commands respect --skip-build passed to bdist (#10946) http://hg.python.org/cpython/rev/a78629c62ee8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:56:37 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:56:37 +0000 Subject: [issue12839] zlibmodule cannot handle Z_VERSION_ERROR zlib error In-Reply-To: <1314249709.71.0.494900056916.issue12839@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2fb00b6ed17c by Nadeem Vawda in branch '3.2': Issue #12839: Fix crash in zlib module due to version mismatch. http://hg.python.org/cpython/rev/2fb00b6ed17c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:56:37 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:56:37 +0000 Subject: [issue12725] Docs: Odd phrase "floating seconds" in socket.html In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 8730fdc9349f by Ezio Melotti in branch '3.2': #12725: fix working. Patch by Ben Hayden. http://hg.python.org/cpython/rev/8730fdc9349f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 08:56:38 2011 From: report at bugs.python.org (Roundup Robot) Date: Sun, 04 Sep 2011 06:56:38 +0000 Subject: [issue12838] FAQ/Programming typo: range[3] is used In-Reply-To: <1314240637.99.0.384249238245.issue12838@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6e156a6c4fd9 by Georg Brandl in branch '3.2': Close #12838: fix range() call. http://hg.python.org/cpython/rev/6e156a6c4fd9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 09:32:31 2011 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Sun, 04 Sep 2011 07:32:31 +0000 Subject: [issue11678] Add support for Arch Linux to platform.linux_distributions() In-Reply-To: <1301098195.86.0.891765525403.issue11678@psf.upfronthosting.co.za> Message-ID: <1315121551.82.0.384787783355.issue11678@psf.upfronthosting.co.za> Westley Mart?nez added the comment: Is there anything preventing the patch from being committed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 12:49:30 2011 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 04 Sep 2011 10:49:30 +0000 Subject: [issue12892] UTF-16 and UTF-32 codecs should reject (lone) surrogates Message-ID: <1315133370.95.0.855318807974.issue12892@psf.upfronthosting.co.za> New submission from Ezio Melotti : >From Chapter 03 of the Unicode Standard 6[0], D91: """ ? UTF-16 encoding form: The Unicode encoding form that assigns each Unicode scalar value in the ranges U+0000..U+D7FF and U+E000..U+FFFF to a single unsigned 16-bit code unit with the same numeric value as the Unicode scalar value, and that assigns each Unicode scalar value in the range U+10000..U+10FFFF to a surrogate pair, according to Table 3-5. ? Because surrogate code points are not Unicode scalar values, isolated UTF-16 code units in the range 0xD800..0xDFFF are ill-formed. """ I.e. UTF-16 should be able to decode correctly a valid surrogate pair, and encode a non-BMP character using a valid surrogate pair, but it should reject lone surrogates both during encoding and decoding. On Python 3, the utf-16 codec can encode all the codepoints from U+0000 to U+10FFFF (including (lone) surrogates), but it's not able to decode lone surrogates (not sure if this is by design or if it just fails because it expects another (missing) surrogate). ---------------------------------------------- >From Chapter 03 of the Unicode Standard 6[0], D90: """ ? UTF-32 encoding form: The Unicode encoding form that assigns each Unicode scalar value to a single unsigned 32-bit code unit with the same numeric value as the Unicode scalar value. ? Because surrogate code points are not included in the set of Unicode scalar values, UTF-32 code units in the range 0x0000D800..0x0000DFFF are ill-formed. """ I.e. UTF-32 should reject both lone surrogates and valid surrogate pairs, both during encoding and during decoding. On Python 3, the utf-32 codec can encode and decode all the codepoints from U+0000 to U+10FFFF (including surrogates). ---------------------------------------------- I think that: * this should be fixed in 3.3; * it's a bug, so the fix /might/ be backported to 3.2. Hoverver it's also a fairly big change in behavior, so it might be better to leave it for 3.3 only; * it's better to leave 2.7 alone, even the utf-8 codec is broken there; * the surrogatepass error handler should work with the utf-16 and utf-32 codecs too. Note that this has been already reported in #3672, but eventually only the utf-8 codec was fixed. [0]: http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf ---------- assignee: ezio.melotti components: Unicode messages: 143490 nosy: ezio.melotti, gvanrossum, haypo, lemburg, loewis, tchrist priority: high severity: normal stage: test needed status: open title: UTF-16 and UTF-32 codecs should reject (lone) surrogates type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 13:07:50 2011 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 04 Sep 2011 11:07:50 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1315134470.35.0.414883274913.issue11816@psf.upfronthosting.co.za> Nick Coghlan added the comment: Regenerated the get_opinfo patch against current 3.3 tip. Still haven't fixed the missing doc updates mentioned in my last message, though. ---------- Added file: http://bugs.python.org/file23095/issue11816_get_opinfo_branch_20110904.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 13:12:50 2011 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 04 Sep 2011 11:12:50 +0000 Subject: [issue11682] PEP 380 reference implementation for 3.3 In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za> Message-ID: <1315134770.34.0.0303015645253.issue11682@psf.upfronthosting.co.za> Nick Coghlan added the comment: Uploaded a patch that should be complete. Note that my pep380 branch is based on my get_opinfo branch (see #11816), so if you're applying patches manually rather than updating directly from my sandbox with hg, you'll need to apply the latest patch from #11816 before applying this one. Raymond: assigning to you, since you said you wanted to review the dis.get_opinfo changes before they went in, and those changes are a dependency for the updated PEP 380 test suite. ---------- Added file: http://bugs.python.org/file23096/issue11682_pep380_branch_20110904.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 13:18:57 2011 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 04 Sep 2011 11:18:57 +0000 Subject: [issue11682] PEP 380 reference implementation for 3.3 In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za> Message-ID: <1315135137.68.0.396143658362.issue11682@psf.upfronthosting.co.za> Nick Coghlan added the comment: Actually, not assigning to Raymond for review yet, after all - I just noticed there are some of Benjamin's review comments relating to cosmetic details rather than functionality that I still need to address. I'll kick it in Raymond's direction once I've dealt with those (probably next weekend, but possibly some time this week) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 13:51:46 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 04 Sep 2011 11:51:46 +0000 Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled without threads In-Reply-To: <4E608F9E.7050407@haypocalc.com> Message-ID: Charles-Fran?ois Natali added the comment: Here's a patch adding a configure-time check. Since the functions are checked without being linked explicitely with pthread, it should do the trick (I couldn't test it on OpenBSD though). I also added a skipTest to test_posix.test_sched_priority(). ---------- keywords: +patch title: Disable sched_get_priority_min/max if Python is compiled without threads -> Disable sched_get_priority_min/max if Python is compiled without threads Added file: http://bugs.python.org/file23097/sched_get_priority.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r a29b72950795 Lib/test/test_posix.py --- a/Lib/test/test_posix.py Thu Sep 01 23:08:21 2011 +0200 +++ b/Lib/test/test_posix.py Sat Sep 03 18:08:01 2011 +0200 @@ -840,6 +840,8 @@ posix.sched_yield() @requires_sched_h + @unittest.skipUnless(hasattr(posix, 'sched_get_priority_max'), + "requires sched_get_priority_max()") def test_sched_priority(self): # Round-robin usually has interesting priorities. pol = posix.SCHED_RR diff -r a29b72950795 Modules/posixmodule.c --- a/Modules/posixmodule.c Thu Sep 01 23:08:21 2011 +0200 +++ b/Modules/posixmodule.c Sat Sep 03 18:08:01 2011 +0200 @@ -4555,6 +4555,8 @@ #ifdef HAVE_SCHED_H +#ifdef HAVE_SCHED_GET_PRIORITY_MAX + PyDoc_STRVAR(posix_sched_get_priority_max__doc__, "sched_get_priority_max(policy)\n\n\ Get the maximum scheduling priority for *policy*."); @@ -4589,6 +4591,8 @@ return PyLong_FromLong(min); } +#endif /* HAVE_SCHED_GET_PRIORITY_MAX */ + #ifdef HAVE_SCHED_SETSCHEDULER PyDoc_STRVAR(posix_sched_getscheduler__doc__, @@ -10452,8 +10456,10 @@ {"fork", posix_fork, METH_NOARGS, posix_fork__doc__}, #endif /* HAVE_FORK */ #ifdef HAVE_SCHED_H +#ifdef HAVE_SCHED_GET_PRIORITY_MAX {"sched_get_priority_max", posix_sched_get_priority_max, METH_VARARGS, posix_sched_get_priority_max__doc__}, {"sched_get_priority_min", posix_sched_get_priority_min, METH_VARARGS, posix_sched_get_priority_min__doc__}, +#endif #ifdef HAVE_SCHED_SETPARAM {"sched_getparam", posix_sched_getparam, METH_VARARGS, posix_sched_getparam__doc__}, #endif @@ -10474,7 +10480,7 @@ {"sched_setaffinity", posix_sched_setaffinity, METH_VARARGS, posix_sched_setaffinity__doc__}, {"sched_getaffinity", posix_sched_getaffinity, METH_VARARGS, posix_sched_getaffinity__doc__}, #endif -#endif +#endif /* HAVE_SCHED_H */ #if defined(HAVE_OPENPTY) || defined(HAVE__GETPTY) || defined(HAVE_DEV_PTMX) {"openpty", posix_openpty, METH_NOARGS, posix_openpty__doc__}, #endif /* HAVE_OPENPTY || HAVE__GETPTY || HAVE_DEV_PTMX */ diff -r a29b72950795 configure.in --- a/configure.in Thu Sep 01 23:08:21 2011 +0200 +++ b/configure.in Sat Sep 03 18:08:01 2011 +0200 @@ -2538,7 +2538,8 @@ select sem_open sem_timedwait sem_getvalue sem_unlink sendfile setegid seteuid \ setgid sethostname \ setlocale setregid setreuid setresuid setresgid setsid setpgid setpgrp setpriority setuid setvbuf \ - sched_setaffinity sched_setscheduler sched_setparam sched_rr_get_interval \ + sched_get_priority_max sched_setaffinity sched_setscheduler sched_setparam \ + sched_rr_get_interval \ sigaction sigaltstack siginterrupt sigpending sigrelse \ sigtimedwait sigwait sigwaitinfo snprintf strftime strlcpy symlinkat sync \ sysconf tcgetpgrp tcsetpgrp tempnam timegm times tmpfile tmpnam tmpnam_r \ From report at bugs.python.org Sun Sep 4 14:46:14 2011 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 04 Sep 2011 12:46:14 +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: <4E637313.2040503@egenix.com> Marc-Andre Lemburg added the comment: Ezio Melotti wrote: > > New submission from Ezio Melotti : > >>From Chapter 03 of the Unicode Standard 6[0], D91: > """ > ? UTF-16 encoding form: The Unicode encoding form that assigns each Unicode scalar value in the ranges U+0000..U+D7FF and U+E000..U+FFFF to a single unsigned 16-bit code unit with the same numeric value as the Unicode scalar value, and that assigns each Unicode scalar value in the range U+10000..U+10FFFF to a surrogate pair, according to Table 3-5. > ? Because surrogate code points are not Unicode scalar values, isolated UTF-16 code units in the range 0xD800..0xDFFF are ill-formed. > """ > I.e. UTF-16 should be able to decode correctly a valid surrogate pair, and encode a non-BMP character using a valid surrogate pair, but it should reject lone surrogates both during encoding and decoding. > > On Python 3, the utf-16 codec can encode all the codepoints from U+0000 to U+10FFFF (including (lone) surrogates), but it's not able to decode lone surrogates (not sure if this is by design or if it just fails because it expects another (missing) surrogate). > > ---------------------------------------------- > >>From Chapter 03 of the Unicode Standard 6[0], D90: > """ > ? UTF-32 encoding form: The Unicode encoding form that assigns each Unicode scalar value to a single unsigned 32-bit code unit with the same numeric value as the Unicode scalar value. > ? Because surrogate code points are not included in the set of Unicode scalar values, UTF-32 code units in the range 0x0000D800..0x0000DFFF are ill-formed. > """ > I.e. UTF-32 should reject both lone surrogates and valid surrogate pairs, both during encoding and during decoding. > > On Python 3, the utf-32 codec can encode and decode all the codepoints from U+0000 to U+10FFFF (including surrogates). > > ---------------------------------------------- > > I think that: > * this should be fixed in 3.3; > * it's a bug, so the fix /might/ be backported to 3.2. Hoverver it's also a fairly big change in behavior, so it might be better to leave it for 3.3 only; > * it's better to leave 2.7 alone, even the utf-8 codec is broken there; > * the surrogatepass error handler should work with the utf-16 and utf-32 codecs too. > > > Note that this has been already reported in #3672, but eventually only the utf-8 codec was fixed. All UTF codecs should reject lone surrogates in strict error mode, but let them pass using the surrogatepass error handler (the UTF-8 codec already does) and apply the usual error handling for ignore and replace. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 15:06:13 2011 From: report at bugs.python.org (Alexander Dutton) Date: Sun, 04 Sep 2011 13:06:13 +0000 Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za> Message-ID: <1315141573.26.0.0248698810746.issue12885@psf.upfronthosting.co.za> Alexander Dutton added the comment: I've come across it as I'm creating a Debian package of the Python package in the same tree ? I'm happy to be told this is a Bad Idea and that they should be in different places. The broken symlinks are relative and in debian/tmp, and will point to locations provided by other Debian packages once my package is installed in the right location. FWIW, I'm getting round it at the moment by walking the directory tree and removing the files is os.path.islink(filename) and not os.path.exists(os.path.join(filename, os.readlink(filename))). I'm happy to provide tests and a patch if necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 15:13:27 2011 From: report at bugs.python.org (Remi Pointel) Date: Sun, 04 Sep 2011 13:13:27 +0000 Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled without threads In-Reply-To: <1314813822.31.0.567192327773.issue12871@psf.upfronthosting.co.za> Message-ID: <1315142007.5.0.969082981509.issue12871@psf.upfronthosting.co.za> Remi Pointel added the comment: Hi, it seems to solve the problem (tested on OpenBSD 4.9 and OpenBSD-current). * test_posix.py on OpenBSD 4.9: [...] Ran 79 tests in 0.508s OK (skipped=35) * test_posix.py on OpenBSD-current: it continues to segfault, but I have opened an other ticket for this problem (issue 12852). Thanks a lot, Remi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 18:48:15 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 04 Sep 2011 16:48:15 +0000 Subject: [issue10914] Python sub-interpreter test In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za> Message-ID: <1315154895.48.0.798411079445.issue10914@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It is possible to install the _testembed.c file alongside xxmodule.c > and compile it at test time. We probably could, using the approach from the distutils patch. But it feels really quirky to me. Granted, the Makefile is quirky as well. > To test under Windows, I?ve re-read your first patch using distutils > and it?s not that long or hard to read after all. Except that it didn't work under Windows... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 4 22:23:11 2011 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 04 Sep 2011 20:23:11 +0000 Subject: [issue12893] Invitation to connect on LinkedIn In-Reply-To: <994986435.5527283.1315166754531.JavaMail.app@ela4-bed84.prod> Message-ID: <1315167791.87.0.0875079655884.issue12893@psf.upfronthosting.co.za> Changes by Nadeem Vawda : ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 02:59:25 2011 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Mon, 05 Sep 2011 00:59:25 +0000 Subject: [issue11155] multiprocessing.Queue's put() signature differs from docs In-Reply-To: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za> Message-ID: <1315184365.4.0.271396333984.issue11155@psf.upfronthosting.co.za> Westley Mart?nez added the comment: ?Hola! Just checking in. The documentation is still incorrect for all versions. There's a patch that fixes it ready to be reviewed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 03:01:19 2011 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Mon, 05 Sep 2011 01:01:19 +0000 Subject: [issue11340] test_distutils fails because of borked compress program In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za> Message-ID: <1315184479.66.0.010729097538.issue11340@psf.upfronthosting.co.za> Westley Mart?nez added the comment: I emailed the Arch Linux people to get more information on this particular issue. If they decide that the compress program will stay as is I will write attempt to write a patch to skip the test based on the output of compress's --version flag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 03:15:58 2011 From: report at bugs.python.org (Christian S. Perone) Date: Mon, 05 Sep 2011 01:15:58 +0000 Subject: [issue12894] pydoc help("modules keyword") is failing when a module throws an exception at the import time Message-ID: <1315185357.98.0.244247068278.issue12894@psf.upfronthosting.co.za> New submission from Christian S. Perone : Pydoc is failing when running the ModuleScanner().run() when you execute: help("modules keyword") ... if some module throws an exception at the import time. See this example: >>> help("modules convolve") Here is a list of matching modules. Enter any module name to get more help. numpy.numarray.convolve scipy.fftpack.convolve Traceback (most recent call last): File "", line 1, in File "C:\Python27\lib\site.py", line 467, in __call__ return pydoc.help(*args, **kwds) File "C:\Python27\lib\pydoc.py", line 1727, in __call__ self.help(request) File "C:\Python27\lib\pydoc.py", line 1768, in help self.listmodules(split(request)[1]) File "C:\Python27\lib\pydoc.py", line 1873, in listmodules apropos(key) File "C:\Python27\lib\pydoc.py", line 1975, in apropos ModuleScanner().run(callback, key) File "C:\Python27\lib\pydoc.py", line 1938, in run for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror): File "C:\Python27\lib\pkgutil.py", line 125, in walk_packages for item in walk_packages(path, name+'.', onerror): File "C:\Python27\lib\pkgutil.py", line 125, in walk_packages for item in walk_packages(path, name+'.', onerror): File "C:\Python27\lib\pkgutil.py", line 125, in walk_packages for item in walk_packages(path, name+'.', onerror): File "C:\Python27\lib\pkgutil.py", line 125, in walk_packages for item in walk_packages(path, name+'.', onerror): File "C:\Python27\lib\pkgutil.py", line 110, in walk_packages __import__(name) File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\lib\pubsub\core\arg1\__init__.py", line 16, in raise RuntimeError(msg) RuntimeError: Should not import this directly, used by pubsub.core if applicable After suppressing the exception by changing the "apropos()" method inside the pydoc.py: Line: ModuleScanner().run(callback, key) To: ModuleScanner().run(callback, key, onerror=lambda error: error) The problem is fixed, but I really don't know if this is the best way to suppress this and if we should suppress these exceptions, I think that as the intent of the help("modules keyword") is to find things with the keyword in the name, we shouldn't let the exception be propagated to the user. ---------- components: Library (Lib) messages: 143502 nosy: Christian.S..Perone priority: normal severity: normal status: open title: pydoc help("modules keyword") is failing when a module throws an exception at the import time type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 03:24:03 2011 From: report at bugs.python.org (Ram Rachum) Date: Mon, 05 Sep 2011 01:24:03 +0000 Subject: [issue12895] In MSI/EXE installer, allow installing Python modules in free path Message-ID: <1315185843.85.0.324851460345.issue12895@psf.upfronthosting.co.za> New submission from Ram Rachum : Currently, when you use an MSI installer (and possibly also EXE) for a Python module, it automatically detects the location of your various system's Python installations. This is very convenient. However, this can be a problem sometimes, if your Python installation doesn't conform to what's required by the installer. For example, if you want to install the module in a virtualenv: http://serverfault.com/questions/305008/installing-compiled-python-modules-on-windows-on-a-virtual-env The installer doesn't give you any option to manually enter a path of a Python installation, so you just can't install! The installer's automatic Python-finding mechanism should degrade gracefully; it should offer to automatically find your Python installation, but it should allow you to bypass it and type it in yourself. ---------- assignee: tarek components: Distutils2 messages: 143503 nosy: alexis, cool-RR, eric.araujo, tarek priority: normal severity: normal status: open title: In MSI/EXE installer, allow installing Python modules in free path versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 03:31:26 2011 From: report at bugs.python.org (Ned Deily) Date: Mon, 05 Sep 2011 01:31:26 +0000 Subject: [issue12894] pydoc help("modules keyword") is failing when a module throws an exception at the import time In-Reply-To: <1315185357.98.0.244247068278.issue12894@psf.upfronthosting.co.za> Message-ID: <1315186286.18.0.927447594898.issue12894@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the suggested fix. It looks like the problem and fix have already been documented in Issue7425. Merging this into the existing issue. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> [PATCH] Improve the robustness of "pydoc -k" in the face of broken modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 03:33:12 2011 From: report at bugs.python.org (Ned Deily) Date: Mon, 05 Sep 2011 01:33:12 +0000 Subject: [issue7425] [PATCH] Improve the robustness of "pydoc -k" in the face of broken modules In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za> Message-ID: <1315186392.94.0.975306293932.issue7425@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +Christian.S..Perone, ned.deily versions: +Python 3.3 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 03:44:52 2011 From: report at bugs.python.org (Meador Inge) Date: Mon, 05 Sep 2011 01:44:52 +0000 Subject: [issue3132] implement PEP 3118 struct changes In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za> Message-ID: <1315187092.02.0.207886716795.issue3132@psf.upfronthosting.co.za> Meador Inge added the comment: Is this work something that might be suitable for the features/pep-3118 repo (http://hg.python.org/features/pep-3118/) ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 04:11:53 2011 From: report at bugs.python.org (Meador Inge) Date: Mon, 05 Sep 2011 02:11:53 +0000 Subject: [issue9969] tokenize: add support for tokenizing 'str' objects In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za> Message-ID: <1315188713.02.0.468854796008.issue9969@psf.upfronthosting.co.za> Meador Inge added the comment: Attached is a first cut at a patch. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file23099/issue9969.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 04:25:06 2011 From: report at bugs.python.org (Meador Inge) Date: Mon, 05 Sep 2011 02:25:06 +0000 Subject: [issue1172711] long long support for array module Message-ID: <1315189506.42.0.592770328047.issue1172711@psf.upfronthosting.co.za> Meador Inge added the comment: Here is a refresh of this patch for 3.3. Please review. ---------- Added file: http://bugs.python.org/file23100/issue-1172711.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 04:32:40 2011 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 05 Sep 2011 02:32:40 +0000 Subject: [issue11155] multiprocessing.Queue's put() signature differs from docs In-Reply-To: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za> Message-ID: <1315189960.36.0.330945131202.issue11155@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 07:50:31 2011 From: report at bugs.python.org (Lennart Regebro) Date: Mon, 05 Sep 2011 05:50:31 +0000 Subject: [issue12896] Recommended location of the interpreter for Python 3 Message-ID: <1315201831.61.0.39811771821.issue12896@psf.upfronthosting.co.za> New submission from Lennart Regebro : The documentation on Using Python, 2.3. Python-related paths and files says that "exec_prefix/bin/python" is the recommended location for the interpreter, while for Python 3 it's "exec_prefix/bin/python3". http://docs.python.org/py3k/using/unix.html#python-related-paths-and-files ---------- assignee: docs at python components: Documentation messages: 143508 nosy: docs at python, lregebro priority: normal severity: normal status: open title: Recommended location of the interpreter for Python 3 versions: Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 09:53:49 2011 From: report at bugs.python.org (Stefan Krah) Date: Mon, 05 Sep 2011 07:53:49 +0000 Subject: [issue3132] implement PEP 3118 struct changes In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za> Message-ID: <1315209229.4.0.662215003335.issue3132@psf.upfronthosting.co.za> Stefan Krah added the comment: Yes, definitely. I'm going to push a new memoryview implementation (complete for all 1D/native format cases) in a couple of days. Once that is done, perhaps we could create a memoryview-struct branch on top of that. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 11:20:22 2011 From: report at bugs.python.org (Zbyszek Szmek) Date: Mon, 05 Sep 2011 09:20:22 +0000 Subject: [issue11682] PEP 380 reference implementation for 3.3 In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za> Message-ID: <1315214422.66.0.395811604422.issue11682@psf.upfronthosting.co.za> Zbyszek Szmek added the comment: I've created some documentation... The patches are the bitbucket repo. Nothing is added to the tutorial, because I think that this isn't material for a newcomer to python. The tutorial doesn't mention generator.throw() and send() either, just talks a little about writing simple generator functions. ---------- hgrepos: +66 nosy: +zbysz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 12:35:26 2011 From: report at bugs.python.org (Armin Rigo) Date: Mon, 05 Sep 2011 10:35:26 +0000 Subject: [issue1172711] long long support for array module Message-ID: <1315218926.99.0.37958608939.issue1172711@psf.upfronthosting.co.za> Changes by Armin Rigo : ---------- nosy: -arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 14:01:45 2011 From: report at bugs.python.org (andrew cooke) Date: Mon, 05 Sep 2011 12:01:45 +0000 Subject: [issue12897] Support for iterators in multiprocessing map Message-ID: <1315224105.15.0.691135308397.issue12897@psf.upfronthosting.co.za> New submission from andrew cooke : http://stackoverflow.com/questions/7306522/combining-itertools-and-multiprocessing/7307078 suggests (and the idea itself seems reasonable) that it would sometimes be useful for multiprocessing to operate correctly (ie lazily) with lazy input (iterables). for example, if the input is large, or perhaps generated by some other process "on demand". obviously this complicates matters, given the asynchronous nature of a worker pool, and would mean re-allocating the results list as required. but in principle i suspect it would be possible and might be a useful extension. ---------- components: Library (Lib) messages: 143511 nosy: acooke priority: normal severity: normal status: open title: Support for iterators in multiprocessing map type: feature request versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 16:19:40 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 14:19:40 +0000 Subject: [issue12888] html.parser.HTMLParser.unescape works only with the first 128 entities In-Reply-To: <1314997720.87.0.621504034674.issue12888@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 9896fc2a8167 by Ezio Melotti in branch '3.2': #12888: Fix a bug in HTMLParser.unescape that prevented it to escape more than 128 entities. Patch by Peter Otten. http://hg.python.org/cpython/rev/9896fc2a8167 New changeset 7b6096852665 by Ezio Melotti in branch 'default': #12888: merge with 3.2. http://hg.python.org/cpython/rev/7b6096852665 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 16:27:55 2011 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 05 Sep 2011 14:27:55 +0000 Subject: [issue12888] html.parser.HTMLParser.unescape works only with the first 128 entities In-Reply-To: <1314997720.87.0.621504034674.issue12888@psf.upfronthosting.co.za> Message-ID: <1315232875.28.0.824147249219.issue12888@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report and the patch! ---------- components: +Library (Lib) -None resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 16:31:15 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 14:31:15 +0000 Subject: [issue12117] Failures with PYTHONDONTWRITEBYTECODE: test_importlib, test_imp, test_distutils, test_packaging, test_runpy, test_import In-Reply-To: <1305821886.01.0.955278848895.issue12117@psf.upfronthosting.co.za> Message-ID: <1315233075.45.0.0434870884328.issue12117@psf.upfronthosting.co.za> ?ric Araujo added the comment: Alright, closing. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 16:33:08 2011 From: report at bugs.python.org (=?utf-8?q?Hei=C3=B0ar_Rafn_Har=C3=B0arson?=) Date: Mon, 05 Sep 2011 14:33:08 +0000 Subject: [issue12886] datetime.strptime parses input wrong In-Reply-To: <1314974007.55.0.285568781981.issue12886@psf.upfronthosting.co.za> Message-ID: <1315233188.42.0.970302318018.issue12886@psf.upfronthosting.co.za> Hei?ar Rafn Har?arson added the comment: My understanding of the python documentation and the ISO 8601 standard is that the digits in a timestamp representing hours, minutes and seconds shall always be in pairs of 2 digits (hh, mm, ss), i.e. when a number is less than 10 it should be preceded by 0. In the example I give, the minute figure is split between minutes and seconds by the python library function which I consider a bug: datetime.datetime.strptime('20110817T1234','%Y%m%dT%H%M%S') gives datetime.datetime(2011, 8, 17, 12, 3, 4) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 16:37:12 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 14:37:12 +0000 Subject: [issue12659] Add tests for packaging.tests.support In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za> Message-ID: <1315233432.6.0.029652441768.issue12659@psf.upfronthosting.co.za> ?ric Araujo added the comment: Follow the link titled ?review? on the right of your patch in the list of files above the messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 16:39:41 2011 From: report at bugs.python.org (=?utf-8?q?Hei=C3=B0ar_Rafn_Har=C3=B0arson?=) Date: Mon, 05 Sep 2011 14:39:41 +0000 Subject: [issue12886] datetime.strptime parses input wrong In-Reply-To: <1314974007.55.0.285568781981.issue12886@psf.upfronthosting.co.za> Message-ID: <1315233581.45.0.705299772811.issue12886@psf.upfronthosting.co.za> Hei?ar Rafn Har?arson added the comment: This issue is also discussed here: http://bugs.python.org/issue5979 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 16:41:42 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 14:41:42 +0000 Subject: [issue10914] Python sub-interpreter test In-Reply-To: <1295098719.73.0.016388283782.issue10914@psf.upfronthosting.co.za> Message-ID: <1315233702.74.0.660652788579.issue10914@psf.upfronthosting.co.za> ?ric Araujo added the comment: > Except that it didn't work under Windows... Ah. If it was an extension module, I?d have a clue (the debug thing), but I know nothing about embedding. An alternative would be to install the file with the msi system and use a project file to have it compiled (sounds like much hassle). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 16:51:17 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 05 Sep 2011 14:51:17 +0000 Subject: [issue10914] Python sub-interpreter test In-Reply-To: <1315233702.74.0.660652788579.issue10914@psf.upfronthosting.co.za> Message-ID: <1315233928.3565.0.camel@localhost.localdomain> Antoine Pitrou added the comment: > Ah. If it was an extension module, I?d have a clue (the debug thing), > but I know nothing about embedding. An alternative would be to > install the file with the msi system and use a project file to have it > compiled (sounds like much hassle). Agreed, but it's not something that I know how to do :) (and yet, of course, it would be good to test that embedding works under Windows too, as well as under Unix installs) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 16:56:41 2011 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 05 Sep 2011 14:56:41 +0000 Subject: [issue11957] re.sub confusion between count and flags args In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za> Message-ID: <1315234601.29.0.863561531753.issue11957@psf.upfronthosting.co.za> Ezio Melotti added the comment: See also #12888 for an error in the stdlib caused by this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:04:19 2011 From: report at bugs.python.org (higery) Date: Mon, 05 Sep 2011 15:04:19 +0000 Subject: [issue7219] Unhelpful error message when a distutils package install fails due to a permissions error In-Reply-To: <1315068853.3531.0.camel@localhost.localdomain> Message-ID: higery added the comment: I have run the 'test_install_lib' on cpython3.3(windows version), the 'test_install_error' failed. The detail is: *FAIL: test_install_error (__main__.InstallLibTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\add-develop-command\Lib\distutils\tests\test_install_lib.py", line 112, in test_install_error cmd.run() AssertionError: DistutilsFileError not raised* The corresponding lines are: * with self.assertRaises(DistutilsFileError) as cm: cmd.run()* ---------- Added file: http://bugs.python.org/file23101/unnamed _______________________________________ Python tracker _______________________________________ -------------- next part -------------- I have run the 'test_install_lib' on cpython3.3(windows version), the 'test_install_error' failed.

The detail is:

FAIL: test_install_error (__main__.InstallLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
?? File "D:\add-develop-command\Lib\distutils\tests\test_install_lib.py", line 112, in test_install_error
?????? cmd.run()
AssertionError: DistutilsFileError not raised

The corresponding lines are:

with self.assertRaises(DistutilsFileError) as cm:
?????????????? cmd.run()
From report at bugs.python.org Mon Sep 5 17:12:27 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 15:12:27 +0000 Subject: [issue12898] add opendir() for POSIX platforms Message-ID: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> New submission from Larry Hastings : With the recent spate of POSIX *at() functions added to os, we now have a bunch of places in the API that take directory fds. But afaict there's no way to get a directory fd in Python! The only calls to opendir() in the tree are internal, in os.listdir() and in the import machinery. (Though in practice most people will use AT_FDCWD anyway.) I propose adding a new function, os.opendir(), the implementation to be much the same as (aka a hacked-up copy and paste of) os.unlink() in Modules/posixmodule.c. I'd be happy to contribute the patch. ---------- components: Extension Modules messages: 143522 nosy: larry priority: normal severity: normal status: open title: add opendir() for POSIX platforms type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:13:31 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 15:13:31 +0000 Subject: [issue7219] Unhelpful error message when a distutils package install fails due to a permissions error In-Reply-To: <1256647071.1.0.815334810123.issue7219@psf.upfronthosting.co.za> Message-ID: <1315235611.83.0.858564271322.issue7219@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I really don't think C error messages are portable, so you shouldn't > test for them :) Too bad. I?ll have to be satisfied with a manual test from Michael then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:14:52 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 15:14:52 +0000 Subject: [issue12841] Incorrect tarfile.py extraction In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 2bc122347351 by Lars Gust?bel in branch '3.2': Issue #12841: Fix tarfile extraction of non-existent uids/gids. http://hg.python.org/cpython/rev/2bc122347351 New changeset da59abc0ce3b by Lars Gust?bel in branch 'default': Merge with 3.2: Issue #12841: Fix tarfile extraction of non-existent uids/gids. http://hg.python.org/cpython/rev/da59abc0ce3b New changeset b64ef2951093 by Lars Gust?bel in branch '2.7': Issue #12841: Fix tarfile extraction of non-existent uids/gids. http://hg.python.org/cpython/rev/b64ef2951093 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:15:59 2011 From: report at bugs.python.org (Ross Lagerwall) Date: Mon, 05 Sep 2011 15:15:59 +0000 Subject: [issue12898] add opendir() for POSIX platforms In-Reply-To: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> Message-ID: <1315235759.92.0.848881432073.issue12898@psf.upfronthosting.co.za> Ross Lagerwall added the comment: opendir opens a C dirent structure with an underlying file descriptor. However, to open a directory file descriptor, simple use: os.open("/tmp", os.O_RDONLY) This can then be used as the fd to the functions which require a directory fd like os.openat() Cheers Ross ---------- nosy: +rosslagerwall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:19:18 2011 From: report at bugs.python.org (Ross Lagerwall) Date: Mon, 05 Sep 2011 15:19:18 +0000 Subject: [issue12898] add opendir() for POSIX platforms In-Reply-To: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> Message-ID: <1315235958.65.0.866590530068.issue12898@psf.upfronthosting.co.za> Ross Lagerwall added the comment: Also see fdopendir(3) which allows you to pass an open file descriptor to get a C dirent struct. This is implemented in the os module too but instead of returning a struct, it returns a list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:20:59 2011 From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=) Date: Mon, 05 Sep 2011 15:20:59 +0000 Subject: [issue12841] Incorrect tarfile.py extraction In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za> Message-ID: <1315236059.61.0.0383705854511.issue12841@psf.upfronthosting.co.za> Lars Gust?bel added the comment: Close as fixed. Thanks all! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:40:40 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 15:40:40 +0000 Subject: [issue12899] Change os.utimensat() and os.futimens() to use float for atime & mtime Message-ID: <1315237240.05.0.971546244676.issue12899@psf.upfronthosting.co.za> New submission from Larry Hastings : The new functions os.futimens() and os.utimensat() update the timestamps of a file with nanosecond precision. However, both functions take atime and mtime as a tuple: (seconds since epoch, nanoseconds). Contrast this with os.utime(), which produces atime and mtime as a floating point number of seconds since epoch. Why the mismatch between the APIs? It simply forces the user to do the conversion themselves. You can see this in the regression tests for these two functions--there's a lot of multiplying by 1e9 going on. The only justification I can contrive is that the conversion of (secs+(1e-9*nsecs)) can be inaccurate; a double would need roughly one more byte of mantissa to be able to accurately preserve all possible nanosecond values. But that ship has sailed--os.utime() produces inaccurate results, and afaik there's no other way to do it in the Python library. os.futimens() and os.utimensat() should take atime and mtime in the floating-point format as produced by os.utime(). I'm happy to contribute the patch. ---------- components: Extension Modules messages: 143529 nosy: larry priority: normal severity: normal status: open title: Change os.utimensat() and os.futimens() to use float for atime & mtime type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:46:08 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 15:46:08 +0000 Subject: [issue8286] distutils: path '[...]' cannot end with '/' -- need better error message In-Reply-To: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 6cd8c1582dff by ?ric Araujo in branch '3.2': Warn instead of crashing because of invalid path in MANIFEST.in (#8286). http://hg.python.org/cpython/rev/6cd8c1582dff New changeset b42661daa5cc by ?ric Araujo in branch 'default': Merge fix for #8286 from 3.2 http://hg.python.org/cpython/rev/b42661daa5cc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:47:19 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 15:47:19 +0000 Subject: [issue8286] distutils: path '[...]' cannot end with '/' -- need better error message In-Reply-To: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za> Message-ID: <1315237639.64.0.057313840104.issue8286@psf.upfronthosting.co.za> ?ric Araujo added the comment: This should now be fixed. ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:49:49 2011 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 05 Sep 2011 15:49:49 +0000 Subject: [issue11155] multiprocessing.Queue's put() signature differs from docs In-Reply-To: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za> Message-ID: <1315237789.47.0.636300315399.issue11155@psf.upfronthosting.co.za> Senthil Kumaran added the comment: anikom15's first patch seems correct. In the multiprocessing.py, the the arg 'obj' can be safely replaced with 'item' to be consistent with the docs. As this is not a keyword arg, it does not stand any chance of breaking any backwards compatibility. It looks me to that when multiprocessing' Queue.put was coding the first arg was wrongly mentioned as 'obj' instead of 'item'. I shall commit the first patch unless someone objects to the above reasoning. ---------- assignee: docs at python -> orsenthil nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:49:58 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 05 Sep 2011 15:49:58 +0000 Subject: [issue12897] Support for iterators in multiprocessing map In-Reply-To: <1315224105.15.0.691135308397.issue12897@psf.upfronthosting.co.za> Message-ID: <1315237798.67.0.720467943305.issue12897@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Since it's a feature request, I would suggest to look whether it can apply to concurrent.futures instead. ---------- nosy: +pitrou versions: +Python 3.3 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:51:43 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 15:51:43 +0000 Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za> Message-ID: <1315237903.39.0.632485476086.issue12885@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I've come across it as I'm creating a Debian package of the Python > package in the same tree I think a lot of people are doing this. > The broken symlinks are relative and in debian/tmp, and will point to > locations provided by other Debian packages once my package is > installed in the right location. It?s too bad that filelist goes into the debian subdirectory :( The Ubuntu-originated python-distutils-extra project had a similar problem and they switched from FileList.findall to os.walk to avoid it. What happens if you ignore the debian dir in MANIFEST.in? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:52:34 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 15:52:34 +0000 Subject: [issue8286] distutils: path '[...]' cannot end with '/' -- need better error message In-Reply-To: <1270180979.93.0.404335172952.issue8286@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 9cdc845d5f2e by ?ric Araujo in branch '2.7': Warn instead of crashing because of invalid path in MANIFEST.in (#8286). http://hg.python.org/cpython/rev/9cdc845d5f2e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:53:37 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 15:53:37 +0000 Subject: [issue12898] add opendir() for POSIX platforms In-Reply-To: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> Message-ID: <1315238017.4.0.698737756123.issue12898@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, there's no os.fdopendir(); I think you're referring to fdlistdir(), which uses the C function fdopendir() internally. The DIR structure is not exposed to the Python caller at any point. I did miss the whole opendir-returns-a-DIR-not-a-fd thing, hopefully that's my dumb thing of the day. This suggests opendir() would have to call dirfd() on your behalf. Would it be safe to call close() on the fd returned from dirfd(opendir())? If not, I guess we'd need a special closedir() function, which would use the C functions fdopendir() then closedir() internally. ... or we could forget the whole thing, I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 17:58:18 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 05 Sep 2011 15:58:18 +0000 Subject: [issue12898] add opendir() for POSIX platforms In-Reply-To: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> Message-ID: <1315238298.09.0.791262458931.issue12898@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, is there any case where fdlistdir() is not sufficient? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:00:46 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 16:00:46 +0000 Subject: [issue12898] add opendir() for POSIX platforms In-Reply-To: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> Message-ID: <1315238446.18.0.895074782925.issue12898@psf.upfronthosting.co.za> Larry Hastings added the comment: fdlistdir() is largely irrelevant to the discussion. I was proposing adding a function to open directory fds, because there isn't one; fdlistdir(), like many other POSIX functions available in Python, consumes directory fds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:05:19 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 16:05:19 +0000 Subject: [issue12900] Use universal newlines mode for setup.cfg Message-ID: <1315238719.19.0.16385104093.issue12900@psf.upfronthosting.co.za> New submission from ?ric Araujo : We need tests to make sure that setup.cfg files using CRLF or CR as newline character work. We could require that people use LF in the spec, but I don?t think it?s worth it, as it?s simple enough to support all newlines whereas Windows users can?t always use LF easily. For packaging in 3.3, opening the file in text mode gives us universal newlines for free, so the code is good but we need tests. For distutils2 in 2.x, we need to pass 'rU' as open flags. ---------- assignee: tarek components: Distutils2 keywords: easy messages: 143539 nosy: alexis, eric.araujo, tarek priority: normal severity: normal stage: needs patch status: open title: Use universal newlines mode for setup.cfg type: behavior versions: 3rd party, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:08:06 2011 From: report at bugs.python.org (Ross Lagerwall) Date: Mon, 05 Sep 2011 16:08:06 +0000 Subject: [issue12899] Change os.utimensat() and os.futimens() to use float for atime & mtime In-Reply-To: <1315237240.05.0.971546244676.issue12899@psf.upfronthosting.co.za> Message-ID: <1315238886.99.0.826134264369.issue12899@psf.upfronthosting.co.za> Ross Lagerwall added the comment: See #11457 for a long discussion about the API and whether to use decimal or not to get the full precision. ---------- nosy: +rosslagerwall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:10:47 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 16:10:47 +0000 Subject: [issue5876] __repr__ returning unicode doesn't work when called implicitly In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za> Message-ID: <1315239047.25.0.24574642916.issue5876@psf.upfronthosting.co.za> ?ric Araujo added the comment: I think it?s not an implicit vs. explicit call problem, rather repr vs. str. IIRC, in 2.x it is allowed that __str__ returns a unicode object, and str will convert it to a str. To do that, it will use the default encoding, which is ASCII in 2.5+, so your example cannot work. Ideas for work-arounds: - write a displayhook (http://docs.python.org/dev/library/sys#sys.displayhook) that converts unicode objects using sys.stout.encoding - for 2.6+, test if setting PYTHONIOENCODING changes soemthing ---------- nosy: +eric.araujo, lemburg versions: -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:12:21 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 16:12:21 +0000 Subject: [issue7425] Improve the robustness of "pydoc -k" in the face of broken modules In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za> Message-ID: <1315239141.02.0.885350579502.issue7425@psf.upfronthosting.co.za> ?ric Araujo added the comment: Does this patch solves only pydoc -k, not all ?invalid spam module makes pydoc crash?? (I wanted to consolidate the handful of reports we have into one but did not get the time.) ---------- nosy: +eric.araujo title: [PATCH] Improve the robustness of "pydoc -k" in the face of broken modules -> Improve the robustness of "pydoc -k" in the face of broken modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:12:22 2011 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 05 Sep 2011 16:12:22 +0000 Subject: [issue11155] multiprocessing.Queue's put() signature differs from docs In-Reply-To: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za> Message-ID: <1315239142.21.0.357171254444.issue11155@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Well, I should take back my previous comment. I realized that the positional arg in this case can be called as keyword arg. It would be wrong to change multiprocessing.py and it is correct to change the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:15:08 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 16:15:08 +0000 Subject: [issue11473] upload command no longer accepts repository by section name In-Reply-To: <1299882717.19.0.490703720004.issue11473@psf.upfronthosting.co.za> Message-ID: <1315239308.94.0.468268636528.issue11473@psf.upfronthosting.co.za> ?ric Araujo added the comment: I started working on a test for this in packaging and it?s worse than I expected: it does not support multiple repositories at all. The config parser has bogus tests and the upload command has no test for this. I will work on fixing this in packaging and backport. ---------- assignee: tarek -> eric.araujo components: +Distutils2 nosy: +alexis versions: +3rd party, Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:16:27 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 05 Sep 2011 16:16:27 +0000 Subject: [issue12898] add opendir() for POSIX platforms In-Reply-To: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> Message-ID: <1315239387.02.0.467337332768.issue12898@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I was proposing adding a function to open directory fds, because > there isn't one; fdlistdir(), like many other POSIX functions > available in Python, consumes directory fds. I don't think I understand. This already works: >>> fd = os.open("Misc", os.O_RDONLY) >>> os.fdlistdir(fd) ['python.pc', 'README.coverity', 'ACKS.orig', 'NEWS.orig', 'HISTORY', 'python.man', 'valgrind-python.supp', 'TextMate', 'python-config.in', 'NEWS', 'RPM', 'vgrindefs', 'svnmap.txt', 'python-wing4.wpr', 'gdbinit', 'build.sh', 'README.AIX', 'Vim', 'SpecialBuilds.txt', 'indent.pro', 'python-wing3.wpr', 'ACKS', 'README', 'README.valgrind', 'Porting', 'python.pc.in'] Is there anything you want to do on a "directory fd" except listing its contents? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:22:21 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 16:22:21 +0000 Subject: [issue12898] add opendir() for POSIX platforms In-Reply-To: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> Message-ID: <1315239741.23.0.305110854111.issue12898@psf.upfronthosting.co.za> Larry Hastings added the comment: > Is there anything you want to do on a "directory fd" > except listing its contents? In the first message in this bug, I wrote: "With the recent spate of POSIX *at() functions added to os, we now have a bunch of places in the API that take directory fds." To be specific: faccessat, fchmodat, fchownat, fstatat, futimesat, linkat, mkdirat, mknodat, openat, readlinkat, renameat, symlinkat, unlinkat, utimensat, mkfifoat. At the time I created this ticket I didn't realize you could just call open() on a directory. It seem that works fine and is supported everywhere that these *at functions exist, so perhaps it's best if we just close this ticket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:23:59 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 16:23:59 +0000 Subject: [issue11155] multiprocessing.Queue's put() signature differs from docs In-Reply-To: <1297211747.04.0.707896670759.issue11155@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset c6d4d4d64405 by Senthil Kumaran in branch '3.2': Fix closes Issue11155 - Correct the multiprocessing.Queue.put's arg (replace 'item' with 'obj') in the docs. Patch by Westley Mart?nez. http://hg.python.org/cpython/rev/c6d4d4d64405 New changeset 8f1187288fac by Senthil Kumaran in branch 'default': merge from 3.2. Fix closes Issue11155 - Correct the multiprocessing.Queue.put's arg (replace 'item' with 'obj') in the docs. Patch by Westley Mart?nez. http://hg.python.org/cpython/rev/8f1187288fac New changeset d29c9006d770 by Senthil Kumaran in branch '2.7': merge from 3.2. Fix closes Issue11155 - Correct the multiprocessing.Queue.put's arg (replace 'item' with 'obj') in the docs. Patch by Westley Mart?nez. http://hg.python.org/cpython/rev/d29c9006d770 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:30:44 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 16:30:44 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1315240244.85.0.786443076928.issue5845@psf.upfronthosting.co.za> ?ric Araujo added the comment: We can?t just decide to enable completion by checking ?'readline' in sys.modules? in site, because it always returns False. site is imported in Python/pythonrun.c, and I guess that Modules/main.c is run afterwards. More importantly, I think the import of readline in Modules/main.c is a CPython implementation detail, and I?d prefer to have code in site that is directly useful for other VMs. (I?d go as far as proposing to remove the import readline from main.c, when my patch makes it obsolete.) I re-read the docs for sys.argv and the -m switch and decided to translate to C checks (?command == NULL && filename == NULL && module == NULL?) to ?if not sys.argv[0]?. Unfortunately, sys.argv is not available when site is imported, so this is a dead end :( So, I could try your _setupinteractive module idea, even though I think it?s a bit unclean, or drink the cool aid and set up completion in main.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:31:16 2011 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Sep 2011 16:31:16 +0000 Subject: [issue12898] add opendir() for POSIX platforms In-Reply-To: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> Message-ID: <1315240276.39.0.857351346539.issue12898@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:32:08 2011 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Sep 2011 16:32:08 +0000 Subject: [issue12898] add opendir() for POSIX platforms In-Reply-To: <1315235547.8.0.461411196791.issue12898@psf.upfronthosting.co.za> Message-ID: <1315240328.15.0.0667731677873.issue12898@psf.upfronthosting.co.za> STINNER Victor added the comment: > At the time I created this ticket I didn't realize you could > just call open() on a directory. Yes, os.open or os.openat. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:38:42 2011 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Sep 2011 16:38:42 +0000 Subject: [issue5876] __repr__ returning unicode doesn't work when called implicitly In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za> Message-ID: <1315240722.95.0.342900735032.issue5876@psf.upfronthosting.co.za> STINNER Victor added the comment: I think that this issue is a duplicate of #4947 which has been fixed in Python 2.7.1. Can you retry with Python 2.7.2 (or 2.7.1)? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:40:18 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 16:40:18 +0000 Subject: [issue12779] Update packaging documentation In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za> Message-ID: <1315240818.06.0.459565621804.issue12779@psf.upfronthosting.co.za> ?ric Araujo added the comment: To make commit review possible, I thought I?d make two patches for this: the first would be only markup fixes and minimal updates to match the reality of the code (i.e. convert setup.py examples to setup.cfg or pysetup, remove obsolete parts, etc.) and a second one with more rephrasing and reorganization (i.e. file deletions, moving chunks of docs, etc.). I?m not finished on the first patch and the diff already contains 1026 insertions and 921 deletions. So, as potential commit reviewers, do you think I should - 1) go ahead with my initial plan of a huge boring commit and a more interesting commit - 2) just make one commit - 3) one commit per file (with boring markup changes + non-boring changes) ---------- nosy: +ezio.melotti, sandro.tosi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:45:19 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 16:45:19 +0000 Subject: [issue12901] Nest class/methods directives in documentation Message-ID: <1315241119.9.0.996780726209.issue12901@psf.upfronthosting.co.za> New submission from ?ric Araujo : I picked up a few files in Doc/library and updated their markup to use directives nesting. The attached patch is the result; it?s a lot of changes for small benefit. If we think it?s a good change anyway, I have two questions - Do you think it would be a good idea to have the -checkins emails ignore whitespace changes in some cases? (I?m thinking a magic string in the commit message) - A number of files have a class directive near the top of the file, in the list of all public names, and a later section ?XX objects? with the methods and attributes. When this is changed to nested class/methods directives, sometimes the first class directive gets a noindex flag, but I think it should jsut be removed: the index in the sidebar is enough to let people jump to the doc. Do you agree? ---------- assignee: docs at python components: Documentation messages: 143552 nosy: benjamin.peterson, docs at python, eric.araujo, georg.brandl priority: normal severity: normal status: open title: Nest class/methods directives in documentation versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 18:45:39 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 05 Sep 2011 16:45:39 +0000 Subject: [issue12901] Nest class/methods directives in documentation In-Reply-To: <1315241119.9.0.996780726209.issue12901@psf.upfronthosting.co.za> Message-ID: <1315241139.22.0.264172995002.issue12901@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- keywords: +patch Added file: http://bugs.python.org/file23102/doc-nest-methods-3.2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 19:27:42 2011 From: report at bugs.python.org (Tomasz Melcer) Date: Mon, 05 Sep 2011 17:27:42 +0000 Subject: [issue5876] __repr__ returning unicode doesn't work when called implicitly In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za> Message-ID: <1315243662.59.0.256574529098.issue5876@psf.upfronthosting.co.za> Tomasz Melcer added the comment: Debian SID. No, it wasn't. Python 2.7.2+ (default, Aug 16 2011, 09:23:59) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class T(object): ... def __repr__(self): return u'???' ... >>> T().__repr__() u'\u3042\u307f\u3054' >>> print T().__repr__() ??? >>> T() Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) >>> print T() Traceback (most recent call last): File "", line 1, in UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128) >>> import sys >>> sys.stdin.encoding 'UTF-8' >>> sys.stdout.encoding 'UTF-8' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 20:29:39 2011 From: report at bugs.python.org (Cherniavsky Beni) Date: Mon, 05 Sep 2011 18:29:39 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1315247379.39.0.723748019545.issue5845@psf.upfronthosting.co.za> Cherniavsky Beni added the comment: Easily detecting interactive mode is of general interest for customization. 1. What if C also set sys.flags.interactive in "python" mode, or exposed sys.flags.implicit_interactive (but with better name)? 2. It's more useful to have a hook called when entering interactive mode, rather than a flag that's set from the beginning: $ python -i -c 'import sys; print sys.flags.interactive' 1 >>> For this, importing _setupinteractive is a step forward; calling e.g. sys.__interactivehook__ sounds even better. (site.py would set it by default to a function that enables rlcompleter, user can always override...) BTW, drawback of doing any such setup in site.py: "python -S" would be unfriendly! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 21:12:48 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 19:12:48 +0000 Subject: [issue12899] Change os.utimensat() and os.futimens() to use float for atime & mtime In-Reply-To: <1315237240.05.0.971546244676.issue12899@psf.upfronthosting.co.za> Message-ID: <1315249968.14.0.106042466076.issue12899@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm withdrawing this, as I've found a better way to approach the problem. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 21:31:23 2011 From: report at bugs.python.org (dronus) Date: Mon, 05 Sep 2011 19:31:23 +0000 Subject: [issue12902] help("modules") executes module code Message-ID: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za> New submission from dronus : When running help("modules"), some code of the modules seems to be run. For example, on my Gnome system KWallet configuration GUI pops up and stalls further opereation. I think no one expect help("modules") run abitrary code instead of just outputting a list of modules. ---------- components: None messages: 143556 nosy: dronus priority: normal severity: normal status: open title: help("modules") executes module code type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 21:40:12 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 19:40:12 +0000 Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2' In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset d95c4b030eac by Victor Stinner in branch '2.7': Issue #12326: Remove plat-linux3 directory http://hg.python.org/cpython/rev/d95c4b030eac New changeset cb47cf5138a4 by Victor Stinner in branch '3.2': Issue #12326: Remove plat-linux3 directory http://hg.python.org/cpython/rev/cb47cf5138a4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 21:51:55 2011 From: report at bugs.python.org (Remi Pointel) Date: Mon, 05 Sep 2011 19:51:55 +0000 Subject: [issue12903] test_io.test_interrupte[r]d* blocks on OpenBSD Message-ID: <1315252314.97.0.81854089556.issue12903@psf.upfronthosting.co.za> New submission from Remi Pointel : Hi, these tests block on OpenBSD: -test_interrupted_write_unbuffered() -test_interrupted_write_buffered() -test_interrupted_write_text() -test_interrupterd_read_retry_buffered() -test_interrupterd_read_retry_text() -test_interrupterd_write_retry_buffered() -test_interrupterd_write_retry_text() I have a patch which skip these tests, to have a full test_io.py regress tests but I think it's not the proper solution. Thanks for your help, Remi. ---------- files: patch-Lib_test_test_io_py messages: 143558 nosy: rpointel priority: normal severity: normal status: open title: test_io.test_interrupte[r]d* blocks on OpenBSD versions: Python 3.2 Added file: http://bugs.python.org/file23103/patch-Lib_test_test_io_py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 22:07:15 2011 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Sep 2011 20:07:15 +0000 Subject: [issue5876] __repr__ returning unicode doesn't work when called implicitly In-Reply-To: <1315243662.59.0.256574529098.issue5876@psf.upfronthosting.co.za> Message-ID: <201109052206.55336.victor.stinner@haypocalc.com> STINNER Victor added the comment: > Debian SID. No, it wasn't. Oh ok, gotcha: repr() always returns a str string. If obj.__repr__() returns a Unicode string, the string is encoded to the default encoding. By default, the default encoding is ASCII. $ ./python -S Python 2.7.2+ (2.7:85a12278de69, Sep 2 2011, 00:21:57) [GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux2 >>> import sys >>> sys.setdefaultencoding('ISO-8859-1') >>> class A(object): ... def __repr__(self): return u'\xe9' ... >>> repr(A()) '\xe9' Don't do that at home! Change the default encoding is not a good idea. I don't think that repr(obj) can be changed to return Unicode if obj.__repr__() returns Unicode. It is too late to change such thing in Python 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 22:30:39 2011 From: report at bugs.python.org (Torsten Landschoff) Date: Mon, 05 Sep 2011 20:30:39 +0000 Subject: [issue12353] argparse cannot handle empty arguments In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za> Message-ID: <1315254639.61.0.554071383208.issue12353@psf.upfronthosting.co.za> Torsten Landschoff added the comment: ping!? I think this should be either applied or dropped. It does not make sense to have such a simple issue rot in the bug tracker... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 22:36:40 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 20:36:40 +0000 Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2' In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 0fe571d43317 by Victor Stinner in branch '2.7': Update sys.platform doc for #12326. http://hg.python.org/cpython/rev/0fe571d43317 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 22:39:31 2011 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Sep 2011 20:39:31 +0000 Subject: [issue12326] Linux 3: code should avoid using sys.platform == 'linux2' In-Reply-To: <1307975682.23.0.138592930251.issue12326@psf.upfronthosting.co.za> Message-ID: <1315255171.4.0.0569089815089.issue12326@psf.upfronthosting.co.za> STINNER Victor added the comment: I removed Lib/plat-linux3 from Python 2.7 and 3.2, and updated doc of Python 2.7. I close this issue (again). ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 23:08:02 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 21:08:02 +0000 Subject: [issue12904] Change os.utime &c functions to use nanosecond precision where possible Message-ID: <1315256882.76.0.179568612134.issue12904@psf.upfronthosting.co.za> New submission from Larry Hastings : Since Linux 2.5 stat() has supported reading nanosecond resolution (1b/sec) for atime and mtime. However, the utime() family of functions could only write atime and mtime with microsecond resolution (1m/sec) until relatively recently. On POSIX platforms Python reads atime and mtime at nanosecond resolution but only writes them at microsecond resolution. This impedance mismatch can cause undesirable behavior. Consider the following code: import os import shutil import sys def mtime(path): return os.stat(path).st_mtime src = sys.argv[0] dest = src + ".new" shutil.copy2(src, dest) assert mtime(src) == mtime(dest) When run under Python on any modern Linux system, the assert fails. (I think any Python since 2.5 will do; I tested with 2.7.1 and a fresh 3.3 trunk.) The accompanying patch modifies Modules/posixmodule.c so all functions that write atime and mtime use nanosecond resolution when possible. With this patch applied, all the regression tests pass (except the ones for extension modules I didn't compile), and the above code runs to completion. Happy to hoist the patch up on Rietveld if there's interest. p.s. I have the commit bit set, so I'd like to be the one to check this in if we get that far. ---------- assignee: larry components: Extension Modules files: larry.utimensat.patch.r1 messages: 143563 nosy: larry priority: normal severity: normal status: open title: Change os.utime &c functions to use nanosecond precision where possible type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23104/larry.utimensat.patch.r1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 23:33:33 2011 From: report at bugs.python.org (Remi Pointel) Date: Mon, 05 Sep 2011 21:33:33 +0000 Subject: [issue12905] multiple errors in test_socket on OpenBSD Message-ID: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za> New submission from Remi Pointel : Hi, I have few problems in test_socket.py. 1) test_sendall_interrupted blocks on OpenBSD, I must Ctrl+c to interrupt the test. I added a skip to have full regress tests, but I think it's not the proper way. I have run it into gdb, and ctrl+c it: test_sendall_interrupted (__main__.GeneralModuleTests) ... [New process 20677] ^C Program received signal SIGINT, Interrupt. 0x0000000206d2378a in poll () from /usr/lib/libc.so.60.1 (gdb) bt #0 0x0000000206d2378a in poll () from /usr/lib/libc.so.60.1 #1 0x0000000205f4e4aa in _thread_kern_poll (wait_reqd=Variable "wait_reqd" is not available. ) at /usr/src/lib/libpthread/uthread/uthread_kern.c:780 #2 0x0000000205f4f3a8 in _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:382 #3 0x0000000205f43ade in sendto (fd=8, msg=0x2047bb040, len=1044480, flags=0, to=0x0, to_len=0) at /usr/src/lib/libpthread/uthread/uthread_sendto.c:63 #4 0x0000000210a5b243 in sock_sendall (s=0x20115c948, args=0x2011510d0) at /usr/ports/pobj/Python-3.2.2/Python-3.2.2/Modules/socketmodule.c:2699 #5 0x0000000000468992 in PyEval_EvalFrameEx (f=0x20a281c30, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:3921 #6 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x20fc581b0, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #7 0x0000000000466df6 in PyEval_EvalFrameEx (f=0x20a9a3c30, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4019 #8 0x0000000000468c1a in PyEval_EvalFrameEx (f=0x2033af030, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4009 #9 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x2028a9de8, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #10 0x0000000000466df6 in PyEval_EvalFrameEx (f=0x2052f1430, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4019 #11 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x2028a9f58, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #12 0x0000000000511ce3 in function_call (func=0x2050d5620, arg=0x20115d330, kw=0x2052f0030) at Objects/funcobject.c:629 #13 0x00000000004e4a7f in PyObject_Call (func=0x2050d5620, arg=0x20115d330, kw=0x2052f0030) at Objects/abstract.c:2149 #14 0x000000000046456d in PyEval_EvalFrameEx (f=0x2052f0e30, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4236 #15 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x2028ad268, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #16 0x0000000000511ce3 in function_call (func=0x2050d5790, arg=0x20115d240, kw=0x0) at Objects/funcobject.c:629 #17 0x00000000004e4a7f in PyObject_Call (func=0x2050d5790, arg=0x20115d240, kw=0x0) at Objects/abstract.c:2149 #18 0x00000000004ff349 in method_call (func=0x2050d5790, arg=0x20115a5a0, kw=0x0) at Objects/classobject.c:319 #19 0x00000000004e4a7f in PyObject_Call (func=0x20115d150, arg=0x20115a5a0, kw=0x0) at Objects/abstract.c:2149 #20 0x000000000042cb66 in slot_tp_call (self=Variable "self" is not available. ) at Objects/typeobject.c:5044 #21 0x00000000004e4a7f in PyObject_Call (func=0x20113b680, arg=0x20115a5a0, kw=0x0) at Objects/abstract.c:2149 #22 0x00000000004628fb in PyEval_EvalFrameEx (f=0x2071dc030, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4141 #23 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x2086db6b8, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #24 0x0000000000511ce3 in function_call (func=0x2086de1d0, arg=0x20115d1c8, kw=0x2071dd430) at Objects/funcobject.c:629 #25 0x00000000004e4a7f in PyObject_Call (func=0x2086de1d0, arg=0x20115d1c8, kw=0x2071dd430) at Objects/abstract.c:2149 #26 0x000000000046456d in PyEval_EvalFrameEx (f=0x2071dde30, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4236 #27 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x2086db490, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #28 0x0000000000511ce3 in function_call (func=0x2086de060, arg=0x20113f420, kw=0x0) at Objects/funcobject.c:629 #29 0x00000000004e4a7f in PyObject_Call (func=0x2086de060, arg=0x20113f420, kw=0x0) at Objects/abstract.c:2149 #30 0x00000000004ff349 in method_call (func=0x2086de060, arg=0x2011411b0, kw=0x0) at Objects/classobject.c:319 #31 0x00000000004e4a7f in PyObject_Call (func=0x20115d0d8, arg=0x2011411b0, kw=0x0) at Objects/abstract.c:2149 #32 0x000000000042cb66 in slot_tp_call (self=Variable "self" is not available. ) at Objects/typeobject.c:5044 #33 0x00000000004e4a7f in PyObject_Call (func=0x201138920, arg=0x2011411b0, kw=0x0) at Objects/abstract.c:2149 #34 0x00000000004628fb in PyEval_EvalFrameEx (f=0x2071dc430, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4141 #35 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x2086db6b8, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #36 0x0000000000511ce3 in function_call (func=0x2086de1d0, arg=0x20113c498, kw=0x2071dd830) at Objects/funcobject.c:629 #37 0x00000000004e4a7f in PyObject_Call (func=0x2086de1d0, arg=0x20113c498, kw=0x2071dd830) at Objects/abstract.c:2149 #38 0x000000000046456d in PyEval_EvalFrameEx (f=0x2071dda30, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4236 #39 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x2086db490, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #40 0x0000000000511ce3 in function_call (func=0x2086de060, arg=0x201127ee8, kw=0x0) at Objects/funcobject.c:629 #41 0x00000000004e4a7f in PyObject_Call (func=0x2086de060, arg=0x201127ee8, kw=0x0) at Objects/abstract.c:2149 #42 0x00000000004ff349 in method_call (func=0x2086de060, arg=0x20113e920, kw=0x0) at Objects/classobject.c:319 #43 0x00000000004e4a7f in PyObject_Call (func=0x208ba78d0, arg=0x20113e920, kw=0x0) at Objects/abstract.c:2149 #44 0x000000000042cb66 in slot_tp_call (self=Variable "self" is not available. ) at Objects/typeobject.c:5044 #45 0x00000000004e4a7f in PyObject_Call (func=0x201138370, arg=0x20113e920, kw=0x0) at Objects/abstract.c:2149 #46 0x00000000004628fb in PyEval_EvalFrameEx (f=0x20de7d830, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4141 #47 0x0000000000468c1a in PyEval_EvalFrameEx (f=0x20de7f830, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4009 #48 0x0000000000468c1a in PyEval_EvalFrameEx (f=0x20e626830, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4009 #49 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x20189b040, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #50 0x0000000000511ce3 in function_call (func=0x20449fb28, arg=0x2071d9a30, kw=0x0) at Objects/funcobject.c:629 #51 0x00000000004e4a7f in PyObject_Call (func=0x20449fb28, arg=0x2071d9a30, kw=0x0) at Objects/abstract.c:2149 #52 0x000000000046456d in PyEval_EvalFrameEx (f=0x200eb9830, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4236 #53 0x0000000000468c1a in PyEval_EvalFrameEx (f=0x209c2d830, throwflag=Variable "throwflag" is not available. ) at Python/ceval.c:4009 #54 0x000000000046a95c in PyEval_EvalCodeEx (_co=0x20fc856b8, globals=Variable "globals" is not available. ) at Python/ceval.c:3350 #55 0x000000000046ab2b in PyEval_EvalCode (co=Variable "co" is not available. ) at Python/ceval.c:767 #56 0x000000000048ade7 in run_mod (mod=Variable "mod" is not available. ) at Python/pythonrun.c:1783 #57 0x000000000048aeee in PyRun_FileExFlags (fp=0x2071bb8e0, filename=0x205619690 "Lib/test/test_socket.py.orig", start=257, globals=0x205a01e30, locals=0x205a01e30, closeit=1, flags=0x7f7ffffbe5e0) at Python/pythonrun.c:1740 #58 0x000000000048da19 in PyRun_SimpleFileExFlags (fp=0x2071bb8e0, filename=0x205619690 "Lib/test/test_socket.py.orig", closeit=1, flags=0x7f7ffffbe5e0) at Python/pythonrun.c:1265 #59 0x000000000049fe00 in Py_Main (argc=Variable "argc" is not available. ) at Modules/main.c:297 #60 0x0000000000414eaa in main (argc=2, argv=0x7f7ffffbe6a0) at ./Modules/python.c:59 2) test_sendall_interrupted_with_timeout has an error: ====================================================================== ERROR: test_sendall_interrupted_with_timeout (__main__.GeneralModuleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_socket.py", line 753, in test_sendall_interrupted_with_timeout self.check_sendall_interrupted(True) File "Lib/test/test_socket.py", line 742, in check_sendall_interrupted self.assertRaises(socket.timeout, c.sendall, b"x" * (1024**2)) File "/usr/ports/pobj/Python-3.2.2/Python-3.2.2/Lib/unittest/case.py", line 557, in assertRaises callableObj(*args, **kwargs) socket.error: [Errno 0] Error ====================================================================== 3) testInterruptedTimeout failed: ====================================================================== FAIL: testInterruptedTimeout (__main__.TCPTimeoutTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_socket.py", line 1707, in testInterruptedTimeout foo = self.serv.accept() socket.timeout: timed out During handling of the above exception, another exception occurred: Traceback (most recent call last): File "Lib/test/test_socket.py", line 1707, in testInterruptedTimeout foo = self.serv.accept() Alarm During handling of the above exception, another exception occurred: Traceback (most recent call last): File "Lib/test/test_socket.py", line 1721, in testInterruptedTimeout self.fail("got Alarm in wrong place") AssertionError: got Alarm in wrong place ====================================================================== Thanks a lot, Remi. ---------- messages: 143564 nosy: rpointel priority: normal severity: normal status: open title: multiple errors in test_socket on OpenBSD versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 23:39:43 2011 From: report at bugs.python.org (Remi Pointel) Date: Mon, 05 Sep 2011 21:39:43 +0000 Subject: [issue12905] multiple errors in test_socket on OpenBSD In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za> Message-ID: <1315258783.54.0.81942475605.issue12905@psf.upfronthosting.co.za> Remi Pointel added the comment: I add bt output with gdb 7, to have more informations. ---------- Added file: http://bugs.python.org/file23105/OpenBSD_test_socket_gdb.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 23:50:13 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 21:50:13 +0000 Subject: [issue12904] Change os.utime &c functions to use nanosecond precision where possible In-Reply-To: <1315256882.76.0.179568612134.issue12904@psf.upfronthosting.co.za> Message-ID: <1315259413.96.0.714475187043.issue12904@psf.upfronthosting.co.za> Larry Hastings added the comment: A small aside: An IEEE 754 double is insufficient to store a modern timestamp with nanosecond accuracy. We're currently at just over 1.3 billion seconds since the epoch. This eats 28 bits of the mantissa. (The value is actually 31 bits to the left of the decimal point, but you get the leading 1 and the subsequent two 0s for free.) Precisely storing a billion values to the right of the decimal point would require another 30 bits. The mantissa of a double is sadly only 52 bits. So we're shy by 6 bits, give or take. So this patch doesn't make Python 100% accurate with respect to atime/mtime. What it *does* do is makes Python's loss of accuracy consistent. I claim that's a definite improvement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 23:50:28 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 21:50:28 +0000 Subject: [issue9561] distutils: set encoding to utf-8 for input and output files In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset fb4d2e6d393e by Victor Stinner in branch '3.2': Issue #9561: distutils now reads and writes egg-info files using UTF-8 http://hg.python.org/cpython/rev/fb4d2e6d393e New changeset 3c080bf75342 by Victor Stinner in branch 'default': Merge 3.2: Issue #9561: distutils now reads and writes egg-info files using UTF-8 http://hg.python.org/cpython/rev/3c080bf75342 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 5 23:57:56 2011 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 05 Sep 2011 21:57:56 +0000 Subject: [issue12904] Change os.utime &c functions to use nanosecond precision where possible In-Reply-To: <1315256882.76.0.179568612134.issue12904@psf.upfronthosting.co.za> Message-ID: <1315259876.99.0.914506493794.issue12904@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: It's a duplicate of issue #11457. (Python >=3.3 has os.utimensat() and os.futimens().) ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 00:04:52 2011 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Sep 2011 22:04:52 +0000 Subject: [issue9561] distutils: set encoding to utf-8 for input and output files In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za> Message-ID: <1315260292.64.0.348397457149.issue9561@psf.upfronthosting.co.za> STINNER Victor added the comment: I applied pkginfo_utf8.patch to Python 3.2 and 3.3. Python 2.7 is not affected, it does already encode Unicode to UTF-8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 00:11:40 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 22:11:40 +0000 Subject: [issue9561] distutils: set encoding to utf-8 for input and output files In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 56ab3257ca13 by Victor Stinner in branch 'default': Issue #9561: packaging now writes egg-info files using UTF-8 http://hg.python.org/cpython/rev/56ab3257ca13 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 00:12:52 2011 From: report at bugs.python.org (Stefan Krah) Date: Mon, 05 Sep 2011 22:12:52 +0000 Subject: [issue11457] Expose nanosecond precision from system calls In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za> Message-ID: <1315260772.42.0.4832065245.issue11457@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 00:18:43 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 22:18:43 +0000 Subject: [issue12904] Change os.utime &c functions to use nanosecond precision where possible In-Reply-To: <1315256882.76.0.179568612134.issue12904@psf.upfronthosting.co.za> Message-ID: <1315261123.28.0.935761850011.issue12904@psf.upfronthosting.co.za> Larry Hastings added the comment: > It's a duplicate of issue #11457. No. #11457 is a how-many-angels-on-the-head-of-a-pin discussion proposing new representations of ctime/mtime/atime to preserve nanosecond accuracy. This patch changes the behavior of os.utime, os.futimes, os.lutimes, and os.futimesat so they conserve all of the existing representation's accuracy, making them consistent with os.stat. > (Python >=3.3 has os.utimensat() and os.futimens().) How is that relevant? I mean, sure, I leveraged some of the work from that support in my patch--it's heavily reliant on the preprocessor macros HAVE_UTIMENSAT and HAVE_FUTIMENS now generated by configure. (Thanks, Ross!) But the presence of those functions does not mitigate the loss of accuracy inside os.utime &c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 00:22:00 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 05 Sep 2011 22:22:00 +0000 Subject: [issue12905] multiple errors in test_socket on OpenBSD In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za> Message-ID: <1315261320.22.0.787340202831.issue12905@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo, neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 00:22:38 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 05 Sep 2011 22:22:38 +0000 Subject: [issue12903] test_io.test_interrupte[r]d* blocks on OpenBSD In-Reply-To: <1315252314.97.0.81854089556.issue12903@psf.upfronthosting.co.za> Message-ID: <1315261358.1.0.998347742058.issue12903@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Tests nosy: +haypo, neologix, pitrou stage: -> patch review type: -> behavior versions: +Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 00:25:30 2011 From: report at bugs.python.org (STINNER Victor) Date: Mon, 05 Sep 2011 22:25:30 +0000 Subject: [issue12905] multiple errors in test_socket on OpenBSD In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za> Message-ID: <1315261530.79.0.402156907463.issue12905@psf.upfronthosting.co.za> STINNER Victor added the comment: I hope that this issue is not related to threads+signals. We got many threads+signals issues on FreeBSD 6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 00:35:22 2011 From: report at bugs.python.org (Larry Hastings) Date: Mon, 05 Sep 2011 22:35:22 +0000 Subject: [issue11457] Expose nanosecond precision from system calls In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za> Message-ID: <1315262122.72.0.75646294415.issue11457@psf.upfronthosting.co.za> Larry Hastings added the comment: This is probably a terrible idea, but: what about using a subclass of float that internally preserves the original sec / usec values? Call it a utime_float for now. os.stat would produce them, and os.utime would look for them--and if it found one it'd pull out the precise numbers. Type promotion as a result of binary operators: utime_float OP int = utime_float utime_float OP float = degrades to float I suspect code rarely does math on atime/utime/ctime and then writes out the result. Most of the time they simply propogate the utime values around, comparing them to each other, or setting them unchanged. For those rare occasions when someone wants to change the fractional part of a utime_float, we could provide a function utime_fractional(int) -> utime_float. Advantages: * Nobody has to change any Python code. In almost all circumstances they get complete accuracy for free. Disadvantages: * Complicated. * Is a yucky hack. * Is a terrible idea. (Now I'm sure of it!) ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 01:53:33 2011 From: report at bugs.python.org (Roundup Robot) Date: Mon, 05 Sep 2011 23:53:33 +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: Roundup Robot added the comment: New changeset b1e03d10391e by Victor Stinner in branch 'default': Issue #12567: Add curses.unget_wch() function http://hg.python.org/cpython/rev/b1e03d10391e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 02:05:09 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Sep 2011 00:05:09 +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: <1315267509.03.0.237118904268.issue12567@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not sure that it is correct to call nl_langinfo(CODESET) to get the locale encoding. The LC_CTYPE locale should maybe be set temporary to the current locale (""), as does locale.getpreferredencoding(). Or maybe better, locale.getpreferredencoding() should be called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 02:06:34 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Sep 2011 00:06:34 +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: <1315267594.59.0.0126999601907.issue12567@psf.upfronthosting.co.za> STINNER Victor added the comment: > The LC_CTYPE locale should maybe be set temporary to > the current locale (""), as does locale.getpreferredencoding(). See also issue #6203. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 02:11:52 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Sep 2011 00:11:52 +0000 Subject: [issue12903] test_io.test_interrupte[r]d* blocks on OpenBSD In-Reply-To: <1315252314.97.0.81854089556.issue12903@psf.upfronthosting.co.za> Message-ID: <1315267912.82.0.060820983301.issue12903@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks similar to issue #12905: yet another threads+signals issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 02:12:28 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Sep 2011 00:12:28 +0000 Subject: [issue12905] multiple errors in test_socket on OpenBSD In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za> Message-ID: <1315267948.63.0.397721153253.issue12905@psf.upfronthosting.co.za> STINNER Victor added the comment: Issue #12903 is similar to this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 05:33:20 2011 From: report at bugs.python.org (Derrick Petzold) Date: Tue, 06 Sep 2011 03:33:20 +0000 Subject: [issue12906] Slight error in logging module's yaml config Message-ID: <1315280000.72.0.273608973729.issue12906@psf.upfronthosting.co.za> New submission from Derrick Petzold : Hello, format: format=%(asctime)s - %(name)s - %(levelname)s - %(message)s Should be: format: %(asctime)s - %(name)s - %(levelname)s - %(message)s Regards, btw I have to say the logging module is just excellent. What a truly great work. ty. ---------- assignee: docs at python components: Documentation messages: 143579 nosy: Derrick.Petzold, docs at python priority: normal severity: normal status: open title: Slight error in logging module's yaml config versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 05:43:52 2011 From: report at bugs.python.org (Derrick Petzold) Date: Tue, 06 Sep 2011 03:43:52 +0000 Subject: [issue12906] Slight error in logging module's yaml config In-Reply-To: <1315280000.72.0.273608973729.issue12906@psf.upfronthosting.co.za> Message-ID: <1315280632.86.0.263900195367.issue12906@psf.upfronthosting.co.za> Derrick Petzold added the comment: Oh crap that doesn't work either. yaml.scanner.ScannerError: while scanning for the next token found character '%' that cannot start any token in "/var/sites/magnum/magnum/logging.yaml", line 4, column 13 Should be format: '%(asctime)s - %(name)s - %(levelname)s - %(message)s' Regards, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 06:33:30 2011 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 06 Sep 2011 04:33:30 +0000 Subject: [issue12850] [PATCH] stm.atomic In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za> Message-ID: <1315283610.05.0.365065884472.issue12850@psf.upfronthosting.co.za> Changes by Jes?s Cea Avi?n : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 06:46:53 2011 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Sep 2011 04:46:53 +0000 Subject: [issue12907] Update test coverage devguide page Message-ID: <1315284413.51.0.757189280849.issue12907@psf.upfronthosting.co.za> New submission from Brett Cannon : The devguide needs to be updated with new coverage.py instructions. It seems that the script in issue11561 has been integrated into coverage.py's own repo, which means we now have a way to get much more complete coverage of the stdlib. But it also means that users need to build the tracer extension in coverage.py. That might require a little extra hand-holding as compiling from a checkout can mean needing to unset CPPFLAGS in order to not pick up the system Python's header files. ---------- assignee: brett.cannon components: Devguide keywords: easy messages: 143581 nosy: brett.cannon priority: high severity: normal stage: needs patch status: open title: Update test coverage devguide page versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 06:47:02 2011 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Sep 2011 04:47:02 +0000 Subject: [issue12907] Update test coverage devguide page In-Reply-To: <1315284413.51.0.757189280849.issue12907@psf.upfronthosting.co.za> Message-ID: <1315284422.16.0.416960845159.issue12907@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +"coverage" of Python regrtest cannot see initial import of libs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 06:48:13 2011 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Sep 2011 04:48:13 +0000 Subject: [issue11561] "coverage" of Python regrtest cannot see initial import of libs In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za> Message-ID: <1315284493.55.0.893938124003.issue11561@psf.upfronthosting.co.za> Brett Cannon added the comment: Brandon, can I go ahead and close this and consider the script you and Ned have in the coverage.py repo to be the canonical script to use? ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 06:51:03 2011 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Sep 2011 04:51:03 +0000 Subject: [issue12908] Update dev-in-a-box for new coverage steps Message-ID: <1315284663.33.0.542797190768.issue12908@psf.upfronthosting.co.za> New submission from Brett Cannon : Once the devguide has been updated, dev-in-a-box needs to be tweaked to follow the new instructions on how to generate a coverage report. ---------- assignee: brett.cannon components: None messages: 143583 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Update dev-in-a-box for new coverage steps versions: 3rd party _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 06:51:10 2011 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Sep 2011 04:51:10 +0000 Subject: [issue12908] Update dev-in-a-box for new coverage steps In-Reply-To: <1315284663.33.0.542797190768.issue12908@psf.upfronthosting.co.za> Message-ID: <1315284670.06.0.883347272371.issue12908@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Update test coverage devguide page _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 07:32:15 2011 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 06 Sep 2011 05:32:15 +0000 Subject: [issue11561] "coverage" of Python regrtest cannot see initial import of libs In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za> Message-ID: <1315287135.88.0.24393401595.issue11561@psf.upfronthosting.co.za> Nick Coghlan added the comment: Do we really want to enshrine shadowing the encodings module as the one true way to do this kind of thing? Although I guess defining a way to do it properly would be a fairly major undertaking, so perhaps blessing the encodings hack is the practical way forward... If we do that, I'd like to see a devguide patch that better explains how to generate your own coverage data for the stdlib with coverage.py, the encodings hack and the standard library coverage option. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 07:49:19 2011 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=) Date: Tue, 06 Sep 2011 05:49:19 +0000 Subject: [issue1616] compiler warnings In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za> Message-ID: <1315288159.61.0.600797222424.issue1616@psf.upfronthosting.co.za> Jes?s Cea Avi?n added the comment: I see this in quite a few of the buildbots: (python 3.2) ./Modules/_io/iobase.c:707: warning: initialization from incompatible pointer type Seems to affect all current versions: 2.7, 3.2 and 3.x ---------- nosy: +jcea versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 08:37:27 2011 From: report at bugs.python.org (Georg Brandl) Date: Tue, 06 Sep 2011 06:37:27 +0000 Subject: [issue12850] [PATCH] stm.atomic In-Reply-To: <1314609941.13.0.16655342422.issue12850@psf.upfronthosting.co.za> Message-ID: <1315291047.45.0.427705098422.issue12850@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 08:39:28 2011 From: report at bugs.python.org (Georg Brandl) Date: Tue, 06 Sep 2011 06:39:28 +0000 Subject: [issue12906] Slight error in logging module's yaml config In-Reply-To: <1315280000.72.0.273608973729.issue12906@psf.upfronthosting.co.za> Message-ID: <1315291168.29.0.0033781279754.issue12906@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- assignee: docs at python -> vinay.sajip nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 09:09:58 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 06 Sep 2011 07:09:58 +0000 Subject: [issue12905] multiple errors in test_socket on OpenBSD In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za> Message-ID: <1315292998.26.0.369033267713.issue12905@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > I hope that this issue is not related to threads+signals. We got many > threads+signals issues on FreeBSD 6. Yep. OpenBSD has a really specific pthread implementation (in user-space, using non-blocking I/O), so it might very well be "yet another threads+signals occurrence". @R?mi What happens if you run a code equivalent to test_sendall_interrupted on its own? I mean, if you try something like this: """ import signal, socket c, s = socket.socketpair() signal.signal(signal.SIGALRM, lambda x,y: 0) signal.alarm(1) c.sendall(b"x" * (1024**2)) """ If it works, you could try creating a dummy thread before setting up the signal handler, something like: """ t = threading.Thread(target=lambda: 0) t.start() t.join() """ And retry. The problem with all those interruption tests (like issue #12903) is that they'll break on many *BSD if another thread is running. Although in this specific case, I suspect that there are no threads running, and we're really encountering a kernel/libc bug (Victor, remember the "funny" bug on FreeBSD where kill(getpid(), ) didn't deliver the signal synchronously after the first thread had been created?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 09:15:43 2011 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 06 Sep 2011 07:15:43 +0000 Subject: [issue12904] Change os.utime &c functions to use nanosecond precision where possible In-Reply-To: <1315256882.76.0.179568612134.issue12904@psf.upfronthosting.co.za> Message-ID: <1315293343.54.0.696937947309.issue12904@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The patch looks fine to me. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 09:40:18 2011 From: report at bugs.python.org (Nadeem Vawda) Date: Tue, 06 Sep 2011 07:40:18 +0000 Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions Message-ID: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za> New submission from Nadeem Vawda : The C functions for converting a Python 'int' object to a C integer are inconsistent about what exception gets raised when the object passed to them is not an integer. Most of these functions raise a TypeError, but PyLong_AsUnsignedLongLong() and PyLong_AsDouble() raise a SystemError instead. Raising a SystemError here is quite unhelpful. My understanding is that it is intended to indicate internal programming errors, so an extension module should not raise one when (for example) a function is passed an argument of the incorrect type. In such a case, raising a TypeError is a reasonable default. Is there any reason not to change the behaviour of these two functions to be consistent with their siblings? ---------- components: Interpreter Core messages: 143588 nosy: nadeem.vawda, pitrou priority: normal severity: normal stage: needs patch status: open title: Inconsistent exception usage in PyLong_As* C functions type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 09:47:06 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 06 Sep 2011 07:47:06 +0000 Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za> Message-ID: <1315295226.08.0.396632421138.issue12909@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +mark.dickinson, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 10:08:41 2011 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Sep 2011 08:08:41 +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: Roundup Robot added the comment: New changeset 786668a4fb6b by Victor Stinner in branch 'default': Issue #12567: Fix curses.unget_wch() tests http://hg.python.org/cpython/rev/786668a4fb6b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 10:42:55 2011 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 06 Sep 2011 08:42:55 +0000 Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za> Message-ID: <1315298575.04.0.332689439856.issue12105@psf.upfronthosting.co.za> ???? ????????? added the comment: O_CLOEXEC is not linux-only. Windows has the same flag. In file-opening functions there is lpSecurityAttributes argument. And there is bInheritHandle member of corresponding structure. http://msdn.microsoft.com/en-us/library/aa379560(v=VS.85).aspx : bInheritHandle A Boolean value that specifies whether the returned handle is inherited when a new process is created. If this member is TRUE, the new process inherits the handle. So, why not to implement 'e' letter in open()? it is true crossplatform. On platforms where inheritance does not work, flag should be ignored. P.S. Moreover, I think that all file-descriptor-crete functions (open, socket, pipe, dup, ...) should set CLOEXEC atomically ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 12:09:43 2011 From: report at bugs.python.org (Alexey Smirnov) Date: Tue, 06 Sep 2011 10:09:43 +0000 Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za> Message-ID: <1315303783.91.0.868066767653.issue12105@psf.upfronthosting.co.za> Alexey Smirnov added the comment: FreeBSD 8+ also supports O_CLOEXEC in open(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 12:26:39 2011 From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Hees?=) Date: Tue, 06 Sep 2011 10:26:39 +0000 Subject: [issue12910] urrlib.quote quotes too many chars, e.g., '()' Message-ID: <1315304798.98.0.174203108938.issue12910@psf.upfronthosting.co.za> New submission from J?rn Hees : urllib.quote('()') returns '%28%29' Looking into its code it tries to follow RFC 2396 (which is good even though it should follow rfc3986 nowadays), but it doesn't: http://tools.ietf.org/html/rfc2396 (see Appendix A, p.27): "(" and ")" are in mark and therefore unreserved, so why are they quoted? ---------- components: Library (Lib) messages: 143592 nosy: joern priority: normal severity: normal status: open title: urrlib.quote quotes too many chars, e.g., '()' type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 12:46:01 2011 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 06 Sep 2011 10:46:01 +0000 Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za> Message-ID: <1315305961.0.0.688388698873.issue12909@psf.upfronthosting.co.za> Mark Dickinson added the comment: +1 for turning these into TypeErrors. It makes little sense that PyLong_AsLongLong and PyLong_AsUnsignedLongLong behave differently here. Do you have a patch handy? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 13:29:33 2011 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 06 Sep 2011 11:29:33 +0000 Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za> Message-ID: <1315308573.92.0.184488900674.issue12105@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > O_CLOEXEC is not linux-only. Windows has the same flag. > In file-opening functions there is lpSecurityAttributes argument How do you suggest to use it? Even on Windows, python calls open(). And lpSecurityAttributes is an argument of CreateFile (which is the win32 kernel function that open() calls) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 13:37:41 2011 From: report at bugs.python.org (STINNER Victor) Date: Tue, 06 Sep 2011 11:37:41 +0000 Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za> Message-ID: <1315309061.48.0.585774264747.issue12105@psf.upfronthosting.co.za> STINNER Victor added the comment: Windows provides a _get_osfhandle() function. There is not the opposite function? :-) Anyway, O_CLOEXEC is not available on all platforms. Even on FreeBSD and Linux, it depends on the OS/kernel version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 13:54:32 2011 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 06 Sep 2011 11:54:32 +0000 Subject: [issue12910] urrlib.quote quotes too many chars, e.g., '()' In-Reply-To: <1315304798.98.0.174203108938.issue12910@psf.upfronthosting.co.za> Message-ID: <1315310072.71.0.252808310961.issue12910@psf.upfronthosting.co.za> Senthil Kumaran added the comment: It can aggressively put these chars !~*\'() in the safe list. I will look at the history to see if they originally present and were removed for some reason or they did not make it the list in the first place. If we do add, then it should be only 3.3 (Someone could be relying on the old behavior). ---------- assignee: -> orsenthil nosy: +orsenthil versions: +Python 3.3 -Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 13:57:49 2011 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Sep 2011 11:57:49 +0000 Subject: [issue1616] compiler warnings In-Reply-To: <1197577517.45.0.829785777717.issue1616@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset f24352b0df86 by Benjamin Peterson in branch 'default': merge 3.2 (#1616) http://hg.python.org/cpython/rev/f24352b0df86 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 14:20:10 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 06 Sep 2011 12:20:10 +0000 Subject: [issue12911] Expose a private accumulator C API Message-ID: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za> New submission from Antoine Pitrou : In 47176e8d7060, I fixed json to not blow memory when serializing a large container of small objects. It turns out that the repr() of tuple objects (and, very likely, list objects and possibly other containers) has the same problem. For example, Martin's 256GB machine can't serialize a two billion-element tuple: http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20parallel%20custom/builds/6/steps/test/logs/stdio So I propose to expose a private C API for the "accumulator" pattern introduced in 47176e8d7060 (with, e.g., the _PyAccumulator prefix), and to use that API from relevant code. ---------- components: Interpreter Core messages: 143598 nosy: mark.dickinson, pitrou, rhettinger priority: normal severity: normal status: open title: Expose a private accumulator C API type: resource usage versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 14:29:12 2011 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Tue, 06 Sep 2011 12:29:12 +0000 Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za> Message-ID: <1315312152.12.0.554984748871.issue12105@psf.upfronthosting.co.za> ???? ????????? added the comment: Some times ago, Python has used fopen() for open() implementation. Now, it uses OS-kernel native function to open files. AFAIK, open() in Windows is a wrapper around CreateFile, created to support some POSIX programs in Windows. Why not to use CreateFile() on Windows platform? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 14:40:47 2011 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 06 Sep 2011 12:40:47 +0000 Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za> Message-ID: <1315312847.78.0.920184131879.issue12105@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > Why not to use CreateFile() on Windows platform? Good idea! Please open a separate issue for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 14:56:31 2011 From: report at bugs.python.org (Dmitry Simonov) Date: Tue, 06 Sep 2011 12:56:31 +0000 Subject: [issue6327] [mimetext] long lines get cut with exclamation mark and newline In-Reply-To: <1245767587.65.0.844328731918.issue6327@psf.upfronthosting.co.za> Message-ID: <1315313791.4.0.213809701795.issue6327@psf.upfronthosting.co.za> Dmitry Simonov added the comment: Quote: ================== Notes Note that mailservers have a 990-character limit on each line contained within an email message. If an email message is sent that contains lines longer than 990-characters, those lines will be subdivided by additional line ending characters, which can cause corruption in the email message, particularly for HTML content. To prevent this from occurring, add your own line-ending characters at appropriate locations within the email message to ensure that no lines are longer than 990 characters. ================== ---------- nosy: +Dmitry.Simonov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 15:08:39 2011 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Sep 2011 13:08:39 +0000 Subject: [issue12906] Slight error in logging module's yaml config In-Reply-To: <1315280000.72.0.273608973729.issue12906@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 299ea19c3197 by Vinay Sajip in branch '2.7': Closes #12906: Fixed bug in YAML configuration. http://hg.python.org/cpython/rev/299ea19c3197 New changeset cf811943046b by Vinay Sajip in branch '3.2': Closes #12906: Fixed bug in YAML configuration. http://hg.python.org/cpython/rev/cf811943046b New changeset e9497423de7a by Vinay Sajip in branch 'default': Closes #12906: Merged fix from 3.2. http://hg.python.org/cpython/rev/e9497423de7a ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 15:09:54 2011 From: report at bugs.python.org (Brandon Craig Rhodes) Date: Tue, 06 Sep 2011 13:09:54 +0000 Subject: [issue11561] "coverage" of Python regrtest cannot see initial import of libs In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za> Message-ID: <1315314594.08.0.921952391427.issue11561@psf.upfronthosting.co.za> Brandon Craig Rhodes added the comment: Brett, yes, you are welcome to close this issue ? Ned quite handily convinced me that coverage code belongs in the "coverage" distribution, not languishing about in the CPython source tree. That solution also quite beautifully solves the copyright problem. So I happily withdraw my request for this feature. Nick, Brett is working on exactly the sort of devguide improvement that you suggest ? not least because the devguide will now need to instruct people in how to build "coverage" so that its C-accelerated tracer is available, which Ned's own patch to "coverage" to cover stdlib tracing uses instead of the Python tracer that I cut-and-pasted into this patch. Finally, it would be wonderful to have a more formal mechanism for boot-time interventions. I have mentioned before my wish that Python's first action be to open() the executable, check its tail to see if it's a valid zipfile, and if so to try loading and running "startup.py" from that zipfile. Among other things, that would allow single-file distribution of pure-Python applications without the py2exe/py2app mess that prevails in the projects I work with today. But since the whole issue of grabbing control at boot time raises hackles ("why would you want to do that!?"), and I needed something working immediately during the PyCon sprint, I elected to simply adopt "encodings.py" as my way in. It works great, and "coverage" can evolve to an even better mechanism as soon as one becomes available, should anyone want to take the bootup option and run with it. One final thought: should PyPy etc also implement the same boot protocol, should one be invented, so that all mainline interpreters can be instrumented the same way? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 15:33:55 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 06 Sep 2011 13:33:55 +0000 Subject: [issue12911] Expose a private accumulator C API In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za> Message-ID: <1315316035.78.0.298310631677.issue12911@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 15:41:45 2011 From: report at bugs.python.org (Rob Crittenden) Date: Tue, 06 Sep 2011 13:41:45 +0000 Subject: [issue12912] xmlrpclib.__version__ not bumped with updates Message-ID: <1315316505.08.0.403062949645.issue12912@psf.upfronthosting.co.za> New submission from Rob Crittenden : xmlrpclib.__version__ reports 1.0.1 from Python 2.7 in Fedora 14 and Python 2.6 in Fedora 12. I discovered this while trying to find a way to identify the version of xmlrpclib. The 2.7 xmlrpclib is not completely backward compatible with that in 2.6 Version-Release number of selected component (if applicable): python-2.7-7.fc14.x86_64 Steps to Reproduce: $ rpm -q python python-2.6.2-8.fc12.x86_64 $ python Python 2.6.2 (r262:71600, Jun 4 2010, 18:28:58) [GCC 4.4.3 20100127 (Red Hat 4.4.3-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xmlrpclib >>> xmlrpclib.__version__ '1.0.1' $ rpm -q python python-2.7-7.fc14.x86_64 $ python Python 2.7 (r27:82500, Jul 26 2010, 18:19:48) [GCC 4.5.0 20100716 (Red Hat 4.5.0-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import xmlrpclib >>> xmlrpclib.__version__ '1.0.1' ---------- components: Library (Lib) messages: 143604 nosy: rcritten priority: normal severity: normal status: open title: xmlrpclib.__version__ not bumped with updates versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 16:06:06 2011 From: report at bugs.python.org (Nadeem Vawda) Date: Tue, 06 Sep 2011 14:06:06 +0000 Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za> Message-ID: <1315317966.47.0.453874537282.issue12909@psf.upfronthosting.co.za> Nadeem Vawda added the comment: > Do you have a patch handy? See attached. ---------- keywords: +patch Added file: http://bugs.python.org/file23106/pylong-exceptions.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 16:18:38 2011 From: report at bugs.python.org (Nadeem Vawda) Date: Tue, 06 Sep 2011 14:18:38 +0000 Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za> Message-ID: <1315318718.41.0.0015267040599.issue12909@psf.upfronthosting.co.za> Nadeem Vawda added the comment: This probably shouldn't be backported to 3.2; it could break 3rd-party extension modules (though I would hope that nothing depends on this behaviour...). Also, it's worth noting that the error handling between conversion functions still isn't completely consistent - some attempt to coerce the argument to an integer using type->tp_as_number->nb_int, while others fail immediately when they see that PyLong_Check() fails. That's a less pressing issue, though. ---------- stage: needs patch -> patch review versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 16:20:24 2011 From: report at bugs.python.org (Derrick Petzold) Date: Tue, 06 Sep 2011 14:20:24 +0000 Subject: [issue12906] Slight error in logging module's yaml config In-Reply-To: <1315280000.72.0.273608973729.issue12906@psf.upfronthosting.co.za> Message-ID: <1315318824.88.0.988010789841.issue12906@psf.upfronthosting.co.za> Derrick Petzold added the comment: I know this is without etiquette but I must say holy shit that was quick and I can only hope that I do can do the same some day. Not with logging but maybe with something else. I think maybe I am already working on it. Hopefully maybe. Its hard to tell at times :). Ha but this (logging) helped me a lot ty again. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 16:51:24 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 14:51:24 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1315320684.27.0.879542353141.issue5845@psf.upfronthosting.co.za> ?ric Araujo added the comment: > Easily detecting interactive mode is of general interest for > customization. Thanks for the feedback. We could open a feature request for that, and/or ask python-ideas. > What if C also set sys.flags.interactive in "python" mode, or exposed > sys.flags.implicit_interactive (but with better name)? An attribute in the sys module sounds like a good idea. It would not be an attribute of sys.flags though, as those are strictly command-line arguments. > It's more useful to have a hook called when entering interactive mode, rather than a flag > that's set from the beginning: We already have such a hook: $PYTHONSTARTUP > calling e.g. sys.__interactivehook__ sounds even better. That?s another interesting idea. > BTW, drawback of doing any such setup in site.py: "python -S" would be unfriendly! People using -S don?t want the customizations done in site, so I don?t think there?s a problem here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 16:54:43 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 06 Sep 2011 14:54:43 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1315320684.27.0.879542353141.issue5845@psf.upfronthosting.co.za> Message-ID: <1315320714.3617.7.camel@localhost.localdomain> Antoine Pitrou added the comment: > > It's more useful to have a hook called when entering interactive mode, rather than a flag > > that's set from the beginning: > We already have such a hook: $PYTHONSTARTUP $PYTHONSTARTUP doesn't work with -i ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 17:00:14 2011 From: report at bugs.python.org (Thomas Wouters) Date: Tue, 06 Sep 2011 15:00:14 +0000 Subject: [issue11561] "coverage" of Python regrtest cannot see initial import of libs In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za> Message-ID: <1315321214.18.0.128892713458.issue11561@psf.upfronthosting.co.za> Thomas Wouters added the comment: For what it's worth, the need for a bootstrap-module has also come up within Google, where we have... somewhat different requirements than most. In order to fix import paths in a way that works even when using "python -S", I had a need to patch the very first module that gets imported. Unfortunately the actual first module that gets imported depends on the arguments passed to Python. So, I wrote the attached stdlib_landmark.diff patch, which makes a 'stdlib_landmark.py' file that is both the stdlib landmark (used by Python to find the stdlib itself, currently 'os.py') *and* the very first module that is imported, always. (The 'stdlib_landmark' name may be a little clunky; a better name, mirroring sitecustomize, may be "stdlibcustomize" or such.) And yes, this could have been fixed in other ways. I could've patched the interpreter directly, or made Python understand symlinks to .py/.pyc files better, or tried to make a bunch of other tools work better with symlinks. This has turned out the most convenient solution for a number of reasons, though. ---------- nosy: +twouters Added file: http://bugs.python.org/file23107/stdlib_landmark.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 17:19:06 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 15:19:06 +0000 Subject: [issue9561] distutils: set encoding to utf-8 for input and output files In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za> Message-ID: <1315322346.9.0.987829724764.issue9561@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I applied pkginfo_utf8.patch to Python 3.2 and 3.3. If you apply patches to distutils, please add tests for the fixed behavior. (Sorry if I wasn?t reactive on this one.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 17:25:47 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 15:25:47 +0000 Subject: [issue12895] In MSI/EXE installer, allow installing Python modules in free path In-Reply-To: <1315185843.85.0.324851460345.issue12895@psf.upfronthosting.co.za> Message-ID: <1315322747.39.0.402672588694.issue12895@psf.upfronthosting.co.za> ?ric Araujo added the comment: Martin, what do you think about this request? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 17:27:47 2011 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 06 Sep 2011 15:27:47 +0000 Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za> Message-ID: <1315322867.97.0.320035456775.issue12909@psf.upfronthosting.co.za> Mark Dickinson added the comment: > This probably shouldn't be backported to 3.2 Agreed; I don't see this as a bugfix (especially since AFAIK it's not documented that TypeError should be raised here); rather, as a design improvement. > Also, it's worth noting that the error handling between conversion > functions still isn't completely consistent True; there are a number of inconsistencies left. We'll get them all eventually. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 17:30:36 2011 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 06 Sep 2011 15:30:36 +0000 Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za> Message-ID: <1315323036.65.0.113209439842.issue12909@psf.upfronthosting.co.za> Mark Dickinson added the comment: The patch still needs tests (e.g., in test_capi). I'm not sure whether it would be good to add information about the TypeError to the docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 17:31:28 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 15:31:28 +0000 Subject: [issue12913] Add a debugging howto Message-ID: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za> New submission from ?ric Araujo : I found a few blogs posts that explained how to use pdb. It appears from the comments that such introductory material is very useful to a lot of users. Instead of just expanding the pdb module docs, I propose to add a debugging howto covering basic troubleshooting techniques and giving a pdb tutorial. I think a howto has more visibility, as people unaware of the existence of a thing named pdb may however look for ?debugging?. To educate myself on pdb, I have started writing a document. Before investing too much time, I?d like to know if people agree with the principle of adding such a howto. ---------- assignee: eric.araujo components: Documentation messages: 143615 nosy: eric.araujo priority: normal severity: normal status: open title: Add a debugging howto versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 17:35:38 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 15:35:38 +0000 Subject: [issue12902] help("modules") executes module code In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za> Message-ID: <1315323338.55.0.634988777296.issue12902@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for the report. This comes from the fact that pydoc imports the modules in order to get their documentation. Your message makes me think that the KWallet Python modules have a problem: they should not pop GUIs at import time! Please report this to them. In the Python docs, there is a note warning about this: http://docs.python.org/dev/library/pydoc . The doc for help, which is not on the same page, does not: http://docs.python.org/dev/library/functions#help It could be possible to load the code of a module without executing it. I?m not sure it would be a good idea; maybe you could ask for opinions on the python-ideas mailing list? ---------- components: -None nosy: +eric.araujo versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 17:40:16 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 15:40:16 +0000 Subject: [issue12910] urrlib.quote quotes too many chars, e.g., '()' In-Reply-To: <1315304798.98.0.174203108938.issue12910@psf.upfronthosting.co.za> Message-ID: <1315323616.8.0.296095900915.issue12910@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 17:54:27 2011 From: report at bugs.python.org (Cherniavsky Beni) Date: Tue, 06 Sep 2011 15:54:27 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1315320714.3617.7.camel@localhost.localdomain> Message-ID: Cherniavsky Beni added the comment: On Tue, Sep 6, 2011 at 17:54, Antoine Pitrou wrote: It covers the user's desire customization very well (esp. if it worked with -i). sys.__interactivehook__ has the benefit of being cleanly settable from python code. But it might well be a YAGNI idea. $PYTHONSTARTUP doesn't work with -i > Perhaps it should? I can't think of a thing that makes sense in $PYTHONSTARTUP that I wouldn't want with -i. (and if there is one, one can add a test for sys.flags.interactive, or run with env PYTHONSTARTUP='') Point to watch out for: errors in $PYTHONSTARTUP. One of the uses of "python -i script.py" is doing pdb.pm() on an exception thrown by the script; ideally a broken $PYTHONSTARTUP would not overr "customization" than editing? The fact that it'd be implemented in site.py? Yes, obviously, if it's implemented in site.py, -S should disable it. My point was that it doesn't have to be implemented there. You could drink the cool aid instead :-) ---------- Added file: http://bugs.python.org/file23108/unnamed _______________________________________ Python tracker _______________________________________ -------------- next part --------------

On Tue, Sep 6, 2011 at 17:54, Antoine Pitrou <report at bugs.python.org> wrote:

??ric Araujo <merwok at netwok.org> added the comment:
> > It's more useful to have a hook called when entering interactive mode, rather than a flag
> > that's set from the beginning:
> We already have such a hook: $PYTHONSTARTUP

Good point!
It covers the user's desire customization very well (esp. if it worked with -i).
sys.__interactivehook__ has the benefit of being cleanly settable from python code.
But it might well be a YAGNI idea.

$PYTHONSTARTUP doesn't work with -i
??
Perhaps it should?
I can't think of a thing that makes sense in $PYTHONSTARTUP that I wouldn't want with -i.
(and if there is one, one can add a test for??sys.flags.interactive, or run with env PYTHONSTARTUP='')
??
Point to watch out for: errors in $PYTHONSTARTUP.
One of the uses of "python -i script.py" is doing pdb.pm() on an exception thrown by the script;
ideally a broken $PYTHONSTARTUP would not overr

> BTW, drawback of doing any such setup in site.py: "python -S" would be unfriendly!People using -S don???t want the customizations done in site, so I don???t think there???s a problem here.

python -S doesn't disable readline. ??What makes completions more of a "customization" than editing?
The fact that it'd be implemented in site.py?
Yes, obviously, if it's implemented in site.py, -S should disable it. ??My point was that it doesn't have to be implemented there. ??You could drink the cool aid instead :-)
From report at bugs.python.org Tue Sep 6 18:05:06 2011 From: report at bugs.python.org (Cherniavsky Beni) Date: Tue, 06 Sep 2011 16:05:06 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1315325106.0.0.199487987908.issue5845@psf.upfronthosting.co.za> Cherniavsky Beni added the comment: [sorry, html mail was bad idea] On Tue, Sep 6, 2011 at 17:54, Antoine Pitrou wrote: ?ric Araujo added the comment: > > It's more useful to have a hook called when entering interactive mode, > > rather than a flag > > that's set from the beginning: > We already have such a hook: $PYTHONSTARTUP Good point! It covers the user's desire customization very well (esp. if it worked with -i). sys.__interactivehook__ has the benefit of being cleanly settable from python code. But it might well be a YAGNI idea. > $PYTHONSTARTUP doesn't work with -i Perhaps it should? I can't think of a thing that makes sense in $PYTHONSTARTUP that I wouldn't want with -i. (and if there is one, one can add a test for sys.flags.interactive, or run with env PYTHONSTARTUP='') Point to watch out for: errors in $PYTHONSTARTUP. One of the uses of "python -i script.py" is doing pdb.pm() on an exception thrown by the script; ideally a broken $PYTHONSTARTUP would not overr > > BTW, drawback of doing any such setup in site.py: "python -S" > > would be unfriendly! > People using -S don?t want the customizations done in site, so I > don?t think there?s a problem here. python -S doesn't disable readline. What makes completions more of a "customization" than editing? The fact that it'd be implemented in site.py? Yes, obviously, if it's implemented in site.py, -S should disable it. My point was that it doesn't have to be implemented there. You could drink the cool aid instead :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:05:46 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:05:46 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1315325146.59.0.416604984779.issue5845@psf.upfronthosting.co.za> Changes by ?ric Araujo : Removed file: http://bugs.python.org/file23108/unnamed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:06:06 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:06:06 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1315325166.19.0.385291708896.issue5845@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- Removed message: http://bugs.python.org/msg143617 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:07:45 2011 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 06 Sep 2011 16:07:45 +0000 Subject: [issue2636] Adding a new regex module (compatible with re) In-Reply-To: <1315009851.39.0.824707935624.issue2636@psf.upfronthosting.co.za> Message-ID: <4E664544.6070407@pearwood.info> Steven D'Aprano added the comment: Matthew Barnett wrote: > So, VERSION0 and VERSION1, with "(?V0)" and "(?V1)" in the pattern? Seems reasonable to me. +1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:13:27 2011 From: report at bugs.python.org (=?utf-8?q?Westley_Mart=C3=ADnez?=) Date: Tue, 06 Sep 2011 16:13:27 +0000 Subject: [issue11340] test_distutils fails because of borked compress program In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za> Message-ID: <1315325607.83.0.865438554223.issue11340@psf.upfronthosting.co.za> Westley Mart?nez added the comment: https://bugs.archlinux.org/task/25908 Looks like Allan will be taking care of this problem (eventually). I think this bug can be closed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:14:43 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:14:43 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1315325683.66.0.568942246473.issue5845@psf.upfronthosting.co.za> ?ric Araujo added the comment: > sys.__interactivehook__ has the benefit of being cleanly settable from python code. > But it might well be a YAGNI idea. I?ll ask python-dev about that. For the moment, I prefer the idea of a new sys.interactive attribute (boolean). >> $PYTHONSTARTUP doesn't work with -i > Perhaps it should? -i means two things: interactive and inspect. The second meaning is used when you want python to execute a script or module just as usual but without exiting afterward, to let you inspect the state of the program. Supporting PYTHONSTARTUP would change these use cases and be an unacceptable change. >> BTW, drawback of doing any such setup in site.py: "python -S" >> would be unfriendly! > People using -S don?t want the customizations done in site, so I > don?t think there?s a problem here. > python -S doesn't disable readline. > What makes completions more of a "customization" than editing? > The fact that it'd be implemented in site.py? If you go back to the first messages of this report, you?ll see that I wasn?t sure what a good location would be, and decided site because it did not look out of place. There isn?t a stronger rationale than that. One could argue that even now, site mixes disparate functionality: one program could wish to use -S to disable sys.path munging but run into bugs because the builtin exit is not defined anymore for example. > Yes, obviously, if it's implemented in site.py, -S should disable it. We agree. > My point was that it doesn't have to be implemented there. I really want to explore all options before renouncing to implement it in site. I?d like the implementation to be maintainable and shareable with other Python VMs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:16:46 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:16:46 +0000 Subject: [issue11340] test_distutils fails because of borked compress program In-Reply-To: <1298752200.14.0.360216595971.issue11340@psf.upfronthosting.co.za> Message-ID: <1315325806.12.0.568163110734.issue11340@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thank you for investigating. ---------- assignee: tarek -> eric.araujo resolution: fixed -> wont fix stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:18:31 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:18:31 +0000 Subject: [issue12906] Slight error in logging module's yaml config In-Reply-To: <1315280000.72.0.273608973729.issue12906@psf.upfronthosting.co.za> Message-ID: <1315325911.93.0.82773670036.issue12906@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks to you for the report and fix! ---------- nosy: +eric.araujo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:19:46 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:19:46 +0000 Subject: [issue12912] xmlrpclib.__version__ not bumped with updates In-Reply-To: <1315316505.08.0.403062949645.issue12912@psf.upfronthosting.co.za> Message-ID: <1315325986.57.0.701382623291.issue12912@psf.upfronthosting.co.za> ?ric Araujo added the comment: > The 2.7 xmlrpclib is not completely backward compatible with that in 2.6 Can?t you check sys.version_info then? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:28:08 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:28:08 +0000 Subject: [issue12914] Add cram function to textwrap Message-ID: <1315326488.16.0.0777914338919.issue12914@psf.upfronthosting.co.za> New submission from ?ric Araujo : The pydoc module has a cram function that could be useful to Python authors, if we made it public (textwrap sounds like a great place). ---------- components: Library (Lib) messages: 143625 nosy: eric.araujo priority: normal severity: normal status: open title: Add cram function to textwrap type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:30:33 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:30:33 +0000 Subject: [issue12915] Add inspect.locate and inspect.resolve Message-ID: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za> New submission from ?ric Araujo : The need to resolve a dotted name to a Python object is spreading in the stdlib: pydoc has locate and resolve, packaging has util.resolve_name, unittest has something else, etc. For the benefit of stdlib maintainers as well as the community, I think such functionality should be exposed publicly by the inspect module. ---------- components: Library (Lib) messages: 143626 nosy: eric.araujo priority: normal severity: normal status: open title: Add inspect.locate and inspect.resolve type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:32:27 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:32:27 +0000 Subject: [issue12916] Add inspect.splitdoc Message-ID: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za> New submission from ?ric Araujo : splitdoc is a hidden gem in pydoc: it?s a little helper to implement docstring splitting as documented in the docstrings PEPs. It is not a one-liner, so I think there is value in making it public in the inspect module. ---------- components: Library (Lib) messages: 143627 nosy: eric.araujo priority: normal severity: normal status: open title: Add inspect.splitdoc type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:34:28 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:34:28 +0000 Subject: [issue12917] Make visiblename and allmethods functions public Message-ID: <1315326868.85.0.0340726084847.issue12917@psf.upfronthosting.co.za> New submission from ?ric Araujo : pydoc contains these two functions that could be used by third-party code to implement a custom dir function, write a documentation tool or other uses: visiblename and allmethods. We could make them public, in pydoc or inspect. ---------- components: Library (Lib) messages: 143628 nosy: eric.araujo priority: normal severity: normal status: open title: Make visiblename and allmethods functions public type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:37:28 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:37:28 +0000 Subject: [issue12918] New module for terminal utilities Message-ID: <1315327048.11.0.179720377155.issue12918@psf.upfronthosting.co.za> New submission from ?ric Araujo : It was suggested in #7798 to make the pager functions from pydoc public. I can?t find a good place to put them, so I think we could add a new module with terminal-related utilities. It could contain the pager functions, progress bars (there are many implementations to be compared), ANSI and Windows color codes (reimplemented over and over again), etc. This may require a run through python-ideas and/or -dev, but I?m opening a bug for the record. ---------- components: Library (Lib) messages: 143629 nosy: eric.araujo priority: normal severity: normal status: open title: New module for terminal utilities type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:39:40 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 16:39:40 +0000 Subject: [issue7798] Make generally useful pydoc functions public In-Reply-To: <1264692401.66.0.0955816094505.issue7798@psf.upfronthosting.co.za> Message-ID: <1315327180.19.0.566785398359.issue7798@psf.upfronthosting.co.za> ?ric Araujo added the comment: I?ve looked hard at pydoc and opened distinct bug reports so that each piece of maybe-useful functionality can be discussed independently: #12918 New module for terminal utilities #12917 Make visiblename and allmethods functions public #12916 Add inspect.splitdoc #12915 Add inspect.locate and inspect.resolve #12914 Add cram function to textwrap ---------- resolution: -> invalid stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:48:59 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 06 Sep 2011 16:48:59 +0000 Subject: [issue12911] Expose a private accumulator C API In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za> Message-ID: <1315327739.15.0.202552027116.issue12911@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch against 3.2. In the default branch it will also help factor out some code from the _json module. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:49:26 2011 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 06 Sep 2011 16:49:26 +0000 Subject: [issue12911] Expose a private accumulator C API In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za> Message-ID: <1315327766.01.0.975236023962.issue12911@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- keywords: +patch Added file: http://bugs.python.org/file23109/accu.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 18:56:41 2011 From: report at bugs.python.org (Armin Rigo) Date: Tue, 06 Sep 2011 16:56:41 +0000 Subject: [issue5876] __repr__ returning unicode doesn't work when called implicitly In-Reply-To: <1241006313.4.0.792016858663.issue5876@psf.upfronthosting.co.za> Message-ID: <1315328201.5.0.263485758966.issue5876@psf.upfronthosting.co.za> Armin Rigo added the comment: A __repr__() that returns unicode can, in CPython 2.7 be used in "%s" % x or in u"%s" % x --- both expressions then return a unicode without doing any encoding --- but it cannot be used anywhere else, e.g. in "%r" % x or in repr(x). See also the PyPy issue https://bugs.pypy.org/issue857 . ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 19:01:23 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 17:01:23 +0000 Subject: [issue7219] Unhelpful error message when a distutils package install fails due to a permissions error In-Reply-To: <1256647071.1.0.815334810123.issue7219@psf.upfronthosting.co.za> Message-ID: <1315328483.4.0.257061289492.issue7219@psf.upfronthosting.co.za> Changes by ?ric Araujo : Removed file: http://bugs.python.org/file23101/unnamed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 19:02:11 2011 From: report at bugs.python.org (Roundup Robot) Date: Tue, 06 Sep 2011 17:02:11 +0000 Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled without threads In-Reply-To: <1314813822.31.0.567192327773.issue12871@psf.upfronthosting.co.za> Message-ID: Roundup Robot added the comment: New changeset 5c8b6e03ebfe by Charles-Fran?ois Natali in branch 'default': Issue #12871: sched_get_priority_(min|max) might not be defined even though http://hg.python.org/cpython/rev/5c8b6e03ebfe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 19:03:23 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 17:03:23 +0000 Subject: [issue7219] Unhelpful error message when a distutils package install fails due to a permissions error In-Reply-To: <1256647071.1.0.815334810123.issue7219@psf.upfronthosting.co.za> Message-ID: <1315328603.5.0.0308466813995.issue7219@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for testing the patch higery. I wonder if another exception was raised but ignored by unittest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 19:50:07 2011 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Sep 2011 17:50:07 +0000 Subject: [issue11561] "coverage" of Python regrtest cannot see initial import of libs In-Reply-To: <1300226950.96.0.51096652956.issue11561@psf.upfronthosting.co.za> Message-ID: <1315331407.93.0.779954462383.issue11561@psf.upfronthosting.co.za> Brett Cannon added the comment: Going to close this and open a separate feature request to better control what module is imported first. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 19:53:36 2011 From: report at bugs.python.org (Brett Cannon) Date: Tue, 06 Sep 2011 17:53:36 +0000 Subject: [issue12919] Control what module is imported first Message-ID: <1315331616.23.0.265275073086.issue12919@psf.upfronthosting.co.za> New submission from Brett Cannon : Issue11561 had a use case for controlling what module is imported first (along with a patch to use a module other than 'os' to control finding the stdlib). There have been others who could use this feature as well. ---------- components: Interpreter Core messages: 143636 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: Control what module is imported first type: feature request versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 19:56:44 2011 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 06 Sep 2011 17:56:44 +0000 Subject: [issue12895] In MSI/EXE installer, allow installing Python modules in free path In-Reply-To: <1315185843.85.0.324851460345.issue12895@psf.upfronthosting.co.za> Message-ID: <1315331804.22.0.416414487607.issue12895@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I don't think it's necessary. People who want to get at the files can do an administrative installation, and put the files anywhere they like. Therefore, I won't work on this myself; somebody would have to contribute the code. It will be difficult to allow multiple simultaneous installations into different paths, which I think the OP would want - so even if the literal request from msg143503 is satisfied, the actual issue probably remains as unimplementable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 19:58:10 2011 From: report at bugs.python.org (Rob Crittenden) Date: Tue, 06 Sep 2011 17:58:10 +0000 Subject: [issue12912] xmlrpclib.__version__ not bumped with updates In-Reply-To: <1315316505.08.0.403062949645.issue12912@psf.upfronthosting.co.za> Message-ID: <1315331890.41.0.383422511095.issue12912@psf.upfronthosting.co.za> Rob Crittenden added the comment: Yes, this is the solution I ended up using as a workaround. I figured that since xmlrpclib has its own version it should be meaningful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 19:58:18 2011 From: report at bugs.python.org (Ram Rachum) Date: Tue, 06 Sep 2011 17:58:18 +0000 Subject: [issue12895] In MSI/EXE installer, allow installing Python modules in free path In-Reply-To: <1315185843.85.0.324851460345.issue12895@psf.upfronthosting.co.za> Message-ID: <1315331898.83.0.439430778721.issue12895@psf.upfronthosting.co.za> Ram Rachum added the comment: Martin, what do you mean "administrative installation"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 20:01:03 2011 From: report at bugs.python.org (Remi Pointel) Date: Tue, 06 Sep 2011 18:01:03 +0000 Subject: [issue12905] multiple errors in test_socket on OpenBSD In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za> Message-ID: <1315332063.76.0.155696048659.issue12905@psf.upfronthosting.co.za> Remi Pointel added the comment: > What happens if you run a code equivalent to test_sendall_interrupted on its own? I mean, if you try something like this: Hi, it blocks too: $ gdb -args ./python [...] (gdb) run Starting program: /usr/ports/pobj/Python-3.2.2/Python-3.2.2/python Python 3.2.2 (default, Sep 5 2011, 21:21:34) [GCC 4.2.1 20070719 ] on openbsd5 Type "help", "copyright", "credits" or "license" for more information. >>> import signal, socket >>> c, s = socket.socketpair() >>> signal.signal(signal.SIGALRM, lambda x,y: 0) 0 >>> signal.alarm(1) 0 >>> [New process 28830] c.sendall(b"x" * (1024**2)) ^C Program received signal SIGINT, Interrupt. Cannot access memory at address 0x98 (gdb) bt #0 0x000000020125678a in poll () from /usr/lib/libc.so.60.1 #1 0x000000020619b4aa in _thread_kern_poll (wait_reqd=) at /usr/src/lib/libpthread/uthread/uthread_kern.c:780 #2 0x000000020619c3a8 in _thread_kern_sched (scp=0x0) at /usr/src/lib/libpthread/uthread/uthread_kern.c:382 #3 0x0000000206190ade in sendto (fd=9, msg=0x2032d6020, len=1044480, flags=0, to=0x0, to_len=0) at /usr/src/lib/libpthread/uthread/uthread_sendto.c:63 #4 0x00000002105f670a in sock_sendall () from /usr/ports/pobj/Python-3.2.2/Python-3.2.2/build/lib.openbsd-5.0-amd64-3.2/_socket.so #5 0x000000020668b172 in PyEval_EvalFrameEx () from /usr/local/lib/libpython3.2m.so.1.0 #6 0x000000020668bf66 in PyEval_EvalCodeEx () from /usr/local/lib/libpython3.2m.so.1.0 #7 0x000000020668c22b in PyEval_EvalCode () from /usr/local/lib/libpython3.2m.so.1.0 #8 0x00000002066a93d7 in run_mod () from /usr/local/lib/libpython3.2m.so.1.0 #9 0x00000002066abcae in PyRun_InteractiveOneFlags () from /usr/local/lib/libpython3.2m.so.1.0 #10 0x00000002066abf3e in PyRun_InteractiveLoopFlags () from /usr/local/lib/libpython3.2m.so.1.0 #11 0x00000002066ac04c in PyRun_AnyFileExFlags () from /usr/local/lib/libpython3.2m.so.1.0 #12 0x00000002066bc9f4 in Py_Main () from /usr/local/lib/libpython3.2m.so.1.0 #13 0x0000000000400e75 in main () Thanks for your help, Remi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 20:05:58 2011 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 06 Sep 2011 18:05:58 +0000 Subject: [issue12912] xmlrpclib.__version__ not bumped with updates In-Reply-To: <1315316505.08.0.403062949645.issue12912@psf.upfronthosting.co.za> Message-ID: <1315332358.89.0.039392573748.issue12912@psf.upfronthosting.co.za> ?ric Araujo added the comment: > I figured that since xmlrpclib has its own version it should be meaningful. That was most probably the intent of the attribute, but it seems to have become unmaintained. In any case, a change could not be done in a 2.7 bugfix release. Maybe it?s worth changing it in 3.3, or it could just be removed. BTW: > The 2.7 xmlrpclib is not completely backward compatible with that in 2.6 Do you mean that your code relied on bugs or undocumented behavior, or that you?ve found regressions? If it?s the later, please report bugs. ---------- nosy: +benjamin.peterson, georg.brandl versions: +Python 3.3 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 20:29:54 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 06 Sep 2011 18:29:54 +0000 Subject: [issue12871] Disable sched_get_priority_min/max if Python is compiled without threads In-Reply-To: <1314813822.31.0.567192327773.issue12871@psf.upfronthosting.co.za> Message-ID: <1315333794.63.0.15162730495.issue12871@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 20:33:56 2011 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 06 Sep 2011 18:33:56 +0000 Subject: [issue12905] multiple errors in test_socket on OpenBSD In-Reply-To: <1315332063.76.0.155696048659.issue12905@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Hi, it blocks too: Oops, I just realized there was a typo in the sample test. The signal handler should be lambda x,y: 1/0 and not lambda x,y: 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 20:35:46 2011 From: report at bugs.python.org (Rob Crittenden) Date: Tue, 06 Sep 2011 18:35:46 +0000 Subject: [issue12912] xmlrpclib.__version__ not bumped with updates In-Reply-To: <1315316505.08.0.403062949645.issue12912@psf.upfronthosting.co.za> Message-ID: <1315334146.6.0.722125308209.issue12912@psf.upfronthosting.co.za> Rob Crittenden added the comment: Python 2.7 changed the internal class used in xmlrpclib from HTTP to HTTPConnection. I have code that subclasses httplib.HTTP to use the python-nss package to create a connection over SSL (similiar to httplib.HTTPS). My code currently looks something like this as a workaround: class NSSConnection(httplib.HTTPConnection) ... class NSSHTTPS(httplib.HTTP): _connection_class = NSSConnection def __init__ ... def connect(): (major, minor, micro, releaselevel, serial) = sys.version_info if major == 2 and minor < 7: conn = NSSHTTPS(host, 443, dbdir="/etc/pki/nssdb") else: conn = NSSConnection(host, 443, dbdir="/etc/pki/nssdb") Full code is at https://fedorahosted.org/freeipa/browser/ipalib/rpc.py and https://fedorahosted.org/freeipa/browser/ipapython/nsslib.py At least one other person has run into this, https://techknowhow.library.emory.edu/blogs/branker/2011/07/01/python-27-xmlrpclibtransport-backward-compatibility ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 20:37:20 2011 From: report at bugs.python.org (Larry Hastings) Date: Tue, 06 Sep 2011 18:37:20 +0000 Subject: [issue11457] Expose nanosecond precision from system calls In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za> Message-ID: <1315334240.43.0.761005215361.issue11457@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's a better idea: we add a new IEEE 754-2008 quad-precision float type. The IEEE 754-2008 quad precision float has 1 sign bit, 15 bits of exponent, and 112 bits of mantissa, so it should have enough precision to last utime until humanity transforms itself into a single angelic being of pure light and energy. GCC has had __float128 since 4.3, Clang has __float128 now too, Intel's compiler has _Quad. It looks like Visual C++ doesn't support it yet--it does support a funny 80-bit float but I don't think Python wants to go there. I realize a new float type would be a major undertaking, but it seems to me that that's really the right way to do it. Nobody would have to change their code, and it'd behave like the existing float. It'd be just like 2.x, with "int" and "long"! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 20:37:58 2011 From: report at bugs.python.org (Popa Claudiu) Date: Tue, 06 Sep 2011 18:37:58 +0000 Subject: [issue12920] Inspect.getsource fails to get source of local classes Message-ID: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za> New submission from Popa Claudiu : inspect.getsource called with a class defined in the same file fails with TypeError: is a built-in class, although the documentation says that: "The argument may be a module, class, method, function, traceback, frame, or code object. The source code is returned as a single string." I think that should be specified in documentation that this function works only for objects living in a module. ---------- assignee: docs at python components: Documentation messages: 143645 nosy: Popa.Claudiu, docs at python priority: normal severity: normal status: open title: Inspect.getsource fails to get source of local classes type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 6 20:41:54 2011 From: report at bugs.python.org (Paul Upchurch) Date: Tue, 06 Sep 2011 18:41:54 +0000 Subject: [issue12921] http.server.BaseHTTPRequestHandler.send_error and trailing newline Message-ID: <1315334514.02.0.137561826697.issue12921@psf.upfronthosting.co.za> New submission from Paul Upchurch : Calling http.server.BaseHTTPRequestHandler.send_error(code,message) with a message that contains a trailing newline does not display properly in Firefox, Chrome. Listing 1 #!/usr/bin/env python3.2 import http.server import traceback class httphandler(http.server.BaseHTTPRequestHandler): def do_GET(self): try: assert(False) except: self.send_error(500,traceback.format_exc()) if __name__=='__main__': addr=('',9000) http.server.HTTPServer(addr,httphandler).serve_forever() Consider Listing 1. A typical programming idiom would be to wrap do_GET with a try/except block that reports an HTTP error with an HTML formatted stack trace. However, when I view this with Firefox and Chrome the error message is unformatted, i.e. raw HTML is displayed. A simple workaround is to call strip() on the message. This could be suggested to the user in the docs, or added as an automatic preprocessing feature to the library. With strip(), the message is formatted. Adding or documenting strip() resolves the bug. The remainder of this report is a feature request. The default error_message_format is probably not what people want for a stack trace. It leaves formatting of whitespace to the HTML which removes the newlines. This is desirable for short, unformatted messages but undesirable for a preformatted traceback. In Listing 2 I give a working solution and suggest including it in the library if the community feels that preformatted messages are common enough to warrant extra attention. I feel it is since "try/except: print traceback" is almost mandatory for error prone internet operations. Listing 2 #!/usr/bin/env python3.2 import http.server import traceback class httphandler(http.server.BaseHTTPRequestHandler): def content_aware_error_message_format(self,m): oldfmt='

Message: %(message)s.\n' if oldfmt in self.error_message_format: # use 

 if the message contains a newline internally
      # otherwise let the html control line breaks
      self.error_message_format=self.error_message_format.replace(oldfmt,'
%(message)s
\n') if '\n' in m else self.error_message_format.replace(oldfmt,'
%(message)s\n')
  def do_GET(self):
    try:
      assert(False)
    except:
      m=traceback.format_exc().strip()
      self.content_aware_error_message_format(m)
      self.send_error(500,m)

if __name__=='__main__':
  addr=('',9000)
  http.server.HTTPServer(addr,httphandler).serve_forever()

----------
components: Library (Lib)
messages: 143646
nosy: Paul.Upchurch
priority: normal
severity: normal
status: open
title: http.server.BaseHTTPRequestHandler.send_error and trailing newline
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep  6 21:23:42 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 06 Sep 2011 19:23:42 +0000
Subject: [issue12895] In MSI/EXE installer,
	allow installing Python modules in free path
In-Reply-To: <1315331898.83.0.439430778721.issue12895@psf.upfronthosting.co.za>
Message-ID: <4E66733B.2070308@v.loewis.de>


Martin v. L?wis  added the comment:

> Martin, what do you mean "administrative installation"?

That's what you get when you do "msiexec /a .msi".

http://en.wikipedia.org/wiki/Windows_Installer#Administrative_installation

----------
title: In MSI/EXE installer, allow installing Python modules in free path -> In MSI/EXE installer,	allow installing Python modules in free path

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep  6 21:36:14 2011
From: report at bugs.python.org (Eric Snow)
Date: Tue, 06 Sep 2011 19:36:14 +0000
Subject: [issue12919] Control what module is imported first
In-Reply-To: <1315331616.23.0.265275073086.issue12919@psf.upfronthosting.co.za>
Message-ID: <1315337774.29.0.0698252213967.issue12919@psf.upfronthosting.co.za>


Changes by Eric Snow :


----------
nosy: +eric.snow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep  6 22:18:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Sep 2011 20:18:23 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1315340303.51.0.716084854968.issue12905@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

I tried the following script on OpenBSD 5 with Python 3.3:
-----------                                                                                                          
import signal
import sys

s = signal.SIGALRM
signal.signal(s, lambda x,y: 1/0)
signal.alarm(1)
signal.siginterrupt(s, True)
sys.stdin.read()
-----------

The C signal handler is called, but the system call (read in this case) is not interrupted.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep  6 22:48:50 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 06 Sep 2011 20:48:50 +0000
Subject: [issue12922] StringIO and seek()
Message-ID: <1315342130.67.0.227650351498.issue12922@psf.upfronthosting.co.za>


New submission from Terry J. Reedy :

First, there is a minor documentation issue.
15.2.3.1. I/O Base Classes
class io.IOBase
seek(offset, whence=SEEK_SET) 
Change the stream position to the given byte offset

Since StringIO seeks by code units that should perhaps say 'byte or code unit offset' or a separate note should be added to the doc entry for StringIO.

>>> txt = StringIO('ab\U00010030')
>>> txt.seek(3)
3
>>> txt.write('x')
1
>>> txt.getvalue()
'ab\ud800x'

The behavior problem is that seeking for StringIO does not work relative to the current position or end.

IOError: Can't do nonzero cur-relative seeks
# Note: this message is wrong for end-relative seeks.

I presume this is inherited from an undocumented restriction on seeking with text streams, because chars *might* be variably sized. However, I do not think it should be. StringIO does not inherit the same reason for the restriction (certainly not on wide builds, and on narrow builds, seeking from the beginning is just as problematical). For StringIO, there is no option of 'opening in binary (byte) mode instead' as there is for disk files. Since a StringIO object is a wrapped array of fixed-size units, seeking from any position is as trivial as it is from the beginning. And again, the current docs imply that it should work.

Note that seeking from the beginning is not limited to the existing content. Instead, skipped areas are filled with nulls.

from io import StringIO
txt = StringIO('0123456789')
txt.seek(15,0) # no problem with absolute seek
txt.write('xxx')
s  = txt.getvalue()
print(ord(s[12]))
# 0

So that is not a reason to limit seeking from other positions either.

----------
components: Library (Lib)
messages: 143649
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: StringIO and seek()
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep  6 22:58:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Sep 2011 20:58:04 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1315342684.39.0.195055177488.issue12905@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> I tried the following script on OpenBSD 5 with Python 3.3: ...

Bad news: the script doesn't hang if Python is build without threads.

Short C program to test interrupted syscalls:
-------------                                                                                                    
#include 
#include 
#include 

void
handler(int signum)
{
printf("HANDLER!\n");
}

void _noop()
{
}

int main()
{
int s = SIGALRM;
char buffer[1024];
int n;
static int dummy = 0;

pthread_t thread1;
pthread_create(&thread1, NULL, (void *) _noop, &dummy);
pthread_join(thread1, NULL);


signal(s, handler);
siginterrupt(s, 1);
alarm(1);
printf("read...\n");
n = read(0, buffer, 1024);
printf("read->%i\n", n);
return 0;
}
-------------

read() is interrupted after 1 second, it works.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep  6 23:06:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Sep 2011 21:06:43 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1315343203.5.0.24644450982.issue12905@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

Oh, siginterrupt(SIGALRM, 0) doesn't work in a program linked to pthread. Example:
--------
#include 
#include 

void
handler(int signum)
{ printf("HANDLER!\n"); }

int main()
{
int s = SIGALRM;
char buffer[1024];
int n;

signal(s, handler);
siginterrupt(s, 0);
alarm(1);
printf("read...\n");
n = read(0, buffer, 1024);
printf("read->%i\n", n);
return 0;
}
--------
This program ends after 1 second with "read->-1" if it is linked to pthread (bug!), it hangs if it is not linked to pthread (ok).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep  6 23:19:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 06 Sep 2011 21:19:37 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1315343977.22.0.80755603816.issue12905@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> The C signal handler is called, but the system call (read in this case)
> is not interrupted.

That's what I thought...

> Bad news: the script doesn't hang if Python is build without threads.

Makes sense. When linked with pthread, all I/O syscalls are actually non-blocking.

> read() is interrupted after 1 second, it works.

Hmmm...
Does it still work if you don't a create thread beforehand?

Also, one difference is that Python uses sigaction to setup the signal handler. There might be subtle semantics change/bugs between signal/sigaction.

> Oh, siginterrupt(SIGALRM, 0) doesn't work in a program linked to
> pthread.

You could try with sigaction/SA_RESTART.

But OpenBSD's pthread implementation has severe limitations/bugs.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep  6 23:46:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Sep 2011 21:46:16 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1315345576.61.0.523842116768.issue12905@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> > read() is interrupted after 1 second, it works.
> Does it still work if you don't a create thread beforehand?

Yes, the read() is also interrupted as expected if no thread is created.

> one difference is that Python uses sigaction to setup the signal handler

If the handler is installed using the following code, read() is interrupted:
----------
sigemptyset(&sa.sa_mask);
sa.sa_handler = handler;
sa.sa_flags = 0;
sigaction(SIGALRM, &sa, NULL);
----------

Using sa.sa_flags=SA_RESTART, read() hangs (it is not interrupted). Python uses sigaction with flags=0.

> You could try with sigaction/SA_RESTART.

Using SA_RESTART, read() is not interrupted. But if the program is linked to pthread, read() is always interrupted: with sa_flags=0 or sa_flags=SA_RESTART.

> But OpenBSD's pthread implementation has severe limitations/bugs.

rthread doc contains:

"Future work:

Quite simply, signal handling is one the most complicated aspects of threads to get right. (...)"

http://www.openbsd.org/papers/eurobsd2005/tedu-rthreads.pdf

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 00:00:40 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 06 Sep 2011 22:00:40 +0000
Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions
In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za>
Message-ID: <1315346440.69.0.83290132579.issue12909@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

Attached is an updated patch with tests.

There don't seem to be any tests for PyLong_AsS[s]ize_t() and
PyLong_AsDouble(), so I added new ones for this issue. They should still
be expanded on at some point in the future, but for the meanwhile this
should be sufficient.

> I'm not sure whether it would be good to add information about the TypeError to the docs.

Yeah, that doesn't seem necessary; raising TypeError in this sort of
situation is sufficiently typical behavior that explicitly documenting
it feels redundant.

----------
assignee:  -> nadeem.vawda
Added file: http://bugs.python.org/file23110/pylong-exceptions.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 00:48:02 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Sep 2011 22:48:02 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za>
Message-ID: <1315349282.51.0.383249010671.issue12911@psf.upfronthosting.co.za>


Antoine Pitrou  added the comment:

For the record, the patch fixes the test_bigmem crashes when testing repr() on tuples and lists:
http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20parallel%20custom/builds/10/steps/test/logs/stdio

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 01:16:08 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 06 Sep 2011 23:16:08 +0000
Subject: [issue12788] test_email fails with -R
In-Reply-To: <1313802442.52.0.218487753455.issue12788@psf.upfronthosting.co.za>
Message-ID: <1315350968.28.0.151904816033.issue12788@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 01:17:00 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 06 Sep 2011 23:17:00 +0000
Subject: [issue12921] http.server.BaseHTTPRequestHandler.send_error and
	trailing newline
In-Reply-To: <1315334514.02.0.137561826697.issue12921@psf.upfronthosting.co.za>
Message-ID: <1315351020.5.0.127549122512.issue12921@psf.upfronthosting.co.za>


Changes by Senthil Kumaran :


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 01:40:58 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 06 Sep 2011 23:40:58 +0000
Subject: [issue12923] test_urllib fails in refleak mode
Message-ID: <1315352458.41.0.979039254957.issue12923@psf.upfronthosting.co.za>


New submission from Stefan Krah :

Hi,

test_urllib fails in refleak mode:

./python -m test -uall -v -R : test_urllib


======================================================================
FAIL: test_invalid_redirect (test.test_urllib.urlopen_HttpTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stefan/hg/cpython/Lib/test/test_urllib.py", line 235, in test_invalid_redirect
    "http://python.org/")
AssertionError: HTTPError not raised by urlopen

----------------------------------------------------------------------
Ran 58 tests in 0.075s

FAILED (failures=1, skipped=1)
test test_urllib failed
1 test failed:
    test_urllib
[133995 refs]

----------
components: Tests
messages: 143656
nosy: orsenthil, skrah
priority: normal
severity: normal
status: open
title: test_urllib fails in refleak mode
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 02:12:38 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Wed, 07 Sep 2011 00:12:38 +0000
Subject: [issue5149] syntactic sugar: type coercion on pointer assignment
In-Reply-To: <1233710403.4.0.267443476473.issue5149@psf.upfronthosting.co.za>
Message-ID: <1315354358.94.0.409947550163.issue5149@psf.upfronthosting.co.za>


Vlad Riscutia  added the comment:

I believe there is a deeper issue here in ctypes design. Basically we provide both c_char_p and POINTER(c_char) which should behave exactly the same since both are the equivalent of char* in C but internally they have different implementations.

c_char_p is considered a "simple type" and I believe supports some conversions to and from Python strings while POINTER(c_char) is considered a pointer type which supports assignment from array etc.

I think a better fix would be to deprecate p_char_p or make it an equivalent of POINTER(c_char), otherwise we will have to do work on c_char_p to make it more like POINTER(c_char) when issues like this get opened and probably also make POINTER(c_char) more like c_char_p. Why not just have POINTER(c_char) which works as expected? I don't have all the historical context on why this pseudo-simple type was provided but I saw a couple of issues where people expect it to behave like a C char* but it won't because it is implemented as a convenience type with limited support.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 02:31:44 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Sep 2011 00:31:44 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za>
Message-ID: <1315355504.22.0.0980846602013.issue12911@psf.upfronthosting.co.za>


Antoine Pitrou  added the comment:

Updated patch (mostly cosmetic stuff) after Benjamin's comments.

----------
Added file: http://bugs.python.org/file23111/accu2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 03:01:29 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 07 Sep 2011 01:01:29 +0000
Subject: [issue5149] syntactic sugar: type coercion on pointer assignment
In-Reply-To: <1233710403.4.0.267443476473.issue5149@psf.upfronthosting.co.za>
Message-ID: <1315357289.45.0.90042321684.issue5149@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Vlad, I agree that having both 'c_char_p' and 'POINTER(c_char)' will just be more work for two seemingly identical constructs.  I don't fully understand why both would be needed either (or the implications of removing one of them or making them synonyms).  I guess a little software archeology is in order.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 06:25:59 2011
From: report at bugs.python.org (Jason Gerard DeRose)
Date: Wed, 07 Sep 2011 04:25:59 +0000
Subject: [issue11677] make test has horrendous performance on an ecryptfs
In-Reply-To: <1301092248.42.0.811586375377.issue11677@psf.upfronthosting.co.za>
Message-ID: <1315369559.86.0.0446591758896.issue11677@psf.upfronthosting.co.za>


Jason Gerard DeRose  added the comment:

Barry,

I'm suspicious there might be more to the performance issue than just the ecryptfs overhead.  While experimenting with a read benchmark, I just happened to notice that when reading from an ecryptfs filesystem, the CPU usage is unusually high in the *python3* process.

For example:

./benchmark.py /home/.dmedia
  => 149 MB per second
  => top shows 22-24% CPU usage

./benchmark.py /home/jderose/.dmedia
  => 38.9 MB per second
  => top shows 79-85% CPU usage

It's the same physical drive in both cases, but the one in /home/jderose is ecryptfs.  If it was just ecryptfs overhead, wouldn't there be lower CPU utilization in the python3 process, as there would be a lower throughput coming from the kernel, more time waiting on IO?

In both cases, there were 56 files, for a total of 19.5 GB.  I ran this on 64-bit Ubuntu Oneiric, Python 3.2.2.

Here's the benchmark:

http://bazaar.launchpad.net/~jderose/filestore/multi/view/head:/benchmark.py

----------
nosy: +jderose

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 06:54:48 2011
From: report at bugs.python.org (Jason Gerard DeRose)
Date: Wed, 07 Sep 2011 04:54:48 +0000
Subject: [issue11677] make test has horrendous performance on an ecryptfs
In-Reply-To: <1301092248.42.0.811586375377.issue11677@psf.upfronthosting.co.za>
Message-ID: <1315371288.54.0.931847603363.issue11677@psf.upfronthosting.co.za>


Jason Gerard DeRose  added the comment:

Oops, I think I don't understand the meaning of top CPU usage, as time tells a different story.

Direct ext4:
real	2m14.144s
user	0m0.260s
sys	0m30.350s

ecryptfs over ext4:
real	8m47.130s
user	0m0.080s
sys	7m2.080s

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 07:03:04 2011
From: report at bugs.python.org (Matt Chaput)
Date: Wed, 07 Sep 2011 05:03:04 +0000
Subject: [issue12870] Regex object should have introspection methods
In-Reply-To: <1314811774.34.0.509713448629.issue12870@psf.upfronthosting.co.za>
Message-ID: <1315371784.42.0.604995412243.issue12870@psf.upfronthosting.co.za>


Matt Chaput  added the comment:

Ezio, no offense, but I think it's safe to say you've completely misunderstood this bug. It is not about "explaining what a regex matches" or optimizing the regex. Read the last sentences of the two paragraphs explaining the proposed methods for the use cases. This is about allowing MY CODE to programmatically get certain information about a regex object to allow it to limit the number of times it has to call regex.match(). AFAIK there's no good way to get this information about a regex object without adding these methods or building my own pure-Python regex interpreter, which would be both Herculean and pointless.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 07:58:33 2011
From: report at bugs.python.org (Jon Parise)
Date: Wed, 07 Sep 2011 05:58:33 +0000
Subject: [issue12924] Missing call to quote_plus() in
	test_urllib.test_default_quoting()
Message-ID: <1315375113.16.0.494762103225.issue12924@psf.upfronthosting.co.za>


New submission from Jon Parise :

test_default_quoting() runs a number of identical tests on both quote() and quote_plus() (which is most cases have equivalent behavior).  However, at the end of the method, there appears to be a missing complementary call to quote_plus() despite there being an assertion call for the quote_plus() case.

----------
components: Tests
files: test_urllib.default_quoting.patch
keywords: patch
messages: 143663
nosy: jon
priority: normal
severity: normal
status: open
title: Missing call to quote_plus() in test_urllib.test_default_quoting()
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23112/test_urllib.default_quoting.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 08:07:50 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 07 Sep 2011 06:07:50 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za>
Message-ID: <1315375670.55.0.393326328767.issue12911@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

I'm -1 on this approach; I don't think yet another container type is the right solution, given that we have already plenty of them.

If you want to avoid creating large lists, then the StringIO type should already provide that. So I wonder why these functions couldn't be rewritten to use StringIO.

If you really want to use this approach, I'd try to avoid allocating the large list if there are only few substrings. I.e. allocate it only when flushing, and only if the flush is not the final flush.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 08:13:38 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 07 Sep 2011 06:13:38 +0000
Subject: [issue12924] Missing call to quote_plus() in
	test_urllib.test_default_quoting()
In-Reply-To: <1315375113.16.0.494762103225.issue12924@psf.upfronthosting.co.za>
Message-ID: <1315376018.94.0.502843052959.issue12924@psf.upfronthosting.co.za>


Changes by Senthil Kumaran :


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 10:20:06 2011
From: report at bugs.python.org (Leo Shklovskii)
Date: Wed, 07 Sep 2011 08:20:06 +0000
Subject: [issue1043134] Add preferred extensions for MIME types
Message-ID: <1315383606.92.0.396032998607.issue1043134@psf.upfronthosting.co.za>


Leo Shklovskii  added the comment:

I'm running into a similar issue with this function. My bug is that get_type('foo.png') returns image/x-png. This occurs on windows because there are mappings to both image/png and image/x-png in the registry (as there should be, since that key is actually a reverse mapping) and the code simply picks the first key that it enumerates over. This issue strikes in both directions.

Chris and others bring up a valid issue: how to decide what the winning result is?

I think the answer is pretty clear - you use the common_types mapping already in the file and expand it as appropriate. If the mimetype can't be found, only then do you go to the windows registry. The behavior on Linux is even stranger to me (now we'll dig through an arbitrary list of files that might contain MIME info or may have completely irrelevant data) but it's a pragmatic solution.

If someone needs to customize what guess_type returns, they can simply wrap the guess_type function in their own code or monkey patch if they don't have access to the source they're running. Changing such a mime type is a really advanced and unusual operation. If that's unacceptable, the code can provide a hook for an 'apache MIME config' file on windows in a standard place (either pythonpath, or %system% or wherever) that it will check before going to common_types or to the registry.

Making this change doesn't require changing the API at all, just the implementation changes.

----------
nosy: +leos
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 10:41:04 2011
From: report at bugs.python.org (Sergei Stolyarov)
Date: Wed, 07 Sep 2011 08:41:04 +0000
Subject: [issue12925] python setup.py upload_docs doesn't ask for login and
	password
Message-ID: <1315384864.35.0.23347114707.issue12925@psf.upfronthosting.co.za>


New submission from Sergei Stolyarov :

python setup.py upload_docs doesn't ask for login and password instead it prints 

Upload failed (401): You must be identified to edit package information

Works only with valid ~/.pypirc

----------
assignee: tarek
components: Distutils
messages: 143666
nosy: cancel, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: python setup.py upload_docs doesn't ask for login and password
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 12:04:11 2011
From: report at bugs.python.org (Fabio Erculiani)
Date: Wed, 07 Sep 2011 10:04:11 +0000
Subject: [issue12926] tarfile tarinfo.extract*() broken with symlinks
Message-ID: <1315389851.08.0.471880114138.issue12926@psf.upfronthosting.co.za>


New submission from Fabio Erculiani :

TarFile.makelink() is plain broken.
Test file: http://git.sabayon.org/entropy.git/tree/libraries/tests/packages/amarok-2.2.2.90.tbz2

_extract_member calls makelink which does os.symlink() and then falls to the else branch and calls back _extract_member(), which calls makelink() which calls os.symlink() and causes errno 17.

ERROR: test_db_insert_compare_match_mime (__main__.EntropyRepositoryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "db.py", line 490, in test_db_insert_compare_match_mime
    data = self.Spm.extract_package_metadata(test_pkg)
  File "../entropy/spm/plugins/interfaces/portage_plugin/__init__.py", line 1038, in extract_package_metadata
    extract_path = pkg_dir, catch_empty = False)
  File "../entropy/tools.py", line 2088, in uncompress_tarball
    tar.extract(tarinfo, encoded_path)
  File "/usr/lib64/python3.2/tarfile.py", line 2174, in extract
    set_attrs=set_attrs)
  File "/usr/lib64/python3.2/tarfile.py", line 2258, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "/usr/lib64/python3.2/tarfile.py", line 2358, in makelink
    targetpath)
  File "/usr/lib64/python3.2/tarfile.py", line 2258, in _extract_member
    self.makelink(tarinfo, targetpath)
  File "/usr/lib64/python3.2/tarfile.py", line 2341, in makelink
    os.symlink(tarinfo.linkname, targetpath)
OSError: [Errno 17] File exists

----------
components: Library (Lib)
messages: 143667
nosy: Fabio.Erculiani
priority: normal
severity: normal
status: open
title: tarfile tarinfo.extract*() broken with symlinks
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 13:25:28 2011
From: report at bugs.python.org (Thomas Wouters)
Date: Wed, 07 Sep 2011 11:25:28 +0000
Subject: [issue12919] Control what module is imported first
In-Reply-To: <1315331616.23.0.265275073086.issue12919@psf.upfronthosting.co.za>
Message-ID: <1315394728.14.0.575383102134.issue12919@psf.upfronthosting.co.za>


Thomas Wouters  added the comment:

Here's the patch implementing this, which I'd attached to Issue11561 (although I noticed 'hg diff' omitted the empty stdlib_landmark.py file.)

----------
keywords: +patch
nosy: +twouters
Added file: http://bugs.python.org/file23113/stdlib_landmark.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 14:23:31 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Sep 2011 12:23:31 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1315375670.55.0.393326328767.issue12911@psf.upfronthosting.co.za>
Message-ID: <1315398048.3535.4.camel@localhost.localdomain>


Antoine Pitrou  added the comment:

> I'm -1 on this approach; I don't think yet another container type is
> the right solution, given that we have already plenty of them.

It's not a container type, just a small C struct that gets allocated on
the stack. Think of it as a library, like stringlib.

> If you want to avoid creating large lists, then the StringIO type
> should already provide that. So I wonder why these functions couldn't
> be rewritten to use StringIO.

That's another possibility. But we'd have to expose a C API anyway, and
this one is as good as any other.

Note that StringIO will copy data twice (once when calling write(), once
when calling getvalue()), while ''.join() only once (at the end, when
concatenating all strings).

> If you really want to use this approach, I'd try to avoid allocating
> the large list if there are only few substrings. I.e. allocate it only
> when flushing, and only if the flush is not the final flush.

That's possible, indeed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 14:45:15 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Sep 2011 12:45:15 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
Message-ID: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>


New submission from Stefan Krah :

stefan at opensolaris:~/hg/cpython$ ./python -m test -uall -v test_ctypes
== CPython 3.3.0a0 (default:5c8b6e03ebfe, Sep 7 2011, 13:41:08) [C]
==   Solaris-2.11-i86pc-i386-32bit little-endian
==   /export/home/stefan/hg/cpython/build/test_python_28849
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_ctypes
test_cast (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_memmove (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_memset (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_string_at (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_wstring_at (ctypes.test.test_memfunctions.MemFunctionsTest) ... ok
test_chararray (ctypes.test.test_delattr.TestCase) ... ok
test_simple (ctypes.test.test_delattr.TestCase) ... ok
test_struct (ctypes.test.test_delattr.TestCase) ... ok
test_struct_by_value (ctypes.test.test_win32.Structures) ... ok
test_buffers (ctypes.test.test_unicode.StringTestCase) ... ok
test_func (ctypes.test.test_unicode.StringTestCase) ... ok
test_wcslen (ctypes.test.test_unicode.StringTestCase) ... ok
test_buffers (ctypes.test.test_unicode.UnicodeTestCase) ... ok
test_wcslen (ctypes.test.test_unicode.UnicodeTestCase) ... ok
test_compare (ctypes.test.test_simplesubclasses.Test) ... ok
test_ignore_retval (ctypes.test.test_simplesubclasses.Test) ... Fatal Python error: Segmentation fault

Current thread 0x00000001:
  File "/export/home/stefan/hg/cpython/Lib/ctypes/test/test_simplesubclasses.py", line 24 in test_ignore_retval
  File "/export/home/stefan/hg/cpython/Lib/unittest/case.py", line 386 in _executeTestPart
  File "/export/home/stefan/hg/cpython/Lib/unittest/case.py", line 441 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/case.py", line 493 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 105 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 105 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 105 in run
  File "/export/home/stefan/hg/cpython/Lib/unittest/suite.py", line 67 in __call__
  File "/export/home/stefan/hg/cpython/Lib/unittest/runner.py", line 168 in run
  File "/export/home/stefan/hg/cpython/Lib/test/support.py", line 1293 in _run_suite
  File "/export/home/stefan/hg/cpython/Lib/test/support.py", line 1327 in run_unittest
  File "/export/home/stefan/hg/cpython/Lib/test/test_ctypes.py", line 13 in test_main
  File "/export/home/stefan/hg/cpython/Lib/test/regrtest.py", line 1140 in runtest_inner
  File "/export/home/stefan/hg/cpython/Lib/test/regrtest.py", line 916 in runtest
  File "/export/home/stefan/hg/cpython/Lib/test/regrtest.py", line 708 in main
  File "/export/home/stefan/hg/cpython/Lib/test/__main__.py", line 13 in 
  File "/export/home/stefan/hg/cpython/Lib/runpy.py", line 73 in _run_code
  File "/export/home/stefan/hg/cpython/Lib/runpy.py", line 160 in _run_module_as_main
Segmentation Fault (core dumped)

----------
components: ctypes
messages: 143670
nosy: skrah
priority: normal
severity: normal
status: open
title: test_ctypes: segfault with suncc
type: crash
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 14:51:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2011 12:51:21 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>
Message-ID: <1315399881.02.0.505697018418.issue12927@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

Code of the test:

    from ctypes import *
    def test_ignore_retval(self):
        # Test if the return value of a callback is ignored
        # if restype is None
        proto = CFUNCTYPE(None)
        def func():
            return (1, "abc", None)
        cb = proto(func)
        self.assertEqual(None, cb())

The crash occurs on self.assertEqual(None, cb()). I suppose that it occurs on cb().

Is CFUNCTYPE correct? Or should it be PYFUNCTYPE?

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 15:16:26 2011
From: report at bugs.python.org (simon)
Date: Wed, 07 Sep 2011 13:16:26 +0000
Subject: [issue12928] exec not woking in unittest
Message-ID: <1315401386.62.0.247993467146.issue12928@psf.upfronthosting.co.za>


New submission from simon :

works in 2.6, fails in 3.2.2

import unittest
class MyTest(unittest.TestCase):
    def test_a(self):
        exec(compile("a = 1", '', 'single'))
        assert a == 1
if __name__ == '__main__':
    unittest.main()

----------
components: Library (Lib)
messages: 143672
nosy: simonsteiner
priority: normal
severity: normal
status: open
title: exec not woking in unittest
type: compile error
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 15:22:02 2011
From: report at bugs.python.org (simon)
Date: Wed, 07 Sep 2011 13:22:02 +0000
Subject: [issue12928] exec not woking in unittest
In-Reply-To: <1315401386.62.0.247993467146.issue12928@psf.upfronthosting.co.za>
Message-ID: <1315401722.11.0.0679495413851.issue12928@psf.upfronthosting.co.za>


simon  added the comment:

seems i need to use

exec(compile("a = 1", '', 'single'), globals())

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 15:39:54 2011
From: report at bugs.python.org (simon)
Date: Wed, 07 Sep 2011 13:39:54 +0000
Subject: [issue12928] exec not woking in unittest
In-Reply-To: <1315401386.62.0.247993467146.issue12928@psf.upfronthosting.co.za>
Message-ID: <1315402794.53.0.380470470235.issue12928@psf.upfronthosting.co.za>


simon  added the comment:

Can't get this one working:

import unittest
class MyTest(unittest.TestCase):
    def test_a(self):
        b = 1
        exec(compile("a = b + 1", '', 'single'))
        assert a == 2
if __name__ == '__main__':
    unittest.main()

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:01:16 2011
From: report at bugs.python.org (Pierre Quentel)
Date: Wed, 07 Sep 2011 14:01:16 +0000
Subject: [issue12922] StringIO and seek()
In-Reply-To: <1315342130.67.0.227650351498.issue12922@psf.upfronthosting.co.za>
Message-ID: <1315404076.36.0.326771910947.issue12922@psf.upfronthosting.co.za>


Changes by Pierre Quentel :


----------
nosy: +quentel

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:09:21 2011
From: report at bugs.python.org (Jeremy Kloth)
Date: Wed, 07 Sep 2011 14:09:21 +0000
Subject: [issue12895] In MSI/EXE installer,
	allow installing Python modules in free path
In-Reply-To: <1315185843.85.0.324851460345.issue12895@psf.upfronthosting.co.za>
Message-ID: <1315404561.1.0.384452778552.issue12895@psf.upfronthosting.co.za>


Changes by Jeremy Kloth :


----------
nosy: +jkloth

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:10:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Sep 2011 14:10:46 +0000
Subject: [issue12929] faulthandler: void pointer used in arithmetic
Message-ID: <1315404646.94.0.313585190069.issue12929@psf.upfronthosting.co.za>


New submission from Stefan Krah :

Hi, suncc detected pointer arithmetic with a pointer to void:

"./Modules/faulthandler.c", line 910: warning: pointer to void or function used in arithmetic
"./Modules/faulthandler.c", line 911: warning: pointer to void or function used in arithmetic
"./Modules/faulthandler.c", line 914: warning: pointer to void or function used in arithmetic
"./Modules/faulthandler.c", line 916: warning: pointer to void or function used in arithmetic

----------
components: Extension Modules
messages: 143675
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: faulthandler: void pointer used in arithmetic
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:15:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Sep 2011 14:15:38 +0000
Subject: [issue12912] xmlrpclib.__version__ not bumped with updates
In-Reply-To: <1315316505.08.0.403062949645.issue12912@psf.upfronthosting.co.za>
Message-ID: <1315404938.93.0.593039044566.issue12912@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> Unfortunately that update changed the interface of
> Transport.make_connection(), breaking any code that overrode or
> extended it.

That?s a bad thing.  Can you open a bug report about that?  We need at least a documentation update.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:19:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Sep 2011 14:19:09 +0000
Subject: [issue12929] faulthandler: void pointer used in arithmetic
In-Reply-To: <1315404646.94.0.313585190069.issue12929@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset e91ad9669c08 by Victor Stinner in branch 'default':
Issue #12929: faulthandler now uses char* for arithmetic on pointers
http://hg.python.org/cpython/rev/e91ad9669c08

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:25:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2011 14:25:18 +0000
Subject: [issue12929] faulthandler: void pointer used in arithmetic
In-Reply-To: <1315404646.94.0.313585190069.issue12929@psf.upfronthosting.co.za>
Message-ID: <1315405518.23.0.444893401811.issue12929@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

Does my commit fixed the warning?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:29:37 2011
From: report at bugs.python.org (Dima Tisnek)
Date: Wed, 07 Sep 2011 14:29:37 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
Message-ID: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>


New submission from Dima Tisnek :

Given this as input:
#!/usr/bin/python
def x():
  s = """line one
line two
line three"""
  return s

reindent.py changes it to:
#!/usr/bin/python
def x():
    s = """line one
  line two
  line three"""
    return s


Which means that I cannot use reindent.py on any source that includes multiline literals that are not docs.

Btw, it is generally weird that reindented file ends up with 2 spaces before "line two".

----------
components: Demos and Tools
messages: 143679
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: reindent.py inserts spaces in multiline literals
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:30:07 2011
From: report at bugs.python.org (Wolfgang Schnerring)
Date: Wed, 07 Sep 2011 14:30:07 +0000
Subject: [issue12931] xmlrpclib confuses unicode and string
Message-ID: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>


New submission from Wolfgang Schnerring :

This is a similar issue to http://bugs.python.org/issue7093, but more insiduous:

This works:

xmlrpclib.ServerProxy(u'http://localhost:8080').foo(dict(baz=u'b?r'))

While this fails with a UnicodeDecodeError (note the trailing slash in the URI):

xmlrpclib.ServerProxy(u'http://localhost:8080/').foo(dict(baz=u'b?r'))

  File "/usr/local/python2.7/lib/python2.7/httplib.py", line 937, in endheaders
    self._send_output(message_body)
  File "/usr/local/python2.7/lib/python2.7/httplib.py", line 795, in _send_output
    msg += message_body
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 139: ordinal not in range(128)


So, somewhere in xmlrpclib, confusion happens, since even though the URI is passed in as unicode both times, it is stored as string in the first case (thus compatible with the serialized, utf-8 encoded string of the message body), but in the second case it remains unicode (thus failing, as #7093 tells, which I personally wouldn't have closed wontfix).

----------
components: Library (Lib)
messages: 143680
nosy: wosc
priority: normal
severity: normal
status: open
title: xmlrpclib confuses unicode and string
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:34:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Sep 2011 14:34:22 +0000
Subject: [issue12870] Regex object should have introspection methods
In-Reply-To: <1314811774.34.0.509713448629.issue12870@psf.upfronthosting.co.za>
Message-ID: <1315406062.05.0.595295301705.issue12870@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Limiting the number of calls to re.match sounds like an optimization to me, and I still think that the methods you proposed are too specific.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:36:49 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2011 14:36:49 +0000
Subject: [issue12931] xmlrpclib confuses unicode and string
In-Reply-To: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>
Message-ID: <1315406209.66.0.661174524075.issue12931@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> (thus failing, as #7093 tells, which I personally wouldn't have
> closed wontfix).

I don't know the right encoding to encode a HTTP header. In Python 3, http.client.HTTPConnection.putheader() encodes header name to ASCII and header values to ISO-8859-1.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:39:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2011 14:39:09 +0000
Subject: [issue12931] xmlrpclib confuses unicode and string
In-Reply-To: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>
Message-ID: <1315406349.99.0.33636160138.issue12931@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

New patch using ISO-8859-1 instead of the default encoding (ASCII).

----------
keywords: +patch
Added file: http://bugs.python.org/file23114/xmlrpclib_unicode_host-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:39:36 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Sep 2011 14:39:36 +0000
Subject: [issue12929] faulthandler: void pointer used in arithmetic
In-Reply-To: <1315404646.94.0.313585190069.issue12929@psf.upfronthosting.co.za>
Message-ID: <1315406376.51.0.857968416813.issue12929@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Yes, the warning is gone.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:39:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2011 14:39:54 +0000
Subject: [issue12929] faulthandler: void pointer used in arithmetic
In-Reply-To: <1315404646.94.0.313585190069.issue12929@psf.upfronthosting.co.za>
Message-ID: <1315406394.08.0.324247611744.issue12929@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

Ok, thanks for the report.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:42:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Sep 2011 14:42:38 +0000
Subject: [issue12870] Regex object should have introspection methods
In-Reply-To: <1314811774.34.0.509713448629.issue12870@psf.upfronthosting.co.za>
Message-ID: <1315406558.93.0.694623209859.issue12870@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I tend to agree with Ezio.  Matt, maybe you could ask for other opinions on python-ideas?

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:46:49 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Sep 2011 14:46:49 +0000
Subject: [issue12922] StringIO and seek()
In-Reply-To: <1315342130.67.0.227650351498.issue12922@psf.upfronthosting.co.za>
Message-ID: <1315406809.47.0.0219078072594.issue12922@psf.upfronthosting.co.za>


Changes by Antoine Pitrou :


----------
components: +IO
stage: test needed -> needs patch
type: behavior -> feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 16:57:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Sep 2011 14:57:27 +0000
Subject: [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1315407447.99.0.204643448094.issue12779@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

1) sounds good;
2) would be fine too if it makes your life easier;
3) doesn't seem too useful.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 17:15:00 2011
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Wed, 07 Sep 2011 15:15:00 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1315408500.85.0.905932880991.issue1492704@psf.upfronthosting.co.za>


Gennadiy Zlobin  added the comment:

Thanks for the comments! Here'a a new patch.

----------
Added file: http://bugs.python.org/file23115/new_patch.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 17:22:30 2011
From: report at bugs.python.org (Matt Chaput)
Date: Wed, 07 Sep 2011 15:22:30 +0000
Subject: [issue12870] Regex object should have introspection methods
In-Reply-To: <1314811774.34.0.509713448629.issue12870@psf.upfronthosting.co.za>
Message-ID: <1315408950.19.0.539808743364.issue12870@psf.upfronthosting.co.za>


Matt Chaput  added the comment:

Yes, it's an optimization of my code, not the regex, as I said. Believe me, it's not premature. I've listed two general use cases for the two methods. To me it seems obvious that having to test a large number of regexes against a string, and having to test a single regex against a large number of strings, are two very common programming tasks, and they could both be speeded up quite a bit using these methods.

As of now my parsing code and other code such as PyParsing are resorting to hacks like requiring the user to manually specify the possible first chars of a regex at configuration. With the hacks, the code can be hundreds of times faster. But the hacks are error-prone and should be unnecessary. 

The PCRE library implements at least the "first char" functionality, and a lot more regex introspection that would be useful, through its pcre_fullinfo() function.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 17:26:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Sep 2011 15:26:29 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1315409189.9.0.727964976101.issue1492704@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Thanks, looks good.  There are a few minor cosmetic things I?ll change before committing.  I assume you have tested it on Windows?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 17:30:39 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 07 Sep 2011 15:30:39 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>
Message-ID: <1315409439.87.0.119493361746.issue12927@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

The segfault occurs both with CFUNCTYPE and PYFUNCTYPE in
ffi_prep_incoming_args_SYSV(). I'm not very familiar with
either suncc or the dbx debugger, and I can't get dbx to
step into that function (compiled with -g, libffi is not
stripped as far as I can see). Anyway, here's what I got:

(dbx) stop at ffi.c:403 
(2) stop at "ffi.c":403
(dbx) run
Running: python 
(process id 29932)
Python 3.3.0a0 (default:5c8b6e03ebfe+, Sep  7 2011, 15:48:46) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
Reading _struct.so
Reading libscf.so.1
Reading libuutil.so.1
Reading libgen.so.1
Reading libmd.so.1
Reading libmp.so.2
>>> proto = CFUNCTYPE(None)
>>> def func():
        return (1, "abc", None)
...
>>> cb = proto(func)
>>> cb()
stopped in ffi_closure_SYSV_inner at line 403 in file "ffi.c"
  403     ffi_prep_incoming_args_SYSV(args, respp, arg_area, cif);
(dbx) step
signal SEGV (no mapping at the fault address) in ffi_closure_SYSV_inner at line 403 in file "ffi.c"
  403     ffi_prep_incoming_args_SYSV(args, respp, arg_area, cif);

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 17:53:15 2011
From: report at bugs.python.org (Jeremy Kloth)
Date: Wed, 07 Sep 2011 15:53:15 +0000
Subject: [issue11805] package_data only allows one glob per-package
In-Reply-To: <1302301429.27.0.797210396018.issue11805@psf.upfronthosting.co.za>
Message-ID: <1315410795.31.0.449494376707.issue11805@psf.upfronthosting.co.za>


Changes by Jeremy Kloth :


----------
nosy: +jkloth

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 18:01:36 2011
From: report at bugs.python.org (Kevin Smith)
Date: Wed, 07 Sep 2011 16:01:36 +0000
Subject: [issue12932] dircmp does not allow non-shallow comparisons
Message-ID: <1315411296.33.0.213336425163.issue12932@psf.upfronthosting.co.za>


New submission from Kevin Smith :

While filecmp.cmp and filecmp.cmpfiles allow a shallow option to be specified to invoke a more involved comparison of files, filecmp.dircmp does not.  It is limited to shallow-only comparisons.  

This could be solved quite easily by adding a shallow keyword option to dircmp then changing the phase3 method to the following.

    def phase3(self): # Find out differences between common files
        xx = cmpfiles(self.left, self.right, self.common_files, self.shallow)
        self.same_files, self.diff_files, self.funny_files = xx

----------
components: Library (Lib)
messages: 143692
nosy: kesmit
priority: normal
severity: normal
status: open
title: dircmp does not allow non-shallow comparisons
type: feature request
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 18:01:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Sep 2011 16:01:37 +0000
Subject: [issue12925] python setup.py upload_docs doesn't ask for login and
	password
In-Reply-To: <1315384864.35.0.23347114707.issue12925@psf.upfronthosting.co.za>
Message-ID: <1315411297.56.0.602926691619.issue12925@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

There is no upload_docs command in distutils, I think you have found a setuptools bug.  You should report it to these bug trackers:

- http://bugs.python.org/setuptools/
- https://bitbucket.org/tarek/distribute/issues

(there is a fork, that?s why there are two bug trackers)

In Python 3.3 however, the packaging module (a.k.a. distutils2) does have an upload_docs command; we should add a test to make sure the bug you report doesn?t show up there.

----------
components: +Distutils2 -Distutils
nosy: +alexis
stage:  -> test needed
versions: +3rd party, Python 3.3 -Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 18:06:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Sep 2011 16:06:54 +0000
Subject: [issue12933] Update or remove claims that distutils requires external
	programs
Message-ID: <1315411614.16.0.0292960363033.issue12933@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

In the past, distutils could use either the zipfile/tarfile modules or the external programs tar, zip and friends.  This is told in the documentation and checked in the tests.

I suspect that the docs and tests are now outdated.  For example, some tests will be skipped if the tar program is not found, even if the code would have used the tarfile module and run successfully.  I?ll look into this for packaging, but I don?t have the time right now to go over the distutils test and docs for 2.7 and 3.2.

----------
assignee: eric.araujo
components: Distutils, Documentation, Tests
keywords: easy
messages: 143694
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Update or remove claims that distutils requires external programs
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 18:12:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 07 Sep 2011 16:12:48 +0000
Subject: =?utf-8?q?=5Bissue12934=5D_pysetup_doesn=E2=80=99t_work_for_the_docutils_?=
	=?utf-8?q?project?=
Message-ID: <1315411968.07.0.253348749085.issue12934@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

I tried to run ?pysetup metadata? in a docutils source directory but the program failed, because packaging tries to import docutils and it picks up the 2.x version in the local directory.

The import chain is: pysetup ? packaging.run ? packaging.metadata ? docutils

I could edit sys.path in pysetup, but that would mean that people calling ?python3.y -m packaging.run? would not get the fix.  Another idea would be to catch both ImportError and SyntaxError when packaging.metadata tries to import docutils, but it would be better to find the 3.x version of docutils in site-packages if it exists.

What do you import experts think?

----------
assignee: tarek
components: Distutils2
messages: 143695
nosy: alexis, brett.cannon, eric.araujo, ncoghlan, tarek
priority: normal
severity: normal
status: open
title: pysetup doesn?t work for the docutils project
versions: 3rd party, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 18:32:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 07 Sep 2011 16:32:35 +0000
Subject: [issue12870] Regex object should have introspection methods
In-Reply-To: <1314811774.34.0.509713448629.issue12870@psf.upfronthosting.co.za>
Message-ID: <1315413155.46.0.917927828974.issue12870@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

If there is a generic introspection method like the pcre_fullinfo you mentioned, and if it's also useful and used with other languages/libraries, then it might be considered.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 19:49:26 2011
From: report at bugs.python.org (Wolfgang Schnerring)
Date: Wed, 07 Sep 2011 17:49:26 +0000
Subject: [issue12931] xmlrpclib confuses unicode and string
In-Reply-To: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>
Message-ID: <1315417766.95.0.105028151732.issue12931@psf.upfronthosting.co.za>


Wolfgang Schnerring  added the comment:

I guess it should use the configured encoding[1] (which is utf-8 by default) to do that, shouldn't it? Since that's the encoding that is used for the message body, too.


[1] http://docs.python.org/library/xmlrpclib.html#xmlrpclib.ServerProxy

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 19:52:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2011 17:52:22 +0000
Subject: [issue12931] xmlrpclib confuses unicode and string
In-Reply-To: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>
Message-ID: <1315417942.79.0.842466978297.issue12931@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

"I guess it should use the configured encoding[1] (which is utf-8 by default) to do that, shouldn't it? Since that's the encoding that is used for the message body, too."

The URI is only used in HTTP headers, not in the body.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 20:34:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 07 Sep 2011 18:34:10 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315345576.61.0.523842116768.issue12905@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

> Using SA_RESTART, read() is not interrupted. But if the program is linked to pthread, read() is always interrupted: with sa_flags=0 or sa_flags=SA_RESTART.
>

Ouch...

>> But OpenBSD's pthread implementation has severe limitations/bugs.
>
> rthread doc contains:
>
> "Future work:
>
> Quite simply, signal handling is one the most complicated aspects of threads to get right. (...)"
>

This paper dates back to 2005, I was hoping they would have solved
this by now...

As for the original problem, IIUC you don't reproduce it with your C
test code...
It might be due to a subtle difference in the way Python is built
(like POSIX_SOURCE...), but it's hard to tell...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 21:06:33 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 07 Sep 2011 19:06:33 +0000
Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1315422393.63.0.657640838519.issue12852@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> this is the result of gcc -E on Modules/posixmodule.o, asked by haypo.

And this confirms that __POSIX_VISIBLE < 200809 when  is included, hence the missing prototype.

> I suppose that there is a conflict between Python's _POSIX_C_SOURCE and 
> other defines related to the POSIX level.

Lookie here:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/cdefs.h?rev=1.31
"""
#ifdef _XOPEN_SOURCE
# if (_XOPEN_SOURCE - 0 >= 700)
#  define __XPG_VISIBLE         700
#  undef _POSIX_C_SOURCE
#  define _POSIX_C_SOURCE       200809L
# elif (_XOPEN_SOURCE - 0 >= 600)
#  define __XPG_VISIBLE         600
#  undef _POSIX_C_SOURCE
#  define _POSIX_C_SOURCE       200112L
"""

configure.in defines _XOPEN_SOURCE to 600:
if test $define_xopen_source = yes
then
  AC_DEFINE(_XOPEN_SOURCE, 600,
            Define to the level of X/Open that your system supports)


So, try with _POSIX_C_SOURCE set to 200809L and _XOPEN_SOURCE to 700 (see http://pubs.opengroup.org/onlinepubs/9699919799/), and it should work.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 21:19:41 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 07 Sep 2011 19:19:41 +0000
Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions
In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za>
Message-ID: <1315423181.61.0.861271194069.issue12909@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Looks good to me.

I'd prefer 'test_long_as_size' to be called 'test_long_as_size_t' (even though that's inaccurate for the ssize_t bits :-).

The 'Py_None' reference counting in test_long_as_size and test_long_as_double looked a little odd at first glance---particularly the lack of a Py_INCREF just before the return Py_None.  I see that it works; it just caught my eye.

Anyway, those are just nitpicks;  I leave it to you whether you want to change anything.  Otherwise, please go ahead and apply.  Thanks for the patches!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 21:26:46 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Wed, 07 Sep 2011 19:26:46 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1315009683.69.0.880749172262.issue12729@psf.upfronthosting.co.za>
Message-ID: <24315.1315423582@chthon>


Tom Christiansen  added the comment:

Ezio Melotti  wrote
   on Sat, 03 Sep 2011 00:28:03 -0000: 

> Ezio Melotti  added the comment:

> Or they are still called UTF-8 but used in combination with different error
> handlers, like surrogateescape and surrogatepass.  The "plain" UTF-* codecs
> should produce data that can be used for "open interchange", rejecting all the
> invalid data, both during encoding and decoding.

> Chapter 03, D79 also says:

>        To ensure that the mapping for a Unicode encoding form is one-to-one,
>        all Unicode scalar values, including those corresponding to
>        noncharacter code points and unassigned code points, must be mapped to
>        unique code unit sequences. Note that this requirement does not extend
>        to high-surrogate and low-surrogate code points, which are excluded by
>        definition from the set of Unicode scalar values.

> and this seems to imply that the only unencodable codepoint are the non-scalar
> values, i.e. surrogates and codepoints >U+10FFFF.  Noncharacters shouldn't
> thus receive any special treatment (at least during encoding).

> Tom, do you agree with this?  What does Perl do with them?

I agree that one needs to be able to encode any scalar value and
store it in memory in a designated character encoding form.

This is different from streams, though.

The 3 different Unicode "character encoding *forms*" -- UTF-8,
UTF-16, and UTF-32 -- certainly need to support all possible
scalar values.  These are the forms used to store code points in
memory.  They do not have BOMs, because one knows one's memory
layout.   These are specifically allowed to contain the
noncharacters:

    http://www.unicode.org/reports/tr17/#CharacterEncodingForm

    The third type is peculiar to the Unicode Standard: the noncharacter.
    This is a kind of internal-use user-defined character, not intended for
    public interchange.

The problem is that one must make a clean distinction between character
encoding *forms* and character encoding *schemes*.

    http://www.unicode.org/reports/tr17/#CharacterEncodingScheme

    It is important not to confuse a Character Encoding Form (CEF) and a CES.

    1. The CEF maps code points to code units, while the CES transforms
       sequences of code units to byte sequences.
    2. The CES must take into account the byte-order serialization of
       all code units wider than a byte that are used in the CEF.
    3. Otherwise identical CESs may differ in other aspects, such as the
       number of user-defined characters allowed.

    Some of the Unicode encoding schemes have the same labels as the three
    Unicode encoding forms. [...]

    As encoding schemes, UTF-16 and UTF-32 refer to serialized bytes, for
    example the serialized bytes for streaming data or in files; they may have
    either byte orientation, and a single BOM may be present at the start of the
    data. When the usage of the abbreviated designators UTF-16 or UTF-32 might
    be misinterpreted, and where a distinction between their use as referring to
    Unicode encoding forms or to Unicode encoding schemes is important, the full
    terms should be used. For example, use UTF-16 encoding form or UTF-16
    encoding scheme. They may also be abbreviated to UTF-16 CEF or UTF-16 CES,
    respectively.

    The Unicode Standard has seven character encoding schemes: UTF-8, UTF-16,
    UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, and UTF-32LE.

	* UTF-8, UTF-16BE, UTF-16LE, UTF-32BE and UTF32-LE are simple CESs.

        * UTF-16 and UTF-32 are compound CESs, consisting of an single, optional
          byte order mark at the start of the data followed by a simple CES.

I believe that what this comes down to is that you can have noncharacters in memory
as a CEF, but that you cannot have them in a CES meant for open interchange.
And what you do privately is a different, third matter.

What Perl does differs somewhat depending on whether you are just playing
around with encodings in memory verus using streams that have particular
encodings associated with them.  I belive that you can think of this as the
first being for CEF stuff and the second is for CES stuff.

Streams are strict.  Memory isn't.

Perl will never ever produce nor accept one of the 66 noncharacers on any
stream marked as one of the 7 character encoding schemes.  However, we
aren't always good about whether we generate an exception or whether we
return replacement characters.  

Here the first process created a (for the nonce, nonfatal) warning, 
whereas the second process raised an exception:

     %   perl -wle 'binmode(STDOUT, "encoding(UTF-16)")|| die; print chr(0xFDD0)' | 
	 perl -wle 'binmode(STDIN, "encoding(UTF-16)")||die; print ord '
    Unicode non-character U+FDD0 is illegal for open interchange at -e line 1.
    UTF-16:Unicode character fdd0 is illegal at -e line 1.
    Exit 255

Here the first again makes a warning, and the second returns a replacement
string because:

    % perl -wle 'binmode(STDOUT, "encoding(UTF-8)")|| die; print chr(0xFDD0)' | 
	perl -wle 'binmode(STDIN, "encoding(UTF-8)")||die; print ord '
    Unicode non-character U+FDD0 is illegal for open interchange at -e line 1.
    "\x{fdd0}" does not map to utf8.
    92

If you call encode() manually, you have a lot clearer control over this, 
beause you can specify what to do with invalid characters (exceptions,
replacements, etc).

We have a flavor of non-strict utf8, spelled "utf8" instead of "UTF-8", that
can produce and accept illegal characters, although by default it is still
going to generate a warning:

    %   perl -wle 'binmode(STDOUT, "encoding(utf8)")|| die; print chr(0xFDD0)' | 
	perl -wle 'binmode(STDIN, "encoding(utf8)")||die; print ord '
    Unicode non-character U+FDD0 is illegal for open interchange at -e line 1.
    64976

I could talk about ways to control whether it's a warning or an exception
or a replacement string or nothing at all, but suffice to say such
mechanisms do exist.  I just don't know that I agree with the defaults.

I think a big problem here is that the Python culture doesn't use stream
encodings enough.  People are always making their own repeated and tedious
calls to encode and then sending stuff out a byte stream, by which time it
is too late to check.  This is a real problem, because now you cannot be
permissive for the CES but conservative for the CEF.  

In Perl this doesn't in practice happen because in Perl people seldom send
the result of encode() out a byte stream; they send things out character
streams that have proper encodings affiliated with them.  Yes, you can do
it, but then you lose the checks.  That's not a good idea.

Anything that deals with streams should have an encoding argument.  But
often/many? things in Python don't.  For example, subprocess.Popen
doesn't even seem to take an encoding argument.  This makes people do
things by hand too often.  In fact, subprocess.Popen won't even accept
normal (Python 3 Unicode) strings, which is a real pain.  I do think the
culture of calling .encode("utf8") all over the place needs to be
replaced with a more stream-based approach in Python.  I had another
place where this happens too much in Python besides subprocess.Popen but
I can't remember where it is right now.

Perl's internal name for the strict utf stuff is for example "utf-8-strict".
I think you probably want to distingish these, and make the default strict
the way we do with "UTF-8".  We do not ever allow nonstrict UTF-16 or UTF-32,
only sometimes nonstrict UTF-8 if you call it "utf8".

I quote a bit of the perlunicode manpage below which talks about this a bit.

Sorry it's taken me so long to get back to you on this.  I'd be happy to answer
any further questions you might have.

--tom

	PERLUNICODE(1)   Perl Programmers Reference Guide  PERLUNICODE(1)

	   Non-character code points
	       66 code points are set aside in Unicode as "non-character code
	       points".  These all have the Unassigned (Cn) General Category, and
	       they never will be assigned.  These are never supposed to be in
	       legal Unicode input streams, so that code can use them as sentinels
	       that can be mixed in with character data, and they always will be
	       distinguishable from that data.  To keep them out of Perl input
	       streams, strict UTF-8 should be specified, such as by using the
	       layer ":encoding('UTF-8')".  The non-character code points are the
	       32 between U+FDD0 and U+FDEF, and the 34 code points U+FFFE,
	       U+FFFF, U+1FFFE, U+1FFFF, ... U+10FFFE, U+10FFFF.  Some people are
	       under the mistaken impression that these are "illegal", but that is
	       not true.  An application or cooperating set of applications can
	       legally use them at will internally; but these code points are
	       "illegal for open interchange". Therefore, Perl will not accept
	       these from input streams unless lax rules are being used, and will
	       warn (using the warning category "nonchar", which is a sub-category
	       of "utf8") if an attempt is made to output them.

	   Beyond Unicode code points
	       The maximum Unicode code point is U+10FFFF.  But Perl accepts code
	       points up to the maximum permissible unsigned number available on
	       the platform.  However, Perl will not accept these from input
	       streams unless lax rules are being used, and will warn (using the
	       warning category "non_unicode", which is a sub-category of "utf8")
	       if an attempt is made to operate on or output them.  For example,
	       "uc(0x11_0000)" will generate this warning, returning the input
	       parameter as its result, as the upper case of every non-Unicode
	       code point is the code point itself.

	perl v5.14.0                2011-05-07                         26

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 21:41:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Sep 2011 19:41:20 +0000
Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions
In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 4a66a35da3fd by Nadeem Vawda in branch 'default':
Issue #12909: Make PyLong_As* functions consistent in their use of exceptions.
http://hg.python.org/cpython/rev/4a66a35da3fd

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 21:46:30 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 07 Sep 2011 19:46:30 +0000
Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions
In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za>
Message-ID: <1315424790.17.0.424027862479.issue12909@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

> The 'Py_None' reference counting in test_long_as_size and
> test_long_as_double looked a little odd at first glance

Indeed, it is rather roundabout, so I added a comment to avoid confusion.

> Anyway, those are just nitpicks;  I leave it to you whether you want to
> change anything.  Otherwise, please go ahead and apply.  Thanks for the
> patches!

Thanks for the review.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 21:46:51 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 07 Sep 2011 19:46:51 +0000
Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions
In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za>
Message-ID: <1315424811.01.0.88204497218.issue12909@psf.upfronthosting.co.za>


Changes by Nadeem Vawda :


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 22:04:44 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Sep 2011 20:04:44 +0000
Subject: [issue12926] tarfile tarinfo.extract*() broken with symlinks
In-Reply-To: <1315389851.08.0.471880114138.issue12926@psf.upfronthosting.co.za>
Message-ID: <1315425884.06.0.036909103562.issue12926@psf.upfronthosting.co.za>


Changes by Ned Deily :


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 22:30:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Sep 2011 20:30:36 +0000
Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset cf66578d03d1 by Victor Stinner in branch 'default':
Issue #12852: Set _XOPEN_SOURCE to 700 to get POSIX 2008
http://hg.python.org/cpython/rev/cf66578d03d1

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 22:34:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2011 20:34:47 +0000
Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1315427687.98.0.340992838972.issue12852@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> try with _POSIX_C_SOURCE set to 200809L and _XOPEN_SOURCE to 700

_POSIX_C_SOURCE value is set automatically depending on _XOPEN_SOURCE value. I chose to set _XOPEN_SOURCE to 700, instead of 600: it works on OpenBSD 5.0. I don't know if _XOPEN_SOURCE=700 is supported by old platforms.

I don't want to touch such sensitive thing like configure in stable releases.

@rpointel: You can backport manually the fix into OpenBSD for Python 3.2, or (safer?) patch pyconfig.h to set _XOPEN_SOURCE to 700.

According to configure.in, it was not possible to set _XOPEN_SOURCE on OpenBSD < 4.7:

  # On OpenBSD, select(2) is not available if _XOPEN_SOURCE is defined,
  # even though select is a POSIX function. Reported by J. Ribbens.
  # Reconfirmed for OpenBSD 3.3 by Zachary Hamm, for 3.4 by Jason Ish.
  # In addition, Stefan Krah confirms that issue #1244610 exists through
  # OpenBSD 4.6, but is fixed in 4.7.

@rpointel: Does the fix work for you? If yes, I will close the issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 22:58:38 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 07 Sep 2011 20:58:38 +0000
Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1315429118.43.0.517048477944.issue12852@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> _POSIX_C_SOURCE value is set automatically depending on _XOPEN_SOURCE
> value.

I know, but I think it's better to be consistent an also bump _POSIX_C_SOURCE to POSIX 2008, and follow POSIX's recommandation (http://pubs.opengroup.org/onlinepubs/9699919799/):
"""
A Strictly Conforming POSIX Application is an application that requires only the facilities described in POSIX.1-2008. Such an application:
[...]
For the C programming language, shall define _POSIX_C_SOURCE to be 200809L before any header is included
"""

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 23:01:33 2011
From: report at bugs.python.org (Chad Whitacre)
Date: Wed, 07 Sep 2011 21:01:33 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1315429293.73.0.202565676847.issue1669349@psf.upfronthosting.co.za>


Chad Whitacre  added the comment:

I am seeing this behavior with 2.7.1.

----------
nosy: +whit537

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 23:22:58 2011
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 07 Sep 2011 21:22:58 +0000
Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1315430578.3.0.159869796139.issue12852@psf.upfronthosting.co.za>


Remi Pointel  added the comment:

> @rpointel: Does the fix work for you? If yes, I will close the issue.

Hi, yes it sounds good for me:

$ hg pull -u
$ ./configure && make
$ ./python Lib/test/test_posix.py
[...]
test_fdlistdir (__main__.PosixTester) ... ok
[...]
Ran 79 tests in 0.097s
OK (skipped=17)

Thanks.

Remi.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep  7 23:41:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2011 21:41:02 +0000
Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: <1315431662.06.0.78605702393.issue12852@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 00:03:03 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 07 Sep 2011 22:03:03 +0000
Subject: [issue12909] Inconsistent exception usage in PyLong_As* C functions
In-Reply-To: <1315294818.19.0.176172892985.issue12909@psf.upfronthosting.co.za>
Message-ID: <1315432983.03.0.282663796456.issue12909@psf.upfronthosting.co.za>


Raymond Hettinger  added the comment:

+1

----------
assignee: nadeem.vawda -> rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 00:19:51 2011
From: report at bugs.python.org (=?utf-8?q?Francisco_Mart=C3=ADn_Brugu=C3=A9?=)
Date: Wed, 07 Sep 2011 22:19:51 +0000
Subject: [issue12659] Add tests for packaging.tests.support
In-Reply-To: <1312033884.07.0.964621452644.issue12659@psf.upfronthosting.co.za>
Message-ID: <1315433991.69.0.956373766179.issue12659@psf.upfronthosting.co.za>


Francisco Mart?n Brugu?  added the comment:

I've updated the patch. From your review: the class 'Mixin' is still
there as the idea was to imitate the use of 'TempdirManager' as is
used in the rest of the tests and test what it's documentation says.

Just let me know your preferences here.

Thank in advance !

----------
Added file: http://bugs.python.org/file23116/issue12659_v2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 00:56:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Sep 2011 22:56:49 +0000
Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0
In-Reply-To: <1314621008.43.0.624142924193.issue12852@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 92842e347d98 by Victor Stinner in branch 'default':
Issue #12852: Set _POSIX_C_SOURCE to 200809 to get POSIX 2008
http://hg.python.org/cpython/rev/92842e347d98

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 00:57:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Sep 2011 22:57:52 +0000
Subject: [issue12852] POSIX level issues in posixmodule.c on OpenBSD 5.0
In-Reply-To: <1315429118.43.0.517048477944.issue12852@psf.upfronthosting.co.za>
Message-ID: <201109080057.35765.victor.stinner@haypocalc.com>


STINNER Victor  added the comment:

> I know, but I think it's better to be consistent an also bump
> _POSIX_C_SOURCE to POSIX 2008

Oh, I missed AC_DEFINE(_POSIX_C_SOURCE, ...) after AC_DEFINE(_XOPEN_SOURCE, 
...). Fixed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 01:01:07 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Sep 2011 23:01:07 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1315436467.8.0.570951848691.issue6560@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

If Bill gets a chance to investigate this before the weekend, great, otherwise my plan to stop making noise in the buildbot results will be to:

1. Create a separate issue specifically for the errors reported by the Mac OS X buildbots (allowing the problem to be spelled out more clearly for readers, and also allowing the feature request itself to be closed)

2. Flag the offending tests as expected failures on Mac OS X, with a pointer back to the new tracker issue.

That way, if these failures are due to underlying OS bugs or limitations (as they appear to be), we'll get a clear indication in the buildbots when Apple have fixed the relevant problems.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 02:23:31 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Thu, 08 Sep 2011 00:23:31 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1315441411.78.0.511800190323.issue12930@psf.upfronthosting.co.za>


Caio Rom?o  added the comment:

This patch fixes the reported issue.

First time contributor here, feel free to bash.

----------
keywords: +patch
nosy: +caioromao
Added file: http://bugs.python.org/file23117/caioromao-fix-12930.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 02:45:00 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Thu, 08 Sep 2011 00:45:00 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1315442700.23.0.453335730696.issue12930@psf.upfronthosting.co.za>


Changes by Caio Rom?o :


Removed file: http://bugs.python.org/file23117/caioromao-fix-12930.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 02:46:24 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 08 Sep 2011 00:46:24 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>
Message-ID: <1315442785.0.0.800467150653.issue12927@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 03:39:11 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 08 Sep 2011 01:39:11 +0000
Subject: [issue2180] tokenize: mishandles line joining
In-Reply-To: <1203904758.19.0.84784431119.issue2180@psf.upfronthosting.co.za>
Message-ID: <1315445951.89.0.378249045427.issue2180@psf.upfronthosting.co.za>


Meador Inge  added the comment:

That syntax error is coming from the CPython parser and *not* the tokenizer.  Both CPython and the 'tokenizer' modules produce the same tokenization:

[meadori at motherbrain cpython]$ cat repro.py
if 1:
  \

  pass
[meadori at motherbrain cpython]$ ./python tokenize.py repro.py 
0,0-0,0:        ENCODING        'utf-8'
1,0-1,2:        NAME            'if'
1,3-1,4:        NUMBER          '1'
1,4-1,5:        OP              ':'
1,5-1,6:        NEWLINE         '\n'
2,0-2,2:        INDENT          '  '
3,0-3,1:        NEWLINE         '\n'
4,2-4,6:        NAME            'pass'
4,6-4,7:        NEWLINE         '\n'
5,0-5,0:        DEDENT          ''
5,0-5,0:        ENDMARKER       ''
[44319 refs]
[meadori at motherbrain cpython]$ ./python -d repro.py | grep Token | tail -10
  File "repro.py", line 3
    
    ^
SyntaxError: invalid syntax
[44305 refs]
Token NEWLINE/'' ... It's a token we know
Token DEDENT/'' ... It's a token we know
Token NEWLINE/'' ... It's a token we know
Token ENDMARKER/'' ... It's a token we know
Token NAME/'if' ... It's a keyword
Token NUMBER/'1' ... It's a token we know
Token COLON/':' ... It's a token we know
Token NEWLINE/'' ... It's a token we know
Token INDENT/'' ... It's a token we know
Token NEWLINE/'' ... It's a token we know

The NEWLINE INDENT NEWLINE tokenization causes the parser to choke because 'suite' nonterminals:

suite: simple_stmt | NEWLINE INDENT stmt+ DEDENT

are defined as NEWLINE INDENT.

It seems appropriate that the NEWLINE after INDENT should be dropped by both tokenizers.  In other words, I think:
"""
if 1:
  \

  pass
"""

should produce the same tokenization as:

"""
if 1:
  
  pass
"""

This seems consistent with with how explicit line joining is defined [2].


[1] http://hg.python.org/cpython/file/92842e347d98/Grammar/Grammar
[2] http://docs.python.org/reference/lexical_analysis.html#explicit-line-joining

----------
stage: test needed -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 03:47:33 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 08 Sep 2011 01:47:33 +0000
Subject: [issue3353] make built-in tokenizer available via Python C API
In-Reply-To: <1216035196.11.0.15913194841.issue3353@psf.upfronthosting.co.za>
Message-ID: <1315446453.58.0.732866906504.issue3353@psf.upfronthosting.co.za>


Meador Inge  added the comment:

It would be nice if this same C API was used to implement the 'tokenize' module.  Issues like issue2180 will potentially require bug fixes in two places :-/

----------
nosy: +meadori

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 03:57:34 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Thu, 08 Sep 2011 01:57:34 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1315447054.27.0.75974955996.issue12930@psf.upfronthosting.co.za>


Caio Rom?o  added the comment:

New patch, fixing issue pointed out by gutworth and some others that came up.

I've used the following as a test input:

-----8<----------8<--------
#!/usr/bin/python
def x():
  """
  This is a doc
  """
  '''
  Another doc.'''
  s = """line one
line two
      line three
      '''
line five
"""
  var = '''test'''
  """Third doc"""
  return s
-----8<----------8<--------

The patch got way bigger than the initial version and feels a little hackish, but I couldn't come up with something better.

----------
Added file: http://bugs.python.org/file23118/caioromao-fix-12930-v2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 10:04:04 2011
From: report at bugs.python.org (Yoav Weiss)
Date: Thu, 08 Sep 2011 08:04:04 +0000
Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF
Message-ID: <1315469044.33.0.218036955043.issue1159051@psf.upfronthosting.co.za>


Yoav Weiss  added the comment:

What is the reason that the currently submitted patch is not good enough and current stage is "needs patch"?
The current patch seem to solve this issue, which is a very common one when dealing with gzip files coming from the Internet.
In any case, an indication on *why* the current patch is not good enough will help create a better patch that may be good enough.

----------
nosy: +yeeeev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 10:32:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Sep 2011 08:32:45 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1315470765.01.0.974721986343.issue12729@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

So to summarize a bit, there are different possible level of strictness:
  1) all the possible encodable values, including the ones >10FFFF;
  2) values in range 0..10FFFF;
  3) values in range 0..10FFFF except surrogates (aka scalar values);
  4) values in range 0..10FFFF except surrogates and noncharacters;

and this is what is currently available in Python:
  1) not available, probably it will never be;
  2) available through the 'surrogatepass' error handler;
  3) default behavior (i.e. with the 'strict' error handler);
  4) currently not available.

(note: this refers to the utf-8 codec in Python 3, but it should be true for the utf-16/32 codecs too once #12892 is fixed.  This whole message refers to codecs only and what they should (dis)allow.  What we use internally seems to work fine and doesn't need to be changed.)

Now, assume that we don't care about option 1 and want to implement the missing option 4 (which I'm still not 100% sure about).  The possible options are:
  * add a new codec (actually one for each UTF encoding);
  * add a new error handler that explicitly disallows noncharacters;
  * change the meaning of 'strict' to match option 4;

This depends on what should be the default behavior while dealing with noncharacters.  If they are rejected by default, then 'strict' should reject them.  However this would leave us without option 3 (something to encode all and only scalar values), and surrogatepass will be misnamed if it also allows noncharacters (and if it doesn't we will end up without option 2 too).  This is apparently what Perl does:
> Perl will never ever produce nor accept one of the 66 noncharacers
> on any stream marked as one of the 7 character encoding schemes. 


Implementation-wise, I think the 'strict' error handler should be the strictest one, because the codec must detects all the "problematic" chars and send them to the error handler that might then decide what to do with them.  I.e. if the codec detects noncharacters, sends them to the error handler, and the error handler is strict, an error will be raised; if it doesn't detect them, the error handler won't be able to do anything with them.  
Another option is to provide another codec that specifically detects them, but this means re-implementing a slightly different version of each codec (or possibly add an extra argument to the PyUnicode_{Encode,Decode}UTF* functions).

We could also decide to leave the handling of noncharacters as it is -- after all the Unicode standard doesn't seem to explicitly forbid them as it does with e.g. surrogates.


> We have a flavor of non-strict utf8, spelled "utf8" instead of "UTF-8",
> that can produce and accept illegal characters, although by default it
> is still going to generate a warning

How did Perl implement this?  With two (or more) slightly different version of the same codec?
And how does Perl handle errors?  With some global options that turns (possibly specific) warnings into error (like python -We)?

Python has different codecs that encode/decode str/bytes and whenever they find a "problematic" char they send it to the error handler that might decide to raise an error, remove the char, replace it with something else, sending it back unchanged, generate a warning and so on.  In this way you can have different combinations of codecs and error handlers to get the desired behaviors.  (and FWIW in Python 'utf8' is an alias for 'UTF-8'.)

> I think a big problem here is that the Python culture doesn't use stream
> encodings enough.  People are always making their own repeated and tedious
> calls to encode and then sending stuff out a byte stream, by which time it
> is too late to check.
> [...]
> Anything that deals with streams should have an encoding argument.  But
> often/many? things in Python don't.
Several objects have an .encoding and .error attributes (e.g. sys.stdin/out), and they are used to encode/decode the text/bytes sent/read to/from them.  In other places we prefer the "explicit is better than implicit" approach and require the user (or some other higher-level layer) to encode/decode manually.

I'm not sure why you are saying that it's too late to check, and since the encoding/decoding happens only in a few places I don't think it's tedious at all (and often it's automatic too).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 11:24:48 2011
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Thu, 08 Sep 2011 09:24:48 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1315473888.19.0.647001699716.issue4431@psf.upfronthosting.co.za>


S?bastien Sabl?  added the comment:

I encountered the same problem while compiling the psutil package.

I used Python 3.2.2 that I compiled myself using Visual Studio 2010 SP1 in Debug mode by following the PCBuild/readme.txt documentation.

I could not compile psutil until I added in setup.py:
extra_link_args=['/MANIFEST']

I have not tried to compile any other C extension yet, but this is not mysql-python and I am not using setuptools either.

----------
nosy: +sable
versions: +Python 2.6, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 11:32:24 2011
From: report at bugs.python.org (Karsten Wolf)
Date: Thu, 08 Sep 2011 09:32:24 +0000
Subject: [issue12935] Typo in findertools.py
Message-ID: <1315474344.82.0.220434823255.issue12935@psf.upfronthosting.co.za>


New submission from Karsten Wolf :

In the current Python-2.7.2.tar.bz2 archive ./Lib/plat-mac/findertools.py in function comment on line 131 the call to FSNewAliasMinimal is misstyped.

current version:
    object_alias = object.FSNewAliasMonimal()

corrected version

    object_alias = object.FSNewAliasMinimal()

----------
assignee: ronaldoussoren
components: Macintosh
messages: 143722
nosy: karstenw, ronaldoussoren
priority: normal
severity: normal
status: open
title: Typo in findertools.py
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 11:54:47 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 09:54:47 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
Message-ID: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>


New submission from Stefan Krah :

I'm getting random segfaults in `make buildbottest` on qemu-debian-arm:

Linux-2.6.26-2-versatile-armv5tejl-with-debian-5.0.8 little-endian

The segfaults occurred in test_robotparser and test_nntplib and
couldn't be reproduced when running the tests separately.
qemu-debian-arm is horrendously slow, so I don't think I'll have
time to debug this. I'm submitting the report in case someone has
access to fast ARM hardware.


[ 81/359/3] test_nntplib
Fatal Python error: Segmentation fault

Current thread 0x400225f0:
  File "/home/user/cpython-e91ad9669c08/Lib/socket.py", line 389 in create_connection
  File "/home/user/cpython-e91ad9669c08/Lib/nntplib.py", line 1024 in __init__
  File "/home/user/cpython-e91ad9669c08/Lib/test/test_nntplib.py", line 291 in setUpClass
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 143 in _handleClassSetUp
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 97 in run
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 67 in __call__
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 105 in run
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 67 in __call__
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/runner.py", line 168 in run
  File "/home/user/cpython-e91ad9669c08/Lib/test/support.py", line 1293 in _run_suite
  File "/home/user/cpython-e91ad9669c08/Lib/test/support.py", line 1327 in run_unittest
  File "/home/user/cpython-e91ad9669c08/Lib/test/test_nntplib.py", line 1260 in test_main
  File "/home/user/cpython-e91ad9669c08/Lib/test/regrtest.py", line 1140 in runtest_inner
  File "/home/user/cpython-e91ad9669c08/Lib/test/regrtest.py", line 905 in runtest
  File "/home/user/cpython-e91ad9669c08/Lib/test/regrtest.py", line 708 in main
  File "/home/user/cpython-e91ad9669c08/Lib/test/__main__.py", line 13 in 
  File "/home/user/cpython-e91ad9669c08/Lib/runpy.py", line 73 in _run_code
  File "/home/user/cpython-e91ad9669c08/Lib/runpy.py", line 160 in _run_module_as_main
Segmentation fault

----------
components: Extension Modules
messages: 143723
nosy: skrah
priority: normal
severity: normal
stage: test needed
status: open
title: armv5tejl: random segfaults in getaddrinfo()
type: crash
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 11:59:53 2011
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Thu, 08 Sep 2011 09:59:53 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1315475993.08.0.221715459023.issue1492704@psf.upfronthosting.co.za>


Gennadiy Zlobin  added the comment:

My fault. I tested it only partially, relying on the documentation that says

"""
On Windows, if dst already exists, OSError will be raised even if it is a file
"""
Actually it does not (at least at my Windows 7):
(Pdb) os.path.isfile(src)
True
(Pdb) p os.rename(src, src)
None

Am I doing something wrong?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 12:12:30 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Sep 2011 10:12:30 +0000
Subject: [issue12928] exec not woking in unittest
In-Reply-To: <1315401386.62.0.247993467146.issue12928@psf.upfronthosting.co.za>
Message-ID: <1315476750.88.0.582746353195.issue12928@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

This doesn't seem related to unittest:

>>> class MyTest:
...     def test_a(self):
...         b = 1
...         exec(compile("a = b + 1", '', 'single'))
...         assert a == 2
... 
>>> t = MyTest()
>>> t.test_a()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 5, in test_a
NameError: global name 'a' is not defined

With unittest I get the same error.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 12:20:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Sep 2011 10:20:25 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1315477225.85.0.367742161586.issue5845@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 12:20:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Sep 2011 10:20:58 +0000
Subject: [issue12910] urrlib.quote quotes too many chars, e.g., '()'
In-Reply-To: <1315304798.98.0.174203108938.issue12910@psf.upfronthosting.co.za>
Message-ID: <1315477258.01.0.768576956282.issue12910@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 12:21:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Sep 2011 10:21:53 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za>
Message-ID: <1315477313.68.0.125442287122.issue12913@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 12:22:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Sep 2011 10:22:45 +0000
Subject: [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1315477365.46.0.333931818613.issue12902@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 12:25:32 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Sep 2011 10:25:32 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1315477532.77.0.586415578594.issue12915@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 12:26:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Sep 2011 10:26:09 +0000
Subject: [issue12890] cgitb displays 
 tags when executed in text mode
In-Reply-To: <1315016521.13.0.175763253408.issue12890@psf.upfronthosting.co.za>
Message-ID: <1315477569.29.0.39894368778.issue12890@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 15:52:35 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 08 Sep 2011 13:52:35 +0000
Subject: [issue12928] exec not woking in unittest
In-Reply-To: <1315401386.62.0.247993467146.issue12928@psf.upfronthosting.co.za>
Message-ID: <1315489955.06.0.892254880878.issue12928@psf.upfronthosting.co.za>


Benjamin Peterson  added the comment:

You're invoking undefined behavior by modifying function locals in exec().

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 16:47:15 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 14:47:15 +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: <1315493235.16.0.547706260041.issue10181@psf.upfronthosting.co.za>


Changes by Stefan Krah :


Added file: http://bugs.python.org/file23119/51cedae5acfc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 16:53:25 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 14:53:25 +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: <1315493605.01.0.463857732636.issue10181@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Here's a completely restructured memoryview implementation that I believe
is quite robust. Both memoryobject.c (the parts I worked on, which is 91%)
and _testbuffer.c have 100% code coverage, including all error conditions [1].

memoryview is tested against the struct module (via _testbuffer's ndarray),
array.array and bytearray. To deal with the case explosions inherent to the
specification test_buffer.py resorts to brute force in some cases (most
notably in testing getbuffer() flags).

PyMemoryViewObject is now a PyVarObject with private arrays. Unless ndim = 0,
shape and strides are always present after initialization.

Memoryview now has support for all native single-value struct module
specifiers. I abandoned the idea of using the struct module for
packing/unpacking. New benchmarks (See #10227) indicate that _testbuffer's
tolist() is over 1000x slower that the optimized versions of memoryview.

The cast function from #5231 is completely implemented.


Review would be much appreciated. Perhaps it would be possible to
do a mini PEP-3118 sprint? Usually I'm never on IRC, but I could
dust off irssi for the occasion.


These are the main changes in detail:
-------------------------------------

o Restructure memoryobject.c into sections.

o Use struct hack in PyMemoryViewObject for the dynamic arrays.

o Rework initialization.

o Add a couple of invariants: A new memoryview will always have complete
  shape/strides/format information, unless ndim = 0.

o Add buffer flags: A new memoryview will always have flag information
  that determines whether it is a scalar (ndim = 0), C/Fortran contiguous,
  NumPY or PIL style, released or active. This eliminates the need for
  expensive re-computations during a getbuffer() request.

o Add support for all native struct module formats in indexing, assigning
  and tolist().

o Add memoryview.cast(format=x, shape=y), where x is a native format specifier
  and y is any multidimensional shape.

o Add PEP-3118 compliant getbuffer() method.

o Slice assignments now support non-contiguous 1-D slices.

o Comparisons now support non-contiguous 1-D buffers.

o Representation of empty shape etc. is now an empty tuple (O.K.
  with Mark Dickinson and Travis Oliphant).


[1] 100% coverage requires a patch for systematically triggering failures
    of Python API functions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 16:55:21 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 14:55:21 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1315493721.53.0.358356334193.issue10227@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Kristj?n, could you check out the new implementation over at #10181?
I have trouble reproducing a big speed difference between bytearray
and memoryview (Linux, 64-bit). Here are the timings I get for the
current and the new version:


Slicing
-------

1) ./python -m timeit -n 10000000 -s "x = bytearray(b'x'*10000)" "x[:100]"
2) ./python -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[:100]"

1) cpython: 0.137 usec   pep-3118: 0.138 usec
2) cpython: 0.132 usec   pep-3118: 0.132 usec


Slicing with overhead for multidimensional capabilities:
--------------------------------------------------------

1) ./python  -m timeit -n 10000000 -s "import _testbuffer; x = _testbuffer.ndarray([ord('x') for _ in range(10000)], shape=[10000])" "x[:100]"
2) ./python  -m timeit -n 10000000 -s "import numpy; x = numpy.ndarray(buffer=bytearray(b'x'*10000), shape=[10000], dtype='B')" "x[:100]"

1) _testbuffer.c: 0.198 usec
2) numpy:         0.415 usec
Slice assignment
----------------

1) ./python -m timeit -n 10000000 -s "x = bytearray(b'x'*10000)" "x[5:10] = x[7:12]"
2) ./python -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[5:10] = x[7:12]"

1) cpython: 0.242 usec   pep-3118: 0.240 usec
2) cpython: 0.282 usec   pep-3118: 0.287 usec


Slice assignment, overhead for multidimensional capabilities
------------------------------------------------------------

1) ./python -m timeit -n 10000000 -s "import _testbuffer; x = _testbuffer.ndarray([ord('x') for _ in range(10000)], shape=[10000], flags=_testbuffer.ND_WRITABLE)" "x[5:10] = x[7:12]"

2) ./python -m timeit -n 10000000 -s "import numpy; x = numpy.ndarray(buffer=bytearray(b'x'*10000), shape=[10000], dtype='B')" "x[5:10] = x[7:12]"

_testbuffer.c: 0.469 usec
numpy:         1.37 usec


tolist
------

1) ./python -m timeit -n 10000 -s "import array; x = array.array('B', b'x'*10000)" "x.tolist()"
2) ./python -m timeit -n 10000 -s "x = memoryview(bytearray(b'x'*10000))" "x.tolist()"

1) cpython, array:      104.0 usec
2) pep-3118, memoryview: 90.5 usec


tolist, struct module overhead
------------------------------

1) ./python -m timeit -n 10000 -s "import _testbuffer; x = _testbuffer.ndarray([ord('x') for _ in range(10000)], shape=[10000])" "x.tolist()"
2) ./python -m timeit -n 10000 -s "import numpy; x = numpy.ndarray(buffer=bytearray(b'x'*10000), shape=[10000], dtype='B')" "x.tolist()"

_testbuffer.c: 1.38 msec (yes, that's microseconds!)
numpy:         104 usec

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 16:56:21 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 14:56:21 +0000
Subject: [issue5231] Change format of a memoryview
In-Reply-To: <1234474743.76.0.794318305676.issue5231@psf.upfronthosting.co.za>
Message-ID: <1315493781.59.0.808019241861.issue5231@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

The cast method is completely implemented over at #10181.

----------
dependencies: +Problems with Py_buffer management in memoryobject.c (and elsewhere?)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 16:57:25 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 14:57:25 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1315493845.32.0.0184153804096.issue10227@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
dependencies: +Problems with Py_buffer management in memoryobject.c (and elsewhere?)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 17:05:06 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 15:05:06 +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: <1315494306.93.0.188945302869.issue10181@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

> is over 1000x slower that the optimized versions of memoryview.

Oh dear, scratch that. Lets make that 15x. ;)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 17:26:59 2011
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 08 Sep 2011 15:26:59 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1315495619.2.0.839359391749.issue10227@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson  added the comment:

I'm afraid I had put this matter _far_ out of my head :)  Seeing the amount of discussion on that other defect (stuff I had already come across and scrathced my head over) I think there is a lot of catching up that I'd need to do and I am unable to give this any priority at the moment.
My original patch sought to even out the slicing performance difference between bytes and bytearray.  bytes objects were very streamlined while other were not.

python.exe -m timeit -n 10000000 -s "x = ((b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.125 usec per loop

python.exe -m timeit -n 10000000 -s "x = (bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.202 usec per loop

Did you take a look at this at all?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 18:03:32 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 16:03:32 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1315497812.69.0.113001086949.issue10227@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I see. I thought this was mainly about memoryview performance, so
I did not specifically look at bytearray. The poor performance seems
to be Windows specific:

C:\Users\stefan\hg\pep-3118\PCbuild>amd64\python.exe -m timeit -n 10000000 -s "x = ((b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.118 usec per loop

C:\Users\stefan\hg\pep-3118\PCbuild>amd64\python.exe -m timeit -n 10000000 -s "x = (bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.191 usec per loop

C:\Users\stefan\hg\pep-3118\PCbuild>amd64\python.exe -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.146 usec per loop


Linux:

bytes: 10.9 usec   bytearray: 0.14 usec   memoryview: 0.14 usec

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 18:22:03 2011
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 08 Sep 2011 16:22:03 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1315498923.76.0.657687474251.issue12915@psf.upfronthosting.co.za>


Changes by Andreas St?hrk :


----------
nosy: +Trundle

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 18:28:12 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 08 Sep 2011 16:28:12 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1315499292.98.0.547316727845.issue10227@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

With Stefan Behnel's slice-object-cache.patch, I get this (PEP-3118 branch):


Linux:   bytes: 0.097 usec  bytearray:  0.127 usec  memoryview: 0.12  usec
Windows: bytes: 0.11 usec   bytearray:  0,184 usec  memoryview: 0.139 usec


On Linux, that's quite a nice speedup.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 19:06:25 2011
From: report at bugs.python.org (Sebastian Ramacher)
Date: Thu, 08 Sep 2011 17:06:25 +0000
Subject: [issue12844] Support more than 255 arguments
In-Reply-To: <1314326578.49.0.0651529898349.issue12844@psf.upfronthosting.co.za>
Message-ID: <1315501585.58.0.211756704118.issue12844@psf.upfronthosting.co.za>


Changes by Sebastian Ramacher :


----------
nosy: +sebastinas

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 19:49:47 2011
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 08 Sep 2011 17:49:47 +0000
Subject: [issue12937] Support install options as found in distutils
Message-ID: <1315504187.52.0.368275649699.issue12937@psf.upfronthosting.co.za>


New submission from Brett Cannon :

Distutils2/packaging does not support all the flags provided in distutils (e.g., --user, --prefix, etc.). It would be good to provide the same level of install control (or at least support the --user flag).

----------
assignee: tarek
components: Distutils2
messages: 143734
nosy: alexis, brett.cannon, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Support install options as found in distutils
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 20:56:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 08 Sep 2011 18:56:11 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1315470765.01.0.974721986343.issue12729@psf.upfronthosting.co.za>
Message-ID: <4E690F86.60500@udel.edu>


Terry J. Reedy  added the comment:

On 9/8/2011 4:32 AM, Ezio Melotti wrote:
> So to summarize a bit, there are different possible level of strictness:
>    1) all the possible encodable values, including the ones>10FFFF;
>    2) values in range 0..10FFFF;
>    3) values in range 0..10FFFF except surrogates (aka scalar values);
>    4) values in range 0..10FFFF except surrogates and noncharacters;
>
> and this is what is currently available in Python:
>    1) not available, probably it will never be;
>    2) available through the 'surrogatepass' error handler;
>    3) default behavior (i.e. with the 'strict' error handler);
>    4) currently not available.
>
> Now, assume that we don't care about option 1 and want to implement the missing option 4 (which I'm still not 100% sure about).  The possible options are:
>    * add a new codec (actually one for each UTF encoding);
>    * add a new error handler that explicitly disallows noncharacters;
>    * change the meaning of 'strict' to match option 4;

If 'strict' meant option 4, then 'scalarpass' could mean option 3. 
'surrogatepass' would then mean 'pass surragates also, in addition to 
non-char scalers'.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 21:00:48 2011
From: report at bugs.python.org (zvin)
Date: Thu, 08 Sep 2011 19:00:48 +0000
Subject: [issue12938] html.escape does not mention single quotes (')
Message-ID: <1315508448.5.0.992592094222.issue12938@psf.upfronthosting.co.za>


New submission from zvin :

The html.escape docstring says:

"""
Replace special characters "&", "<" and ">" to HTML-safe sequences.
If the optional flag quote is true (the default), the quotation mark
character (") is also translated.
"""

But if you set the optional flag quote to True, this function also escapes single quotes ('). You can see it by comparing _escape_map and _escape_map_full. [http://hg.python.org/cpython/file/cf811943046b/Lib/html/__init__.py]
The docstring needs to be updated.

----------
components: Library (Lib)
messages: 143736
nosy: zvin
priority: normal
severity: normal
status: open
title: html.escape does not mention single quotes (')
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 21:02:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Sep 2011 19:02:42 +0000
Subject: [issue12938] html.escape does not mention single quotes (')
In-Reply-To: <1315508448.5.0.992592094222.issue12938@psf.upfronthosting.co.za>
Message-ID: <1315508562.21.0.650959920528.issue12938@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti, sandro.tosi

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 21:22:48 2011
From: report at bugs.python.org (zvin)
Date: Thu, 08 Sep 2011 19:22:48 +0000
Subject: [issue12938] html.escape docstring does not mention single quotes (')
In-Reply-To: <1315508448.5.0.992592094222.issue12938@psf.upfronthosting.co.za>
Message-ID: <1315509768.78.0.859077778129.issue12938@psf.upfronthosting.co.za>


Changes by zvin :


----------
title: html.escape does not mention single quotes (') -> html.escape docstring does not mention single quotes (')

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 21:51:40 2011
From: report at bugs.python.org (zvin)
Date: Thu, 08 Sep 2011 19:51:40 +0000
Subject: [issue12938] html.escape docstring does not mention single quotes (')
In-Reply-To: <1315508448.5.0.992592094222.issue12938@psf.upfronthosting.co.za>
Message-ID: <1315511500.96.0.0591343265715.issue12938@psf.upfronthosting.co.za>


zvin  added the comment:

Or maybe instead of updating the docstring, we should remove the single quote (') from _escape_map_full.

cgi.escape did not escaped the single quotes (') and if you use it now, it says: 
"PendingDeprecationWarning: cgi.escape is deprecated, use html.escape instead"

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep  8 21:57:24 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 08 Sep 2011 19:57:24 +0000
Subject: [issue12937] Support install options as found in distutils
In-Reply-To: <1315504187.52.0.368275649699.issue12937@psf.upfronthosting.co.za>
Message-ID: <1315511844.84.0.925222532342.issue12937@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis :


----------
nosy: +Arfrever

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 00:56:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Sep 2011 22:56:22 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315522582.18.0.829468215215.issue11457@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

timespec is just a structure of two integers, so we should expose it as a simple and efficient Python tuple: (int, int). We can simply expose this type in os.stat, or we can do better by providing an optional callback to convert this tuple to a high level object. It looks like everybodys wants something different at high level (decimal, datetime, float128, ...), so giving the choice of the type to the caller looks to be a good idea :-)

os.stat(fn) => timestamps stored as int
os.stat(fn, lambda x: x) => timestamps stored as (int, int)

Callbacks for other data types:

def to_decimal(sec, nsec):
    return decimal.Decimal(sec) + decimal.Decimal(nsec).scaleb(-9)

def to_datetime(sec, nsec):
    # naive, we can do better
    t = sec + nsec*1e-9
    return datetime.datetime.fromtimestamp(t)

def to_float128(sec, nsec):
    return float128(sec) + float128(nsec)*float128(1e-9)

etc.

Using a callback removes also the bootstrap issue: we don't have to prodive to_datetime() in the posix module or in directly in the os module. The datetime module may provide its own callback, or we can write it as a recipe in os.stat documentation.

I don't know how to call this new argument: decode_timestamp? timestamp_callback? ...?

If it is too slow to use a callback, we can take the first option: expose the timestamp as (int, int). For example: os.stat(path, tuple_timestamp=True).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 01:02:54 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 08 Sep 2011 23:02:54 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315522974.4.0.102345338754.issue11457@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis  added the comment:

I suggest to have low-level, POSIX-compatible, (int, int)-based interface in os module and add high-level, decimal.Decimal-based interface in shutil module.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 01:05:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Sep 2011 23:05:31 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1315523131.24.0.712117178932.issue12105@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

See also issue #12760 (Add create mode to open).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 01:18:43 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 08 Sep 2011 23:18:43 +0000
Subject: [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1315523923.24.0.444555743439.issue12760@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis :


----------
nosy: +Arfrever

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 01:19:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Sep 2011 23:19:01 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
Message-ID: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>


New submission from STINNER Victor :

On Windows, Python uses the POSIX API (file descriptors), instead of the native API (file handles). Some features cannot be used using the POSIX API, like setting security attributes. It would be nice to have a io.FileIO using Windows file handlers to get access to all Windows features. It would help feature #12105 to implement "O_CLOEXEC" flag using the lpSecurityAttributes argument.

We can maybe try with a prototype written in Python. Using _pyio.RawIOBase, only readinto(), write(), seek() and truncate() have to be implemented. But it is better to implement also close() :-)

----------
components: IO, Unicode
messages: 143741
nosy: amaury.forgeotdarc, haypo, mmarkk
priority: normal
severity: normal
status: open
title: Add new io.FileIO using the native Windows API
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 01:21:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Sep 2011 23:21:23 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1315524083.53.0.903693511113.issue12939@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

See also issue #1602: a prototype of a console object has been proposed to use the native Windows console API, instead of the POSIX API (read from fd 0, write to fd 1 or 2). The prototype is implemented in Python using ctypes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 01:22:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Sep 2011 23:22:23 +0000
Subject: [issue12105] open() does not able to set flags, such as O_CLOEXEC
In-Reply-To: <1305745889.2.0.237560021123.issue12105@psf.upfronthosting.co.za>
Message-ID: <1315524143.96.0.853432742678.issue12105@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> > Why not to use CreateFile() on Windows platform?
> Good idea! Please open a separate issue for it.

Done, issue #12939.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 01:25:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Sep 2011 23:25:14 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315258413.34.0.212082169153.issue12905@psf.upfronthosting.co.za>
Message-ID: <1315524314.54.0.878626143112.issue12905@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

It looks like Python cannot do much to workaround OpenBSD issues. IMO the best fix is just to skip these tests on OpenBSD, until OpenBSD handles correctly signals in programs linked to pthread. The same "fix" can be used for #12903.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 01:28:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Sep 2011 23:28:34 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315524514.42.0.0159829073321.issue1172711@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

+if have_long_long:
+    class LongLongTest(SignedNumberTest):
+        ...

It is maybe better to use @unittest.skipIf(not have_long_long, 'need long long support'). Except of this nit, the patch looks correct.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 02:04:52 2011
From: report at bugs.python.org (Tim Chase)
Date: Fri, 09 Sep 2011 00:04:52 +0000
Subject: [issue12940] Cmd example using turtle left vs. right doc-bug
Message-ID: <1315526692.9.0.379869372006.issue12940@psf.upfronthosting.co.za>


New submission from Tim Chase :

The Turtle example for the cmd module as documented at

http://docs.python.org/py3k/library/cmd.html#cmd-example

In the left() method, it calls turtle.right() instead of turtle.left().  Easy fix: /def left/+2s/left/right/

Likely exists in most 3.x documentation.

----------
assignee: docs at python
components: Documentation
messages: 143746
nosy: Gumnos, docs at python
priority: normal
severity: normal
status: open
title: Cmd example using turtle left vs. right doc-bug
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 02:05:45 2011
From: report at bugs.python.org (Tim Chase)
Date: Fri, 09 Sep 2011 00:05:45 +0000
Subject: [issue12940] Cmd example using turtle left vs. right doc-bug
In-Reply-To: <1315526692.9.0.379869372006.issue12940@psf.upfronthosting.co.za>
Message-ID: <1315526745.26.0.206268170934.issue12940@psf.upfronthosting.co.za>


Tim Chase  added the comment:

(duh, sorry, that's the "do_left" method, not the "left" method)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 02:11:01 2011
From: report at bugs.python.org (John Feuerstein)
Date: Fri, 09 Sep 2011 00:11:01 +0000
Subject: [issue12941] add random.pop()
Message-ID: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>


New submission from John Feuerstein :

This patch against current hg tip (72314:92842e347d98) adds random.pop():

    pop(self, seq) method of Random instance
        Remove and return a random element from a non-empty sequence.

Includes test case.

----------
components: Library (Lib)
files: random_pop.diff
keywords: patch
messages: 143748
nosy: jfeuerstein
priority: normal
severity: normal
status: open
title: add random.pop()
type: feature request
versions: Python 3.4
Added file: http://bugs.python.org/file23120/random_pop.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 02:42:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Sep 2011 00:42:04 +0000
Subject: [issue12940] Cmd example using turtle left vs. right doc-bug
In-Reply-To: <1315526692.9.0.379869372006.issue12940@psf.upfronthosting.co.za>
Message-ID: <1315528924.67.0.17387256368.issue12940@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti, sandro.tosi
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 02:50:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Sep 2011 00:50:51 +0000
Subject: [issue12941] add random.pop()
In-Reply-To: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>
Message-ID: <1315529451.43.0.67446795611.issue12941@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti, rhettinger
stage:  -> patch review
versions: +Python 3.3 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 03:28:04 2011
From: report at bugs.python.org (Aaron Meurer)
Date: Fri, 09 Sep 2011 01:28:04 +0000
Subject: [issue12942] Shebang line fixer for 2to3
Message-ID: <1315531684.56.0.727993232351.issue12942@psf.upfronthosting.co.za>


New submission from Aaron Meurer :

As suggested in this thread in the Python porting list (http://mail.python.org/pipermail/python-porting/2011-September/000231.html), it would be nice if 2to3 had a fixer that translated shebang lines from 

#! /usr/bin/env python

to

#! /usr/bin/env python3

Also relevant here is the draft PEP 394 (http://www.python.org/dev/peps/pep-0394/), which apparently is likely to be accepted.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 143749
nosy: Aaron.Meurer
priority: normal
severity: normal
status: open
title: Shebang line fixer for 2to3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 04:29:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Sep 2011 02:29:06 +0000
Subject: [issue12904] Change os.utime &c functions to use nanosecond precision
	where possible
In-Reply-To: <1315256882.76.0.179568612134.issue12904@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 1de6619733d9 by Larry Hastings in branch 'default':
Issue #12904: os.utime, os.futimes, os.lutimes, and os.futimesat now write
http://hg.python.org/cpython/rev/1de6619733d9

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 05:02:12 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 09 Sep 2011 03:02:12 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315537332.32.0.547743501092.issue1172711@psf.upfronthosting.co.za>


Changes by Meador Inge :


Added file: http://bugs.python.org/file23121/issue-1172711.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 05:04:20 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 09 Sep 2011 03:04:20 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315537460.12.0.245730813436.issue1172711@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Victor, I like the decorator approach much better.  Thanks.  Attached is a new patch with that update.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 05:11:07 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 09 Sep 2011 03:11:07 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
Message-ID: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>


New submission from Meador Inge :

In 2.x, 'python -m tokenize' worked great:

[meadori at motherbrain cpython]$ python2.7 -m tokenize test.py
1,0-1,5:        NAME    'print'
1,6-1,21:       STRING  '"Hello, World!"'
1,21-1,22:      NEWLINE '\n'
2,0-2,0:        ENDMARKER       ''

In 3.x, however, the functionality has been removed and replaced with
some hard-wired test code:

[meadori at motherbrain cpython]$ python3 -m tokenize test.py
TokenInfo(type=57 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line='')
TokenInfo(type=1 (NAME), string='def', start=(1, 0), end=(1, 3),
line='def parseline(self, line):')
TokenInfo(type=1 (NAME), string='parseline', start=(1, 4), end=(1,
13), line='def parseline(self, line):')
TokenInfo(type=53 (OP), string='(', start=(1, 13), end=(1, 14),
line='def parseline(self, line):')
...

The functionality was removed here [1], but with no explanation.  Let's add it back and document the functionality this time around.

[1] http://hg.python.org/cpython/rev/51e24512e305/

----------
components: Library (Lib)
messages: 143752
nosy: meadori
priority: normal
severity: normal
stage: needs patch
status: open
title: tokenize: add python -m tokenize support back
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 05:30:29 2011
From: report at bugs.python.org (Julian Berman)
Date: Fri, 09 Sep 2011 03:30:29 +0000
Subject: [issue12941] add random.pop()
In-Reply-To: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>
Message-ID: <1315539029.19.0.080401357695.issue12941@psf.upfronthosting.co.za>


Julian Berman  added the comment:

Considering this is pretty easily written more or less as

    r = range(20)
    r.pop(random.randrange(0, len(r)))

is it really worth adding?

----------
nosy: +Julian

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 06:11:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Sep 2011 04:11:22 +0000
Subject: [issue12942] Shebang line fixer for 2to3
In-Reply-To: <1315531684.56.0.727993232351.issue12942@psf.upfronthosting.co.za>
Message-ID: <1315541482.41.0.54957412358.issue12942@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 08:32:49 2011
From: report at bugs.python.org (Rene Dudfield)
Date: Fri, 09 Sep 2011 06:32:49 +0000
Subject: [issue12944] setup.py upload to pypi needs to work with specified
	files
Message-ID: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>


New submission from Rene Dudfield :

We need to specify files to upload to pypi.  Otherwise we have to use the web interface.

'Regarding the "setup.py upload" command, this isn't very helpful because it will not upload a package that was already built - for example, a Windows package built on another host while I am trying to release from a Linux desktop. Since automatic package building across a build farm is the only way I can actually build packages for most platforms, this rules out use of the "upload" command.'

See this post for more details:
http://as.ynchrono.us/2011/09/releasing-python-software-is-tedious.html

----------
assignee: tarek
components: Distutils
messages: 143754
nosy: eric.araujo, illume, tarek
priority: normal
severity: normal
status: open
title: setup.py upload to pypi needs to work with specified files
type: feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 08:46:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 09 Sep 2011 06:46:05 +0000
Subject: [issue12905] multiple errors in test_socket on OpenBSD
In-Reply-To: <1315524314.54.0.878626143112.issue12905@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

> It looks like Python cannot do much to workaround OpenBSD issues. IMO the best fix is just to skip these tests on OpenBSD, until OpenBSD handles correctly signals in programs linked to pthread. The same "fix" can be used for #12903.

Agreed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 08:52:36 2011
From: report at bugs.python.org (Nam Nguyen)
Date: Fri, 09 Sep 2011 06:52:36 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1315551156.78.0.0579675543817.issue6715@psf.upfronthosting.co.za>


Nam Nguyen  added the comment:

In uint32_converter, I'm not sure the if statement comparing val and UINT32_MAX makes sense. val was defined to be unsigned long, which is 32bit on 32-bit compiler.

----------
nosy: +Nam.Nguyen

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 10:08:25 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 09 Sep 2011 08:08:25 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1315555705.84.0.496589960741.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

> In uint32_converter, I'm not sure the if statement comparing val and
> UINT32_MAX makes sense. val was defined to be unsigned long, which is
> 32bit on 32-bit compiler.

Yes, on a 32-bit system, this comparison will always be false. However,
on a 64-bit system, an unsigned long will (usually) be 64 bits wide. In
this case, we do need to check that the value fits into a uint32_t.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 12:01:57 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Sep 2011 10:01:57 +0000
Subject: [issue12555] PEP 3151 implementation
In-Reply-To: <1310595572.06.0.21556538548.issue12555@psf.upfronthosting.co.za>
Message-ID: <1315562517.45.0.135389890365.issue12555@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I still need to understand the full impact of the PEP, but it seems
very sound. I've left two small comments on Rietveld, and there's
an additional question:


Should the input of OSError be checked?

>>> OSError("not an errno", "Bad file descriptor")
OSError('not an errno', 'Bad file descriptor')
>>> o = OSError("not an errno", "Bad file descriptor")
>>> raise o
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno not an errno] Bad file descriptor
>>>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 14:04:55 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 09 Sep 2011 12:04:55 +0000
Subject: [issue12941] add random.pop()
In-Reply-To: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>
Message-ID: <1315569895.2.0.389107868506.issue12941@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> is it really worth adding?

Probably not.  For improvements along these lines, I'd rather see random.choice support sets:

>>> random.choice({1, 2})
Traceback (most recent call last):
  File "", line 1, in 
  File "/Library/Frameworks/Python.framework/Versions/7.1/lib/python2.7/random.py", line 274, in choice
    return seq[int(self.random() * len(seq))]  # raises IndexError if seq is empty
TypeError: 'set' object does not support indexing

But that's another (rejected) issue; see issue 7522.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 15:41:17 2011
From: report at bugs.python.org (John Feuerstein)
Date: Fri, 09 Sep 2011 13:41:17 +0000
Subject: [issue12941] add random.pop()
In-Reply-To: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>
Message-ID: <1315575677.38.0.131111040893.issue12941@psf.upfronthosting.co.za>


John Feuerstein  added the comment:

> r.pop(random.randrange(0, len(r)))

So seq[random.randrange(0, len(seq))] suddenly makes random.choice(seq) obsolete? There is no functional reasoning here, it's convenience for a common operation.

> Not all the sequences have a .pop() method.

Not all sequences support indexing or item assignment either:

>>> random.choice({1, 2})
TypeError: 'set' object does not support indexing
>>> random.shuffle("abc")
TypeError: 'str' object does not support item assignment
...

> I'd rather see random.choice support sets: ...
> But that's another (rejected) issue; see issue 7522.

So the implicit requirement for random.choice() is support for indexing.
The implicit requirement for random.shuffle() is support for indexing and item assignment. The implicit requirement for random.pop() is support for seq.pop()...

I don't think random's convenience functions should validate (or even worse, convert) input. It's actually great that they are thin wrappers without magic, resulting in the same behaviour as if done without them.

> self.assertIn(pop([25, 75]), [25, 75])
> These should also verify that the element is not in the list anymore.
> Also other test with different (and possibly wrong) input types should be added.

This is true for many convenience functions in random. I've considered doing that at first and came to the conclusion that the tests for random should test the behaviour specific to random, not that of the underlying functionality?

So seq[random] should test for random behaviour, not that indexing of seq itself works correctly. Similarly, seq.pop(random) should test for random behaviour and not for a working seq.pop()?

All we would do here is duplicate tests not related to random.

Please correct me if I'm wrong. I'm glad that this started a discussion.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 15:54:49 2011
From: report at bugs.python.org (Pavel Boldin)
Date: Fri, 09 Sep 2011 13:54:49 +0000
Subject: [issue12945] ctypes works incorrectly with _swappedbytes_ = 1
Message-ID: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>


New submission from Pavel Boldin :

ctypes seems to work incorrectly with _swappedbytes_ specified.

I.e. it misses some values from buffer:

class X(ctypes.Structure):
    _swappedbytes_ = 1
    _pack_ = 1
    _fields_ = [
        ('a', ctypes.c_ubyte, 4),
        ('b', ctypes.c_ubyte, 4),
        ('c', ctypes.c_ushort, 8),
        ('d', ctypes.c_ushort, 8),
    ]

buf = '\x12\x34\x56\x78'
x = X.from_buffer_copy(buf)

print x.a == 1
print x.b == 2
print x.c == 3
print x.d == 4

This prints
True
True
False
False

Where as four 'True' are expected.

----------
components: ctypes
files: test_ctypes.py
messages: 143761
nosy: Pavel.Boldin
priority: normal
severity: normal
status: open
title: ctypes works incorrectly with _swappedbytes_ = 1
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file23122/test_ctypes.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 16:04:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Sep 2011 14:04:26 +0000
Subject: [issue12941] add random.pop()
In-Reply-To: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>
Message-ID: <1315577066.25.0.522485226844.issue12941@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

>> Not all the sequences have a .pop() method.
> Not all sequences support indexing or item assignment either:

All the sequences support indexing and len(), but not assignment (e.g. tuples and strings are sequences, but they are immutable).  So talking about sequences there is incorrect (see also http://docs.python.org/py3k/glossary.html#term-sequence ).

> So seq[random] should test for random behaviour, not that indexing of
> seq itself works correctly. Similarly, seq.pop(random) should test for
> random behaviour and not for a working seq.pop()?

The test should check the behavior of the function, and in this case it includes both getting a random element and removing it.  The test doesn't have to check that seq.pop() is working fine (there are other tests for that) but that it's actually called and that it pops the right element from the input sequence (and not e.g. from a copy of the sequence that might have been created at some point).
In general it's always better to have a test more than one less.

Regarding the function itself, I'm not sure about its usefulness.  While I've used random.choice several times, I never felt the need of popping the elements.  One use case I might think of is picking all the elements of a sequence until there are no more left, without risking to pick the same element twice.  The same result can be achieved by shuffling the sequence and iterate over the elements though (that doesn't actually leave you with an empty sequence, but that's probably just a unimportant side-effect).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 17:10:05 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 09 Sep 2011 15:10:05 +0000
Subject: [issue12942] Shebang line fixer for 2to3
In-Reply-To: <1315531684.56.0.727993232351.issue12942@psf.upfronthosting.co.za>
Message-ID: <1315581005.39.0.136730489676.issue12942@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw :


----------
nosy: +barry

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 18:18:45 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 16:18:45 +0000
Subject: [issue12333] test_distutils and test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1315585125.9.0.321279737211.issue12333@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

I am seen the same problem in 2.7 buildbots. Eric, could you apply this patch to 2.7 branch too?.

Thanks!.

----------
nosy: +jcea
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 18:19:52 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Sep 2011 16:19:52 +0000
Subject: [issue12946] PyModule_GetDict() claims it can never fail, but it can
Message-ID: <1315585192.34.0.742122652176.issue12946@psf.upfronthosting.co.za>


New submission from Stefan Behnel :

As is obvious from the code, PyModule_GetDict() can fail if being passed a non-module object, and when the (unlikely) dict creation at the end fails. The documentation of the C-API function should be fixed to reflect that, i.e. it should state that NULL is returned in the case of an error.

PyObject *
PyModule_GetDict(PyObject *m)
{
    PyObject *d;
    if (!PyModule_Check(m)) {
        PyErr_BadInternalCall();
        return NULL;
    }
    d = ((PyModuleObject *)m) -> md_dict;
    if (d == NULL)
        ((PyModuleObject *)m) -> md_dict = d = PyDict_New();
    return d;
}

----------
assignee: docs at python
components: Documentation
messages: 143764
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: PyModule_GetDict() claims it can never fail, but it can
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  Fri Sep  9 18:30:21 2011
From: report at bugs.python.org (John Feuerstein)
Date: Fri, 09 Sep 2011 16:30:21 +0000
Subject: [issue12941] add random.pop()
In-Reply-To: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>
Message-ID: <1315585821.42.0.343084485466.issue12941@psf.upfronthosting.co.za>


John Feuerstein  added the comment:

> The test doesn't have to check that seq.pop() is working fine (there are other tests for that) but that it's actually called and that it pops the right element from the input sequence (and not e.g. from a copy of the sequence that might have been created at some point).

I agree, that makes sense.

> One use case I might think of is picking all the elements of a sequence until there are no more left, without risking to pick the same element twice.  The same result can be achieved by shuffling the sequence and iterate over the elements though (that doesn't actually leave you with an empty sequence, but that's probably just a unimportant side-effect).

One problem with shuffling in this use case is that you lose the otherwise original order of the remaining elements, so there is no way to return from "pop random elements" to "pop elements in order" (without working on a shallow copy). However, I would agree that this is rather uncommon.

Feel free to close this as "wont fix", after all it is trivial for the user to randomly pop elements out of a sequence himself (see above).

There might be other use cases. If nothing else, there's at least issue 12941 to reference now.

Thanks!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 18:32:42 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 09 Sep 2011 16:32:42 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1315585962.46.0.786178896393.issue12915@psf.upfronthosting.co.za>


Changes by Daniel Urban :


----------
nosy: +durban

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 18:51:26 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Sep 2011 16:51:26 +0000
Subject: [issue12333] test_distutils and test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset a74483c12740 by Jesus Cea in branch '2.7':
Issue #12333: fix test_distutils failures under Solaris and derivatives. Patch by Antoine Pitrou
http://hg.python.org/cpython/rev/a74483c12740

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 18:54:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 16:54:38 +0000
Subject: [issue12896] Recommended location of the interpreter for Python 3
In-Reply-To: <1315201831.61.0.39811771821.issue12896@psf.upfronthosting.co.za>
Message-ID: <1315587278.23.0.973325697485.issue12896@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo
versions:  -Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 18:55:46 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 09 Sep 2011 16:55:46 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315587346.3.0.820041047313.issue12936@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

You don't have a core dump, do you?

----------
nosy: +neologix

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 18:56:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 16:56:17 +0000
Subject: [issue12333] test_distutils and test_packaging failures under Solaris
In-Reply-To: <1308061607.43.0.119074494077.issue12333@psf.upfronthosting.co.za>
Message-ID: <1315587377.81.0.974232905884.issue12333@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I got your message but you committed before I could do it :)  Thanks!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 18:57:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 16:57:33 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1315587453.85.0.938324344469.issue12841@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> I think we have to go without a unit test.
May I ask why?  I don?t know tarfile well, but I know that a lot can be done with unittest.

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:10:50 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:10:50 +0000
Subject: [issue12919] Control what module is imported first
In-Reply-To: <1315331616.23.0.265275073086.issue12919@psf.upfronthosting.co.za>
Message-ID: <1315588250.84.0.0533632743203.issue12919@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Thomas: I assume you have ?hg add?-ed the file; you may need to use git-style diffs to have new files included in diffs: http://hgtip.com/tips/beginner/2009-10-22-always-use-git-diffs/

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:11:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Sep 2011 17:11:28 +0000
Subject: [issue12896] Recommended location of the interpreter for Python 3
In-Reply-To: <1315201831.61.0.39811771821.issue12896@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 4c7566669be5 by ?ric Araujo in branch '3.2':
Fix current name of the Python 3 binary on Unix (#12896).
http://hg.python.org/cpython/rev/4c7566669be5

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:13:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:13:13 +0000
Subject: [issue12896] Recommended location of the interpreter for Python 3
In-Reply-To: <1315201831.61.0.39811771821.issue12896@psf.upfronthosting.co.za>
Message-ID: <1315588393.03.0.569447636332.issue12896@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Thanks for the report.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:16:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:16:18 +0000
Subject: [issue12920] inspect.getsource fails to get source of local classes
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1315588578.58.0.205823567491.issue12920@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> inspect.getsource called with a class defined in the same file fails
> with TypeError:  is a built-in class

The error message makes me think that getsource(__main__) was used, not getsource(SomeClass).  Can you check again?

----------
nosy: +eric.araujo
title: Inspect.getsource fails to get source of local classes -> inspect.getsource fails to get source of local classes
versions:  -Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:17:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:17:41 +0000
Subject: [issue12893] Invitation to connect on LinkedIn
In-Reply-To: <994986435.5527283.1315166754531.JavaMail.app@ela4-bed84.prod>
Message-ID: <1315588661.77.0.519159711001.issue12893@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


Removed file: http://bugs.python.org/file23098/unnamed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:18:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:18:45 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1315588725.71.0.834912944256.issue1492704@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

By testing, I mean running ./python -m test test_shutil

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:22:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:22:34 +0000
Subject: [issue12947] Examples in library/doctest.html lack the flags
Message-ID: <1315588954.16.0.979263107509.issue12947@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

The docs for the doctest module contains examples that use doctest flags to control behavior, but the HTML version does not contain the flags, making the examples useless.

I don?t know if this is a bug with the HTML builder or something we can fix in markup.

----------
assignee: docs at python
components: Documentation
messages: 143775
nosy: docs at python, eric.araujo, georg.brandl
priority: normal
severity: normal
status: open
title: Examples in library/doctest.html lack the flags
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:25:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:25:18 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1315589118.09.0.426139368007.issue6703@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

The revision you linked to seems to say that Georg was the one who added this code.

----------
nosy: +georg.brandl
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:25:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Sep 2011 17:25:41 +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: <1315589141.69.0.381484072815.issue12947@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:30:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:30:08 +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: <1315589408.55.0.49804298376.issue12947@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Ezio prompted me to give precise examples, and I can?t find any in the docs online.  Maybe it was only a local build with certain options that caused this problem, I?ll reopen if I find out.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:33:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:33:30 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1315589610.43.0.270948108897.issue12301@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

After thinking about this, I think it may be easier for everyone if I just did the change.  It?s just a list of boring grep-sed combos to run, and it?s easier if a core dev just does it instead of reviewing a long patch.  Sorry if you invested time, Bryce.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:36:01 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 09 Sep 2011 17:36:01 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1315589761.63.0.583301830302.issue6703@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

> The revision you linked to seems to say that Georg was the one who
> added this code.

Can you elaborate?  Line 355 in trunk was last edited by "edloper".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:36:33 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 09 Sep 2011 17:36:33 +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: <1315589793.29.0.1129115296.issue12947@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Hehe... Sphinx makes a point of *removing* doctest flags, to enable doctesting of code snippets without distracting the reader with the test-internal flags.

I think it's because you used a newer version locally.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:39:22 2011
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Fri, 09 Sep 2011 17:39:22 +0000
Subject: [issue1492704] distinct error type from shutil.move()
Message-ID: <1315589962.7.0.439890225305.issue1492704@psf.upfronthosting.co.za>


Gennadiy Zlobin  added the comment:

Yes, I got Windows 7, downloaded VS 2008 express, compiled, ran
python python_d.exe -m test test_shutil 
and tests failed. I found out that os.rename does not raise OSError, according to my previous comment...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 19:42:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 09 Sep 2011 17:42:35 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1315590155.94.0.328533434512.issue6703@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I misread the Subversion viewer, it was actually PJE in r45248 (if I read correctly this time :)

----------
nosy: +pje

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:25:35 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 18:25:35 +0000
Subject: [issue12948] multiprocessing test failures can hang the buildbots
Message-ID: <1315592735.18.0.0641673256441.issue12948@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n :

Some failures in the multiprocessing testsuite can leave processes around, hanging the buildbots (until the timeout).

I take care of this myself.

----------
assignee: jcea
messages: 143783
nosy: jcea
priority: normal
severity: normal
status: open
title: multiprocessing test failures can hang the buildbots
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:26:29 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 09 Sep 2011 18:26:29 +0000
Subject: [issue12949] Documentation of PyCode_New() lacks kwonlyargcount
	argument
Message-ID: <1315592789.75.0.632556595518.issue12949@psf.upfronthosting.co.za>


New submission from Stefan Behnel :

In Py3, PyCode_New() takes a new argument "kwonlyargcount". The signature change is not currently in the Py3 C-API documentation.

http://docs.python.org/dev/c-api/code.html

PyCodeObject *
PyCode_New(int argcount, int kwonlyargcount,
           int nlocals, int stacksize, int flags,
           PyObject *code, PyObject *consts, PyObject *names,
           PyObject *varnames, PyObject *freevars, PyObject *cellvars,
           PyObject *filename, PyObject *name, int firstlineno,
           PyObject *lnotab)

----------
assignee: docs at python
components: Documentation
messages: 143784
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: Documentation of PyCode_New() lacks kwonlyargcount argument
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:35:05 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Sep 2011 18:35:05 +0000
Subject: [issue12948] multiprocessing test failures can hang the buildbots
In-Reply-To: <1315592735.18.0.0641673256441.issue12948@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset ebeb58f3de39 by Jesus Cea in branch '3.2':
Close issue #12948: multiprocessing test failures can hang the buildbots
http://hg.python.org/cpython/rev/ebeb58f3de39

New changeset 1e189d55721c by Jesus Cea in branch 'default':
Close issue #12948: multiprocessing test failures can hang the buildbots
http://hg.python.org/cpython/rev/1e189d55721c

New changeset b376534856a3 by Jesus Cea in branch '2.7':
Close issue #12948: multiprocessing test failures can hang the buildbots
http://hg.python.org/cpython/rev/b376534856a3

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:35:46 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 18:35:46 +0000
Subject: [issue12948] multiprocessing test failures can hang the buildbots
In-Reply-To: <1315592735.18.0.0641673256441.issue12948@psf.upfronthosting.co.za>
Message-ID: <1315593346.39.0.76174118063.issue12948@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:37:38 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Sep 2011 18:37:38 +0000
Subject: [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1315593458.11.0.180808743069.issue12902@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

The immediate issue is improvement of the entries for help and help():

In builtin functions section:

Expand "Invoke the built-in help system." to
"Invoke the built-in help system, which uses *pydoc*."
where *pydoc* is linked to the pydoc section.

Add to the end of the entry something like "As needed, pydoc imports modules to get their doc strings."

The special string 'modules' is not documented in the manual entry for help() itself. That is fine. It does appear in the longer text that appears for 'help()'. That text, where ever it is, could and should have a warning.

"Warning: gathering the results for the topic 'modules' can take considerable time and have side effects as it imports *every* module available to get at its doc string."

A separate issue would be a feature request to not do that (assuming it really does). Given that 'modules' just produces a list of (incomplete) module names, I do not see the point of importing until one requests help on a particular name.

There seems to be a bug. In a fresh 3.2.2 IDLE window, help('modules') produces about 300 names. If I repeat, I get a reduced list of 58 names. These seem to just be the builtin C-coded modules, like 'math', with all Python-coded modules, like 'random', omitted.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, terry.reedy
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:55:59 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 18:55:59 +0000
Subject: [issue12950] multiprocessing "test_fd_transfer" fails under
	OpenIndiana
Message-ID: <1315594559.68.0.697746063648.issue12950@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n :

Buildbots running OpenIndiana 147 show failures in multiprocessing "test_fd_transfer":

"""
======================================================================
ERROR: test_fd_transfer (test.test_multiprocessing.WithProcessesTestConnection)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/test/test_multiprocessing.py", line 1597, in test_fd_transfer
    reduction.send_handle(conn, fd, p.pid)
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/multiprocessing/reduction.py", line 80, in send_handle
    _multiprocessing.sendfd(conn.fileno(), handle)
OSError: [Errno 9] Bad file number

======================================================================
ERROR: test_large_fd_transfer (test.test_multiprocessing.WithProcessesTestConnection)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/test/test_multiprocessing.py", line 1626, in test_large_fd_transfer
    reduction.send_handle(conn, newfd, p.pid)
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/multiprocessing/reduction.py", line 80, in send_handle
    _multiprocessing.sendfd(conn.fileno(), handle)
OSError: [Errno 9] Bad file number

----------------------------------------------------------------------
"""

Buildbots are running OpenIndiana 147 (this is not the last OI version, could be a OI bug).

This test seem to work correctly under Solaris 10 Update 9.

----------
messages: 143787
nosy: jcea
priority: normal
severity: normal
stage: needs patch
status: open
title: multiprocessing "test_fd_transfer" fails under OpenIndiana
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:56:40 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 18:56:40 +0000
Subject: [issue12950] multiprocessing "test_fd_transfer" fails under
	OpenIndiana
In-Reply-To: <1315594559.68.0.697746063648.issue12950@psf.upfronthosting.co.za>
Message-ID: <1315594600.18.0.149028798704.issue12950@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

Example: 

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:57:43 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Sep 2011 18:57:43 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za>
Message-ID: <1315594663.92.0.0878989522122.issue12913@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

If you write 'How to debug Python code' rather than just "How to use pdb", I would start with the use of print statements and binary search. Have short sections on using trace and profile. Very useful would be a list of error messages and possible un-obvious to beginners but common causes. The following example comes up regularly on python-list.

TypeError: 'int' object is not callable
  Look in the previous line to see what you called. If it is a builtin name, perhaps you re-assigned the name to something else. Example:

list = 3

list(1,2,3)
Traceback (most recent call last):
  File "", line 1, in 
    list(1,2,3)
TypeError: 'int' object is not callable 

Another one we see occasionally ("Is module x broken?") is something like: user runs script.py

import random
x = random.random()
Traceback...
NameError: name 'random.random' is not defined

Solution: user has a file random.py in the same directory

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 20:59:59 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Fri, 09 Sep 2011 18:59:59 +0000
Subject: [issue12920] inspect.getsource fails to get source of local classes
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1315594799.24.0.20064280094.issue12920@psf.upfronthosting.co.za>


Popa Claudiu  added the comment:

Yes. On Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32, the result for the following lines:

import inspect
class A:
    pass
inspect.getsource(A)

is:

Traceback (most recent call last):
  File "E:/Scripts/Snippets/test_inspect_bug.py", line 4, in 
    inspect.getsource(A)
  File "C:\Python32\lib\inspect.py", line 694, in getsource
    lines, lnum = getsourcelines(object)
  File "C:\Python32\lib\inspect.py", line 683, in getsourcelines
    lines, lnum = findsource(object)
  File "C:\Python32\lib\inspect.py", line 522, in findsource
    file = getsourcefile(object)
  File "C:\Python32\lib\inspect.py", line 441, in getsourcefile
    filename = getfile(object)
  File "C:\Python32\lib\inspect.py", line 406, in getfile
    raise TypeError('{!r} is a built-in class'.format(object))
TypeError:  is a built-in class
>>>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:19:21 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 09 Sep 2011 19:19:21 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315595961.81.0.0519329031613.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

No such luck. Somehow gdb doesn't dump the core file:


[ 25/359] test_urllib2_localnet
Fatal Python error: Segmentation fault

Current thread 0x400225f0:
  File "/home/user/cpython-e91ad9669c08/Lib/socket.py", line 389 in create_connection
  File "/home/user/cpython-e91ad9669c08/Lib/http/client.py", line 721 in connect
  File "/home/user/cpython-e91ad9669c08/Lib/http/client.py", line 743 in send
  File "/home/user/cpython-e91ad9669c08/Lib/http/client.py", line 805 in _send_output
  File "/home/user/cpython-e91ad9669c08/Lib/http/client.py", line 960 in endheaders
  File "/home/user/cpython-e91ad9669c08/Lib/http/client.py", line 1002 in _send_request
  File "/home/user/cpython-e91ad9669c08/Lib/http/client.py", line 964 in request
  File "/home/user/cpython-e91ad9669c08/Lib/urllib/request.py", line 1145 in do_open
  File "/home/user/cpython-e91ad9669c08/Lib/urllib/request.py", line 1165 in http_open
  File "/home/user/cpython-e91ad9669c08/Lib/urllib/request.py", line 347 in _call_chain
  File "/home/user/cpython-e91ad9669c08/Lib/urllib/request.py", line 387 in _open
  File "/home/user/cpython-e91ad9669c08/Lib/urllib/request.py", line 369 in open
  File "/home/user/cpython-e91ad9669c08/Lib/urllib/request.py", line 138 in urlopen
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/case.py", line 136 in handle
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/case.py", line 572 in assertRaises
  File "/home/user/cpython-e91ad9669c08/Lib/test/test_urllib2_localnet.py", line 537 in test_bad_address
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/case.py", line 386 in _executeTestPart
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/case.py", line 441 in run
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/case.py", line 493 in __call__
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 105 in run
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 67 in __call__
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 105 in run
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/suite.py", line 67 in __call__
  File "/home/user/cpython-e91ad9669c08/Lib/unittest/runner.py", line 168 in run
  File "/home/user/cpython-e91ad9669c08/Lib/test/support.py", line 1293 in _run_suite
  File "/home/user/cpython-e91ad9669c08/Lib/test/support.py", line 1327 in run_unittest
  File "/home/user/cpython-e91ad9669c08/Lib/test/test_urllib2_localnet.py", line 561 in test_main
  File "/home/user/cpython-e91ad9669c08/Lib/test/support.py", line 1420 in decorator
  File "/home/user/cpython-e91ad9669c08/Lib/test/regrtest.py", line 1140 in runtest_inner
  File "/home/user/cpython-e91ad9669c08/Lib/test/regrtest.py", line 905 in runtest
  File "/home/user/cpython-e91ad9669c08/Lib/test/regrtest.py", line 708 in main
  File "/home/user/cpython-e91ad9669c08/Lib/test/__main__.py", line 13 in 
  File "/home/user/cpython-e91ad9669c08/Lib/runpy.py", line 73 in _run_code
  File "/home/user/cpython-e91ad9669c08/Lib/runpy.py", line 160 in _run_module_as_main
make: *** [buildbottest] Segmentation fault (core dumped)


user at debian-arm:~/cpython-e91ad9669c08$ ulimit -c
unlimited
user at debian-arm:~/cpython-e91ad9669c08$ ls core
ls: cannot access core: No such file or directory
user at debian-arm:~/cpython-e91ad9669c08$ find . -name core
user at debian-arm:~/cpython-e91ad9669c08$ 


When I run under gcc, the test are automatically interrupted
by SIGINT at some point. Perhaps this is another broken
threading implementation. I'll try --without-threads.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:28:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Sep 2011 19:28:52 +0000
Subject: [issue12299] Stop documenting functions added by site as builtins
In-Reply-To: <1307636270.04.0.997555638345.issue12299@psf.upfronthosting.co.za>
Message-ID: <1315596532.22.0.880304421045.issue12299@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Can we close this as out-of-date, since 2/3rds of what you asked seems to be done already, and the last 1/3 should (in my opinion) absolutely not be?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:29:04 2011
From: report at bugs.python.org (=?utf-8?b?4KS24KSC4KSk4KSo4KWC?=)
Date: Fri, 09 Sep 2011 19:29:04 +0000
Subject: [issue12951] List behavior is different
Message-ID: <1315596544.14.0.783397700321.issue12951@psf.upfronthosting.co.za>


New submission from ????? :

URL: http://docs.python.org/library/stdtypes.html

Following example is given.

>>> lists = [[]] * 3
>>> lists
[[], [], []]
>>> lists[0].append(3)
>>> lists
[[3], [3], [3]]


Behavior is as follows.

>>> a = [[]] * 3
>>> a
[[], [], []]
>>> a[0] = 1
>>> a
[1, [], []]
>>> 


Python interpreter details:

$ python
Python 2.7.2 (default, Aug 22 2011, 13:53:27) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

----------
assignee: docs at python
components: Documentation
messages: 143793
nosy: docs at python, ?????
priority: normal
severity: normal
status: open
title: List behavior is different
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:29:05 2011
From: report at bugs.python.org (Tim Chase)
Date: Fri, 09 Sep 2011 19:29:05 +0000
Subject: [issue12940] Cmd example using turtle left vs. right doc-bug
In-Reply-To: <1315526692.9.0.379869372006.issue12940@psf.upfronthosting.co.za>
Message-ID: <1315596545.59.0.0429896469174.issue12940@psf.upfronthosting.co.za>


Tim Chase  added the comment:

I see the status changed to needs-patch.  what do I patch against?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:29:08 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Sep 2011 19:29:08 +0000
Subject: [issue12914] Add cram function to textwrap
In-Reply-To: <1315326488.16.0.0777914338919.issue12914@psf.upfronthosting.co.za>
Message-ID: <1315596548.05.0.304216160882.issue12914@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

It is already available:
>>> import pydoc
>>> pydoc.cram('This sentence is too long to fit the space I have made available', 28)
'This sentenc...ade available'

def cram(text, maxlen):
    """Omit part of a string if needed to make it fit in a maximum length."""
    if len(text) > maxlen:
        pre = max(0, (maxlen-3)//2)
        post = max(0, maxlen-3-pre)
        return text[:pre] + '...' + text[len(text)-post:]
    return text

It could be documented in place, or moved and imported into pydoc. I am +0 at the moment.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:41:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Sep 2011 19:41:58 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1315597318.29.0.562599151261.issue12915@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

To be a little clearer, this is about dotted import names, not regular dotted names.
pydoc.locate(path, forceload=0):
  """Locate an object by name or dotted path, importing as necessary"""
pydoc.resolve(thing, forceload=0):
  """Given an object or a path to an object, get the object and its name.""" 

It is not completely clear to me how this is different from using __import__ but I will believe it is. It something like this is in at least 3 places, +1 on factoring it out to one place.

----------
nosy: +terry.reedy
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:48:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Sep 2011 19:48:25 +0000
Subject: [issue12940] Cmd example using turtle left vs. right doc-bug
In-Reply-To: <1315526692.9.0.379869372006.issue12940@psf.upfronthosting.co.za>
Message-ID: <1315597705.34.0.130724013519.issue12940@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

3.2. Any patch should trivially port to 3.3 and 2.7

----------
nosy: +terry.reedy
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:51:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Sep 2011 19:51:49 +0000
Subject: [issue12941] add random.pop()
In-Reply-To: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>
Message-ID: <1315597909.29.0.833580558356.issue12941@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
resolution:  -> rejected
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:52:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Sep 2011 19:52:59 +0000
Subject: [issue12942] Shebang line fixer for 2to3
In-Reply-To: <1315531684.56.0.727993232351.issue12942@psf.upfronthosting.co.za>
Message-ID: <1315597979.43.0.370169696153.issue12942@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:55:16 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 19:55:16 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1315598116.11.0.129358174702.issue6755@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

I have compiled ncurses myself, supporting wide characters. I get this warnings in the buildbots:

"""
/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Modules/_cursesmodule.c:920: warning: implicit declaration of function 'wget_wch'
/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Modules/_cursesmodule.c:927: warning: implicit declaration of function 'mvwget_wch'
/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Modules/_cursesmodule.c:2760: warning: implicit declaration of function 'unget_wch'
"""

Studying the "ncurses.h", I see the definition of "wget_wch" and others. But these definitions are created only if "_XOPEN_SOURCE_EXTENDED" is defined.

Something to be explored?.

----------
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 21:57:35 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 19:57:35 +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: <1315598255.26.0.582082691435.issue12567@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 22:13:39 2011
From: report at bugs.python.org (Phillip J. Eby)
Date: Fri, 09 Sep 2011 20:13:39 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1315599219.16.0.372815946457.issue6703@psf.upfronthosting.co.za>


Phillip J. Eby  added the comment:

No, I only consolidated the two copies of the code to a single function, in order to more easily add the PEP 302 support.  The feature was already there.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 22:17:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Sep 2011 20:17:18 +0000
Subject: [issue12948] multiprocessing test failures can hang the buildbots
In-Reply-To: <1315592735.18.0.0641673256441.issue12948@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 9f4d72da69a8 by Jesus Cea in branch '2.7':
Fix issue #12948: multiprocessing test failures can hang the buildbots
http://hg.python.org/cpython/rev/9f4d72da69a8

New changeset 559ea53e25df by Jesus Cea in branch '3.2':
Fix issue #12948: multiprocessing test failures can hang the buildbots
http://hg.python.org/cpython/rev/559ea53e25df

New changeset c9a72fb5968d by Jesus Cea in branch 'default':
Fix issue #12948: multiprocessing test failures can hang the buildbots
http://hg.python.org/cpython/rev/c9a72fb5968d

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 22:50:53 2011
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 09 Sep 2011 20:50:53 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315601453.24.0.856996725809.issue11457@psf.upfronthosting.co.za>


Larry Hastings  added the comment:

I think a pair of integers is a poor API.  It ties the value of the fractional part to nanoseconds.  What happens when a future filesystem implements picosecond resolution?  And then later goes to femtoseconds?  Or some platform chooses another divisor (2**32)?  This should all be abstracted away by the API, as the current API does.  Otherwise you start sprinkling magic values in your code (ie 1e9).  Suggesting that other representations (float128, Decimal) can be built on top of the (int,int) interface is irrelevant; obviously, any representation can be built on top of any other.

I think Decimal is reasonable, except that it breaks existing code.  One cannot perform computation between a Decimal and a float, so almost any existing manipulations of atime/utime would start throw exceptions.

I suggest that a float128 type would solve the problem on all counts--nobody would have to change their code, and it would handle nanosecond (or I think even zeptosecond!) resolution.  And when we run out of resolution, we can switch to float256.  (Or an arbitrary-precision float if Python has one by then.)

os.stat added support for float atime/mtime in 2.3, specifically in October 2002:
  http://hg.python.org/cpython/rev/0bbea4dcd9be
This predates both the inclusion of Decimal in Python (2.4) and nanosecond resolution in the utime API (2008).  I could find no discussion of the change, so I don't know what other representations were considered.  It's hard to say what the author of the code might have done if Decimal had existed back then, or if he foresaw nanosecond resolution.

However, that author is already present in this thread ;-)  Martin?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 23:22:41 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 09 Sep 2011 21:22:41 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1315601453.24.0.856996725809.issue11457@psf.upfronthosting.co.za>
Message-ID: 


Alexander Belopolsky  added the comment:

On Fri, Sep 9, 2011 at 4:50 PM, Larry Hastings  wrote:
..
> I think a pair of integers is a poor API. ?It ties the value of the fractional part to nanoseconds. ?What happens
> when a future filesystem implements picosecond resolution?

If history repeats, struct stat will grow new st_xtimesuperspec
fields, st_xtimespec will become a macro expanding to
st_xtimesuperspec.tv_picosec and we will get a request to support that
in os.stat().  I don't see why this conflicts with
stat_result.st_xtimespec returning a (sec, nsec) tuple.  If we will
ever have to support higher resolution,  stat_result will grow another
member with a (sec, picosec) or whatever will be appropriate value.

> ?And then later goes to femtoseconds?

Same thing.

> ?Or some platform chooses another divisor (2**32)?

Unlikely, but C API will dictate Python API if this happens.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 23:36:55 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 09 Sep 2011 21:36:55 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: 
Message-ID: 


Alexander Belopolsky  added the comment:

On Fri, Sep 9, 2011 at 5:22 PM, Alexander Belopolsky
 wrote:
..
> If history repeats, struct stat will grow new st_xtimesuperspec
> fields, st_xtimespec will become a macro expanding to
> st_xtimesuperspec.tv_picosec

On the second thought, this won't work.  To support higher resolution
will need to supply 3 fields in st_xtimesuperspec: tv_sec and tv_nsec
packed in st_xtimespec (say tv_timespec) and new tv_psec field.
st_xtime will now be   st_xtimesuperspec.tv_timespec.tv_sec and
st_xtimespec will be a new macro expanding to
st_xtimesuperspec.tv_timespec.  The rest of my argument still holds.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 23:40:49 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 09 Sep 2011 21:40:49 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1315604449.23.0.103223415438.issue12841@psf.upfronthosting.co.za>


Lars Gust?bel  added the comment:

It's the low-level operating system aspects of tarfile that are very difficult to test, e.g. filesystem and operating system dependent features such as symbolic links, hard links, file permissions, ownership. It is not even possible to reliably determine the filesystem the testsuite currently runs on. Also, superuser privileges are needed for some operations to work, e.g. chown(). A testsuite is normally not run as root, so a test that depends on this will never get enough coverage.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 23:42:00 2011
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 09 Sep 2011 21:42:00 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315604520.38.0.546764937836.issue11457@psf.upfronthosting.co.za>


Larry Hastings  added the comment:

> To support higher resolution
> will need to supply 3 fields in st_xtimesuperspec: tv_sec and tv_nsec
> packed in st_xtimespec (say tv_timespec) and new tv_psec field.
> st_xtime will now be   st_xtimesuperspec.tv_timespec.tv_sec and
> st_xtimespec will be a new macro expanding to
> st_xtimesuperspec.tv_timespec.

How is this superior to using either Decimal or float128?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 23:47:01 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 21:47:01 +0000
Subject: [issue12952] Solaris/Illumos (OpenIndiana) Scheduling policies
Message-ID: <1315604821.27.0.391952177257.issue12952@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n :

Solaris/Illumos (OpenIndiana) have several more Scheduling Policies, specially if the program is running under a Solaris Zone.

OpenIndiana buildbots are running under Zones, and the test is failing because current (under Zones) scheduling policy is not recognized.

I take care of this myself.

----------
assignee: jcea
messages: 143806
nosy: jcea
priority: normal
severity: normal
status: open
title: Solaris/Illumos (OpenIndiana) Scheduling policies
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 23:55:25 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 09 Sep 2011 21:55:25 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1315601453.24.0.856996725809.issue11457@psf.upfronthosting.co.za>
Message-ID: <4E6A8B4B.3010901@v.loewis.de>


Martin v. L?wis  added the comment:

> This predates both the inclusion of Decimal in Python (2.4) and
> nanosecond resolution in the utime API (2008).  I could find no
> discussion of the change, so I don't know what other representations
> were considered.  It's hard to say what the author of the code might
> have done if Decimal had existed back then, or if he foresaw
> nanosecond resolution.
> 
> However, that author is already present in this thread ;-)  Martin?

I think I specifically expected that nanosecond resolution in the file
system API will not be relevant ever, since a nanosecond is damned
short. I also specifically wanted to support units of 100ns, since that
is what NTFS used at that time (and still uses).

I also considered that introducing float would cause backwards
incompatibilities, and provided the stat.float_times setting, and
made only the indexed fields return ints, whereas the named fields
contained floats. I think I would have chosen an arbitrary-precision
fractional type had one been available. If a two-ints representation
is considered necessary, I'd favor a rational number (numerator,
denominator) over a pair (second, subsecond); this would also support
2**-32 fractions (as used in NTP !!!).

As yet another approach, I propose a set of st_[cma]time_nsec fields
which always give an int representing the integral part of the time
stamp in nanoseconds since the epoch. If sub-nanosecond time stamps
ever become a reality, st_[cma]time_asec fields could be added, for
attosecond resolution.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 23:55:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Sep 2011 21:55:47 +0000
Subject: [issue12952] Solaris/Illumos (OpenIndiana) Scheduling policies
In-Reply-To: <1315604821.27.0.391952177257.issue12952@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset e1644c8edc3e by Jesus Cea in branch 'default':
Close issue 12952: Solaris/Illumos (OpenIndiana) Scheduling policies
http://hg.python.org/cpython/rev/e1644c8edc3e

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep  9 23:58:57 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 21:58:57 +0000
Subject: [issue12952] Solaris/Illumos (OpenIndiana) Scheduling policies
In-Reply-To: <1315604821.27.0.391952177257.issue12952@psf.upfronthosting.co.za>
Message-ID: <1315605537.41.0.945379420136.issue12952@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

Under Solaris 10 Update 9, FSS (Fair Share Scheduling) is usually used in the Zones, but it is not defined in "sched.h", so the test will fail.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 00:09:14 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 09 Sep 2011 22:09:14 +0000
Subject: [issue12763] test_posix failure on OpenIndiana
In-Reply-To: <1313517544.51.0.534780325686.issue12763@psf.upfronthosting.co.za>
Message-ID: <1315606154.17.0.765854170203.issue12763@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

This fix is incorrect. It is ignoring a common case (a process running under a Solaris Zone) completelly.

Since the intention of the test is to check the access to the scheduling information of a different process, I change it to access the parent, instead of a hardcoded "init".

I take care of this.

----------
assignee: benjamin.peterson -> jcea
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 00:18:14 2011
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 09 Sep 2011 22:18:14 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315606694.82.0.804335826955.issue11457@psf.upfronthosting.co.za>


Larry Hastings  added the comment:

I've drawn an ASCII table summarizing the proposals so far.  If I've made any factual errors I trust you'll let me know.


= means os.stat().st_mtime is changed to that type.
+ means os.stat() grows a new field using that type,
  and the current behavior of st_mtime is unchanged.

___________________________________________________________________________

[ UPSIDES      ]        =(int,int)  +(int,int) =Decimal +Decimal =float128
[ yes is good! ]

all existing code gets   no           no        no       no       yes
more accurate for free

some existing code gets  no           no        yes      no       yes
more accurate for free

guaranteed
future-proof against     no           no        yes      yes      no*
new representations

very very
future-proof against     no           no        yes      yes      yes*
new representations

* float128 could handle representations finer than yoctosecond resolution,
  10**-24, but not another 10**-3.  fwiw, yocto is currently the smallest
  defined prefix.
___________________________________________________________________________

[ DOWNSIDES   ]          =(int,int)  +(int,int) =Decimal +Decimal =float128
[ yes is bad! ]

breaks existing code      yes          no        yes      no       no

requires new code in
order to take advantage   yes*         yes       yes*     yes      no
of added precision

requires implementing a   no           no        no       no       yes
complicated new type

* Since this option breaks existing code, obviously people will have to
  write new code in order to cope.
___________________________________________________________________________


My take on the above: if we're willing to put people through the pain of changing their code to use the new accuracy, then Decimal is the obvious winner.  I see no advantage to any of the pair-of-floats proposals over Decimal.

If we want all existing code to continue working and get more accurate automatically, the only viable option is float128 (or a multiple-precision float).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 00:24:46 2011
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 09 Sep 2011 22:24:46 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315607086.91.0.256436221974.issue11457@psf.upfronthosting.co.za>


Larry Hastings  added the comment:

s/pair-of-floats/pair-of-ints/

Also, to be clear: yocto is the smallest defined SI prefix.  And what I meant when I referred to 10**-3 was, float128 could handle 10**-24 but not 10**-27.  According to my back-of-the-envelope calculations, float128 could accurately represent timestamps with yoctosecond resolution for another 650 years to come.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 00:37:22 2011
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 09 Sep 2011 22:37:22 +0000
Subject: [issue12953] Function calls missing from profiler output
Message-ID: <1315607842.02.0.28762981022.issue12953@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau :

I noticed that some function calls don't get reported by profile/cProfile. For example, 'len' works fine, but calls to 'range' or functions in 'itertools' don't show up. Is this a known limitation?

I remember that there was a bug in profiling C-functions with keyword arguments (issue5330, fixed), but I don't have the time right now to investigate whether this is related.

----------
components: Library (Lib)
messages: 143813
nosy: hagen
priority: normal
severity: normal
status: open
title: Function calls missing from profiler output
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 01:17:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Sep 2011 23:17:31 +0000
Subject: [issue12763] test_posix failure on OpenIndiana
In-Reply-To: <1313517544.51.0.534780325686.issue12763@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset dba886806eb3 by Jesus Cea in branch 'default':
Better fix for #12763: test_posix failure on OpenIndiana
http://hg.python.org/cpython/rev/dba886806eb3

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 01:26:49 2011
From: report at bugs.python.org (paul j3)
Date: Fri, 09 Sep 2011 23:26:49 +0000
Subject: [issue12954] Multiprocessing logging under Windows
Message-ID: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>


New submission from paul j3 :

The Windows programming guidelines for the multiprocessing module documentation should include a warning that any logging initialization should be protected by the 'if __name__' block.  Otherwise you will get duplicate logging entries for the child processes.  This is because the multiprocessing.forking.prepare() function explicitly calls log_to_stderr(), and may implicitly do so again when it imports the parent module, resulting in duplicate logging handlers.

----------
assignee: docs at python
components: Documentation
messages: 143815
nosy: docs at python, paul.j3
priority: normal
severity: normal
status: open
title: Multiprocessing logging under Windows

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 01:41:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Sep 2011 23:41:00 +0000
Subject: [issue12763] test_posix failure on OpenIndiana
In-Reply-To: <1313517544.51.0.534780325686.issue12763@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 9ef10328180b by Jesus Cea in branch 'default':
Yet another fix for #12763: test_posix failure on OpenIndiana
http://hg.python.org/cpython/rev/9ef10328180b

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 01:45:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 09 Sep 2011 23:45:06 +0000
Subject: [issue12941] add random.pop()
In-Reply-To: <1315527061.03.0.145475351113.issue12941@psf.upfronthosting.co.za>
Message-ID: <1315611906.66.0.38777350339.issue12941@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee:  -> rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 01:48:56 2011
From: report at bugs.python.org (Tim Chase)
Date: Fri, 09 Sep 2011 23:48:56 +0000
Subject: [issue12940] Cmd example using turtle left vs. right doc-bug
In-Reply-To: <1315526692.9.0.379869372006.issue12940@psf.upfronthosting.co.za>
Message-ID: <1315612136.73.0.924023219993.issue12940@psf.upfronthosting.co.za>


Tim Chase  added the comment:

Patch attached.

----------
keywords: +patch
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23123/issue12940.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 01:53:45 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 09 Sep 2011 23:53:45 +0000
Subject: [issue12945] ctypes works incorrectly with _swappedbytes_ = 1
In-Reply-To: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>
Message-ID: <1315612425.17.0.10708941867.issue12945@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I can reproduce this on Fedora 15 with the Python tip revision.  I am investigating the behavior now.

----------
nosy: +meadori
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 01:57:30 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 09 Sep 2011 23:57:30 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1315604520.38.0.546764937836.issue11457@psf.upfronthosting.co.za>
Message-ID: 


Alexander Belopolsky  added the comment:

On Fri, Sep 9, 2011 at 5:42 PM, Larry Hastings  wrote:
..
> How is this superior to using either Decimal or float128?

It is explicit about the units of time used.  If we use named tuples
and retain C API field names, stat_result.tv_atimespec.tv_sec will
clearly mean number of seconds and stat_result.tv_atimespec.tv_nsec
will clearly mean nanoseconds.  Even if we use plain tuples, the
convention will be obvious to someone familiar with C API.  And
familiarity with C API is expected from users of os module, IMO.
Those who need higher level abstractions should use higher level
modules.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 02:02:08 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 10 Sep 2011 00:02:08 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1315606694.82.0.804335826955.issue11457@psf.upfronthosting.co.za>
Message-ID: 


Alexander Belopolsky  added the comment:

On Fri, Sep 9, 2011 at 6:18 PM, Larry Hastings  wrote:
..
> I've drawn an ASCII table summarizing the proposals so far.

You did not mention "closely matches C API" as an upside.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 02:20:53 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 10 Sep 2011 00:20:53 +0000
Subject: [issue11812] transient socket failure to connect to 'localhost'
In-Reply-To: <1302386214.84.0.811032327589.issue11812@psf.upfronthosting.co.za>
Message-ID: <1315614053.58.0.385314776377.issue11812@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

I am seeing this failure from time to time in OpenIndiana buildbots. For instance http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/1751/steps/test/logs/stdio

Seems a clear race condition.

----------
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 02:59:16 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Sep 2011 00:59:16 +0000
Subject: [issue12914] Add cram function to textwrap
In-Reply-To: <1315326488.16.0.0777914338919.issue12914@psf.upfronthosting.co.za>
Message-ID: <1315616356.43.0.430711740157.issue12914@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 03:05:42 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 10 Sep 2011 01:05:42 +0000
Subject: [issue12807] Optimizations for {bytearray,bytes,unicode}.strip()
In-Reply-To: <1313981941.49.0.99491814096.issue12807@psf.upfronthosting.co.za>
Message-ID: <1315616742.52.0.33768250384.issue12807@psf.upfronthosting.co.za>


John O'Connor  added the comment:

Moved {l,r,}strip to stringlib as well as the bloom filters from unicodeobject. I think it cleans things up nicely. Now there is one implementation for all 3 types. This patch also improves performance for bytearray and slightly for bytes. I see no delta for unicodeobject.

Added a test case for the mistake I made before (returning inc ref for mutable type).

grep -R couldn't find any other references to _PyUnicode_XStrip so I removed it. Though, someone with better knowledge of this should confirm.

----------
Added file: http://bugs.python.org/file23124/stringlib_strip.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 03:06:30 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 10 Sep 2011 01:06:30 +0000
Subject: [issue12807] Optimizations for {bytearray,bytes,unicode}.strip()
In-Reply-To: <1313981941.49.0.99491814096.issue12807@psf.upfronthosting.co.za>
Message-ID: <1315616790.42.0.454009063148.issue12807@psf.upfronthosting.co.za>


Changes by John O'Connor :


Removed file: http://bugs.python.org/file22982/strip_perf.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 03:16:09 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Sep 2011 01:16:09 +0000
Subject: [issue12914] Add cram function to textwrap
In-Reply-To: <1315326488.16.0.0777914338919.issue12914@psf.upfronthosting.co.za>
Message-ID: <1315617369.24.0.01721818804.issue12914@psf.upfronthosting.co.za>


Raymond Hettinger  added the comment:

A few thoughts:
* no one has ever made a request for this
* different people may want to do it in different ways 
  (the formulas are hard-wired).
* the '...' connector is hardwired
  (perhaps ' ... ' would look less odd).
* we should have a preference for keeping APIs small
  (more to learn and remember)
* this is dirt simple string processing and not hard
  for people to roll their own if the need arises
* if the API were to be expanded, perhaps it should
  be as a part of a focuses, thoughtful effort to
  provide a more generic set of text formatting
  transformations perhaps modeled on deep experiences
  with similar modules in other languages.
  (as opposed to piecemeal additions that weren't 
  designed with a coherent vision).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 03:36:58 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 10 Sep 2011 01:36:58 +0000
Subject: [issue12950] multiprocessing "test_fd_transfer" fails under
	OpenIndiana
In-Reply-To: <1315594559.68.0.697746063648.issue12950@psf.upfronthosting.co.za>
Message-ID: <1315618618.25.0.874785307161.issue12950@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

This failure happens only in 32 bits, not in 64 bits. I suspect a alignment issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 04:04:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Sep 2011 02:04:17 +0000
Subject: [issue12950] multiprocessing "test_fd_transfer" fails under
	OpenIndiana
In-Reply-To: <1315594559.68.0.697746063648.issue12950@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 1fde7cf94c76 by Jesus Cea in branch 'default':
Close #12950: multiprocessing "test_fd_transfer" fails under OpenIndiana
http://hg.python.org/cpython/rev/1fde7cf94c76

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 04:09:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Sep 2011 02:09:22 +0000
Subject: [issue12950] multiprocessing "test_fd_transfer" fails under
	OpenIndiana
In-Reply-To: <1315594559.68.0.697746063648.issue12950@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset cd15473a9de2 by Jesus Cea in branch '2.7':
Close #12950: multiprocessing "test_fd_transfer" fails under OpenIndiana
http://hg.python.org/cpython/rev/cd15473a9de2

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 04:14:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Sep 2011 02:14:11 +0000
Subject: [issue12950] multiprocessing "test_fd_transfer" fails under
	OpenIndiana
In-Reply-To: <1315594559.68.0.697746063648.issue12950@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 0f50b8379614 by Jesus Cea in branch '3.2':
Close #12950: multiprocessing "test_fd_transfer" fails under OpenIndiana
http://hg.python.org/cpython/rev/0f50b8379614

New changeset e37488e78cfa by Jesus Cea in branch 'default':
MERGE: Close #12950: multiprocessing "test_fd_transfer" fails under OpenIndiana
http://hg.python.org/cpython/rev/e37488e78cfa

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 05:35:54 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 10 Sep 2011 03:35:54 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1315625754.18.0.729093960257.issue6560@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 07:01:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Sep 2011 05:01:06 +0000
Subject: [issue12951] List behavior is different
In-Reply-To: <1315596544.14.0.783397700321.issue12951@psf.upfronthosting.co.za>
Message-ID: <1315630866.23.0.59831138628.issue12951@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

I don't see where is the bug.  If you do
>>> lists = [[]] * 3
>>> lists
[[], [], []]

you are creating a list that contains 3 references to the same list, as you can see here:
>>> lists[0] is lists[1] is lists[2]
True
>>> [id(l) for l in lists]
[33714832, 33714832, 33714832]

so if you append an element to either of the inner list, it will show up 3 times, because the 3 lists are really the same object:
>>> lists[0].append(3)
>>> lists
[[3], [3], [3]]

However, if you do
>>> lists[0] = 1
>>> lists
[1, [3], [3]]

you are replacing the first element of 'lists' with the int 1.  This doesn't mutate the inner list, and therefore the second and third elements are not affected.

See also http://python.net/crew/mwh/hacks/objectthink.html

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 07:04:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Sep 2011 05:04:29 +0000
Subject: [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1315631069.45.0.649409923066.issue12902@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

> "Warning: gathering the results for the topic 'modules' can take
> considerable time and have side effects as it imports *every* module
> available to get at its doc string."

http://docs.python.org/documenting/style.html#affirmative-tone

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 07:19:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Sep 2011 05:19:53 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za>
Message-ID: <1315631993.18.0.544312385343.issue12913@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

FWIW I almost always use "print" for debugging, and find the use of a real debugger overkill in Python in most of the cases.  People coming from other languages often feel the need of using a debugger because that's what works best with the other languages, but it's not necessarily true for Python.

I'm not sure focusing on pdb is the best idea then.  While it should be mentioned and a quick overview should be presented, a more extensive guide should probably go alongside the pdb doc, or possibly in a pdb-specific howto.

Mentioning unittest and coverage as a way to find errors earlier might also be a good idea (and reply to the "it's easier to debug compiled code because if I do something wrong the compiler gives me an error immediately" argument).

But all this might not be what you had in mind :)
I'm wondering if, for this kind of work, it's better to set up a clone with the document and its outline, in order to allow different persons to work on it before pushing it.  Rietveld works well for corrections, but a clone is better if you actually want to add something (and faster if you want to make corrections).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 08:45:38 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Sat, 10 Sep 2011 06:45:38 +0000
Subject: [issue12920] inspect.getsource fails to get source of local classes
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1315637138.51.0.831615515882.issue12920@psf.upfronthosting.co.za>


Popa Claudiu  added the comment:

I forgot to mention that I executed this code directly in IDLE. It seems to work perfectly on command line though.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 09:13:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Sep 2011 07:13:31 +0000
Subject: [issue12940] Cmd example using turtle left vs. right doc-bug
In-Reply-To: <1315526692.9.0.379869372006.issue12940@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 1ab62d3b96d2 by Ezio Melotti in branch '3.2':
#12940: fix cmd example.  Patch by Tim Chase.
http://hg.python.org/cpython/rev/1ab62d3b96d2

New changeset b239b7d9f752 by Ezio Melotti in branch 'default':
#12940: merge with 3.2.
http://hg.python.org/cpython/rev/b239b7d9f752

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 09:15:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Sep 2011 07:15:38 +0000
Subject: [issue12940] Cmd example using turtle left vs. right doc-bug
In-Reply-To: <1315526692.9.0.379869372006.issue12940@psf.upfronthosting.co.za>
Message-ID: <1315638938.3.0.76825942814.issue12940@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Fixed, thanks for the report and the patch!
2.7 doesn't have the example, so there's nothing to fix there.

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 09:16:47 2011
From: report at bugs.python.org (Vlada Peric)
Date: Sat, 10 Sep 2011 07:16:47 +0000
Subject: [issue12942] Shebang line fixer for 2to3
In-Reply-To: <1315531684.56.0.727993232351.issue12942@psf.upfronthosting.co.za>
Message-ID: <1315639007.2.0.606062450727.issue12942@psf.upfronthosting.co.za>


Changes by Vlada Peric :


----------
nosy: +VPeric

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 09:31:42 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sat, 10 Sep 2011 07:31:42 +0000
Subject: [issue12926] tarfile tarinfo.extract*() broken with symlinks
In-Reply-To: <1315389851.08.0.471880114138.issue12926@psf.upfronthosting.co.za>
Message-ID: <1315639902.02.0.0454008522642.issue12926@psf.upfronthosting.co.za>


Changes by Lars Gust?bel :


----------
assignee:  -> lars.gustaebel

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 10:41:46 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 10 Sep 2011 08:41:46 +0000
Subject: [issue12951] List behavior is different
In-Reply-To: <1315596544.14.0.783397700321.issue12951@psf.upfronthosting.co.za>
Message-ID: <1315644106.76.0.629323275184.issue12951@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc  added the comment:

See also http://docs.python.org/faq/programming.html#how-do-i-create-a-multidimensional-list

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 11:56:50 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 10 Sep 2011 09:56:50 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315595961.81.0.0519329031613.issue12936@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

> No such luck. Somehow gdb doesn't dump the core file:

What do
$ /sbin/sysctl -a | grep "kernel.core"

And
$ grep core /etc/security/limits.conf

return?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 12:30:28 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Sat, 10 Sep 2011 10:30:28 +0000
Subject: [issue12955] urllib2.build_opener().open() is not friendly to "with
	... as:"
Message-ID: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>


New submission from Valery Khamenya :

The following intuitive construction

with urllib2.build_opener().open() as:
    ...

leads to AttributeError: addinfourl instance has no attribute '__exit__'

http://docs.python.org/library/urllib2.html says almost nothing about concept of closing.

Could it be possible to add a canonical "with ... as:" example for urllib2.build_opener() ?

Thanks,
Valery

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 143836
nosy: Valery.Khamenya, docs at python
priority: normal
severity: normal
status: open
title: urllib2.build_opener().open() is not friendly to "with ... as:"
type: resource usage
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  Sat Sep 10 12:52:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Sep 2011 10:52:53 +0000
Subject: [issue12955] urllib2.build_opener().open() is not friendly to "with
	... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1315651973.5.0.844909413129.issue12955@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti, orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 13:37:53 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 10 Sep 2011 11:37:53 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315654673.75.0.582889626979.issue11457@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

[about adding float128]
> I realize a new float type would be a major undertaking

That's an understatement and a half.  The only way this could ever be viable is if float128 support becomes widespread enough that we don't have to write our own algorithms for basic float128 operations;  even then, it would still be a massive undertaking.  MPFR provides these operations, but it's LGPL.

I don't see this happening in the forseeable future.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 16:09:03 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 10 Sep 2011 14:09:03 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>
Message-ID: <1315663743.93.0.350468152138.issue12927@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I see what is going on.  I don't think the 'libffi' code can be executed correctly when built by 'suncc'.  The code currently requires '__attribute__((regparm(1)))', which AFAICT is not implemented by 'suncc';  only 'gcc'.

Take a look at 'ffi_closure_SYSV_inner' in 'Modules/_ctypes/libffi/src/x86/ffi.c':

void FFI_HIDDEN ffi_closure_raw_SYSV (ffi_raw_closure *)
     __attribute__ ((regparm(1)));

...

/* This function is jumped to by the trampoline */

unsigned int FFI_HIDDEN
ffi_closure_SYSV_inner (closure, respp, args)
     ffi_closure *closure;
     void **respp;
     void *args;
{
  /* our various things...  */
  ffi_cif       *cif;
  void         **arg_area;

  cif         = closure->cif;
  arg_area    = (void**) alloca (cif->nargs * sizeof (void*));

The '__attribute__ ((regparm(1)))' causes the first parameter to be passed in a register and the rest of the parameters to be spilled to the stack.  For most (all?) x86 compilers, '%eax' is the first register used to pass parameters when the calling convention requires registers.

'suncc' ignores this attribute (you can see warnings by greping the build logs) and expects 'closure' to be on the stack where as the trampoline code puts it in '%eax'.  This causes a bogus 'closure' and a huge value for 'cif->nargs', which overflows the stack with 'alloca'.

If you build Python on OpenSolaris with 'gcc' (pkg install gcc-dev), then everything works fine.  Does 'libffi' claim to support Solaris Studio?  If not, then this can be closed.

Also see issue1544339.  This issue was run into there as well (although no one ever really diagnosed it).

----------
nosy: +meadori

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 16:30:02 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 10 Sep 2011 14:30:02 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>
Message-ID: <1315665002.65.0.487096713031.issue12927@psf.upfronthosting.co.za>


Meador Inge  added the comment:

According to the latest release notes (https://github.com/atgreen/libffi/blob/master/README) the Solaris compiler should be supported for building:

3.0.10 Aug-23-11
        Add support for Apple's iOS.
        Add support for ARM VFP ABI.
        Add RTEMS support for MIPS and M68K.
        Fix instruction cache clearing problems on
        ARM and SPARC.
        Fix the N64 build on mips-sgi-irix6.5.
        Enable builds with Microsoft's compiler.
        Enable x86 builds with Oracle's Solaris compiler.
        Fix support for calling code compiled with Oracle's Sparc
        Solaris compiler.
        Testsuite fixes for Tru64 Unix.
        Additional platform support.

So 'x86' builds work with 'suncc', but I guess no runtime testing was performed, which is consistent with (http://www.moxielogic.org/wiki/index.php?title=Libffi_3.0.11).  I will open a bug with 'libffi'.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 17:05:15 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 10 Sep 2011 15:05:15 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315667115.87.0.425260281028.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

This is slightly embarrassing: The partition containing the qemu images
was full. I don't encounter this often, so it tends to be the last thing
I think of.

Proudly presenting a core dump. Since the segfault occurs in
libpthread, I suggest we close this. What do you think?


gdb ./python ./build/test_python_2217/core


Core was generated by `./python -m test -uall -r --randseed=8304772'.
Program terminated with signal 11, Segmentation fault.
[New process 2217]
#0  0x400356f4 in raise () from /lib/libpthread.so.0
(gdb) bt
#0  0x400356f4 in raise () from /lib/libpthread.so.0
#1  0x400356d8 in raise () from /lib/libpthread.so.0
Backtrace stopped: frame did not save the PC
(gdb)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 17:55:14 2011
From: report at bugs.python.org (LMO)
Date: Sat, 10 Sep 2011 15:55:14 +0000
Subject: [issue12956] 2.7.2 build fails with --enable-framework and space in
	pathname on OS X 10.7.1
Message-ID: <1315670114.35.0.572946657302.issue12956@psf.upfronthosting.co.za>


Changes by LMO :


----------
components: Build
nosy: rzn8tr
priority: normal
severity: normal
status: open
title: 2.7.2 build fails with --enable-framework and space in pathname on OS X 10.7.1
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 18:43:23 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 10 Sep 2011 16:43:23 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>
Message-ID: <1315673003.04.0.63739010716.issue12927@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Nice debugging work! I compiled --with-system-ffi and there the
issue seems fixed.

Do we have a libffi-3.0.10 release candidate in Modules/_ctypes?
The README says libffi-3.0.10, but the last commit for ffi.c was
17 months ago:

http://hg.python.org/cpython/log/b239b7d9f752/Modules/_ctypes/libffi/src/x86/ffi.c

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 18:43:29 2011
From: report at bugs.python.org (Bryce Verdier)
Date: Sat, 10 Sep 2011 16:43:29 +0000
Subject: [issue12301] Use :data:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1315673009.47.0.10092179038.issue12301@psf.upfronthosting.co.za>


Bryce Verdier  added the comment:

No worries, I totally understand. I was working on it a little bit at a time, as life would allow. And being probably more thorough than I needed to be. Here is the patch of everything that I've accomplished. Hope this helps.

----------
keywords: +patch
Added file: http://bugs.python.org/file23125/issue-12031.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 19:08:35 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Sep 2011 17:08:35 +0000
Subject: [issue12914] Add cram function to textwrap
In-Reply-To: <1315326488.16.0.0777914338919.issue12914@psf.upfronthosting.co.za>
Message-ID: <1315674515.52.0.492518915268.issue12914@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

This pretty well summarizes my vague feelings. I originally used a size 30 in my example, getting 'This sentence...made available' and then realized that it was a complete accident that I got complete words. If anything were made publicly available, I might like a more sophisticated algorithm. I think other things in pydoc are more worth of consideration. So I am now -.5 or more and would not mind closing this one of the four new pydoc exposure issues.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 22:15:25 2011
From: report at bugs.python.org (Michael Schurter)
Date: Sat, 10 Sep 2011 20:15:25 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1315685725.79.0.571931900001.issue6560@psf.upfronthosting.co.za>


Changes by Michael Schurter :


----------
nosy: +schmichael

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 22:24:19 2011
From: report at bugs.python.org (Michael Schurter)
Date: Sat, 10 Sep 2011 20:24:19 +0000
Subject: [issue12957] mmap.resize changes memory address of mmap'd region
Message-ID: <1315686259.57.0.0304440203891.issue12957@psf.upfronthosting.co.za>


New submission from Michael Schurter :

Since mmap.resize uses MREMAP_MAYMOVE on Linux, it would be nice to warn users that pointers into their memory mapped regions will be invalid after resizes. Linux's manpage offers the following explanation:

"If the mapping is relocated, then absolute pointers into the old mapping location become invalid (offsets relative to the starting address of the mapping should be employed)."

Since the only way I know of to use pointers into mmaps from pure Python is to use ctypes..from_buffer(), perhaps clarification would be better in the ctypes docs.

----------
assignee: docs at python
components: Documentation
files: killctypes.py
messages: 143845
nosy: docs at python, schmichael
priority: normal
severity: normal
status: open
title: mmap.resize changes memory address of mmap'd region
type: feature request
versions: Python 2.7
Added file: http://bugs.python.org/file23126/killctypes.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 10 23:19:43 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 10 Sep 2011 21:19:43 +0000
Subject: [issue12957] mmap.resize changes memory address of mmap'd region
In-Reply-To: <1315686259.57.0.0304440203891.issue12957@psf.upfronthosting.co.za>
Message-ID: <1315689583.69.0.00278566344799.issue12957@psf.upfronthosting.co.za>


Changes by Alex Gaynor :


----------
nosy: +alex

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 03:39:50 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Sep 2011 01:39:50 +0000
Subject: [issue12880] ctypes: clearly document how structure bit fields are
	allocated
In-Reply-To: <1314930851.91.0.112444630543.issue12880@psf.upfronthosting.co.za>
Message-ID: <1315705190.08.0.552679997097.issue12880@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Another example of desperately needed documentation: issue12945.

----------
components: +ctypes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 03:41:10 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Sep 2011 01:41:10 +0000
Subject: [issue12945] ctypes works incorrectly with _swappedbytes_ = 1
In-Reply-To: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>
Message-ID: <1315705270.28.0.473539835897.issue12945@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Pavel, I looked into to this a little more and have some ideas.  First off, '_swappedbytes_' is an undocumented implementation detail that is used to implement the LittleEndianStructure and BigEndianStructure types.  So using it directly like that is not expected to work.  If you want to change the endianity of the layout, then use LittleEndianStructure or BigEndianStructure instead.

Next, consider your test case when removing '_swappedbytes_' and using a LittleEndianStructure.  I am using a Linux hosted Python which lays out the structures in a manner similar to GCC.  This gives a layout like:

 ---------------------------------------
 | unsigned short   | unsigned short   |
 ---------------------------------------
 | bbbbaaaa cccccccc dddddddd ........ |
 ---------------------------------------
 | 00010010 00110100 01010110 01111000 |
 ---------------------------------------

'a', 'b', and 'c' all get "expanded" into one 'unsigned short'.  Then 'd' has to go in an 'unsigned short' as well leaving one byte left over with don't cares.

Similarly, the big endian layout looks like:

 ---------------------------------------
 | unsigned short   | unsigned short   |
 ---------------------------------------
 | aaaabbbb cccccccc dddddddd ........ |
 ---------------------------------------
 | 00010010 00110100 01010110 01111000 |
 ---------------------------------------

All of this is really a roundabout way of saying that the documentation for ctypes structure layout stinks.  issue12880 has been opened to fix it.

Does this seem reasonable to you?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 03:51:30 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Sep 2011 01:51:30 +0000
Subject: [issue12927] test_ctypes: segfault with suncc
In-Reply-To: <1315399514.93.0.967789977585.issue12927@psf.upfronthosting.co.za>
Message-ID: <1315705890.56.0.194927187654.issue12927@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I am not sure, but it does seem that way considering the most recent libffi says that 3.0.10 was released on Aug-23-11.  What is the process for updating libffi anyway?

Also, I posted a question concerning the Solaris Studio support on libffi-discuss: http://sourceware.org/ml/libffi-discuss/2011/msg00185.html.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 03:54:59 2011
From: report at bugs.python.org (Pavel Boldin)
Date: Sun, 11 Sep 2011 01:54:59 +0000
Subject: [issue12945] ctypes works incorrectly with _swappedbytes_ = 1
In-Reply-To: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>
Message-ID: <1315706099.33.0.741676552645.issue12945@psf.upfronthosting.co.za>


Pavel Boldin  added the comment:

Yes. Thanks. But here is another error:

import ctypes


class X(ctypes.Structure):
    _pack_ = 1
    _fields_ = [
        ('a', ctypes.c_ubyte, 4),
        ('b', ctypes.c_ubyte, 4),
        ('c', ctypes.c_ushort, 4),
        ('d', ctypes.c_ushort, 12),
    ]

buf = '\x12\x34\x56\x78'
x = X.from_buffer_copy(buf)

print X.a
print X.b
print X.c
print X.d

print x.a == 2
print x.b == 1
print x.c == 4
print x.d == 0x563


Prints (python 2.7.1):
True
True
True
False

Can you reproduce this?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 04:59:22 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Sep 2011 02:59:22 +0000
Subject: [issue12945] ctypes works incorrectly with _swappedbytes_ = 1
In-Reply-To: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>
Message-ID: <1315709962.11.0.107021310865.issue12945@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Yes I can.  This seems strange, but it is correct.  The little endian case look like:

 Little endian
 ---------------------------------------
 | unsigned short   | unsigned short   |
 ---------------------------------------
 | bbbbaaaa ....cccc dddddddd ....dddd |
 ---------------------------------------
 | 00010010 00110100 01010110 01111000 |
 ---------------------------------------

where the 'd' bits pack from left to right, so '1000 01010110'.
The big endian case look like:

 Big endian
 ---------------------------------------
 | unsigned short   | unsigned short   |
 ---------------------------------------
 | aaaabbbb cccc.... dddddddd dddd.... |
 ---------------------------------------
 | 00010010 00110100 01010110 01111000 |
 ---------------------------------------

where the 'd' bits pack from right to left, so '01010110 0111'.

The native case (Structure) can typically be verified using your host C compiler.  For example, the above code can be represented in C as:

#include 

struct T
{
  unsigned char  a : 4;
  unsigned char  b : 4;
  unsigned short c : 4;
  unsigned short d : 12;
};

int main (int argc, char **argv)
{
  unsigned char bytes[] = {0x12, 0x34, 0x56, 0x78};
  struct T *t = (struct T*)&bytes;

  printf ("%X\n", t->a);
  printf ("%X\n", t->b);
  printf ("%X\n", t->c);
  printf ("%X\n", t->d);
}

With respect to structure layout, ctypes typically behaves the same way as the native compiler used to build the interpreter.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 05:01:59 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Sep 2011 03:01:59 +0000
Subject: [issue12881] ctypes: segfault with large structure field names
In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za>
Message-ID: <1315710119.93.0.304449758854.issue12881@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Ping.  Any thoughts on this one?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 05:08:13 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Sep 2011 03:08:13 +0000
Subject: [issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
In-Reply-To: <1309741000.66.0.461732700198.issue12483@psf.upfronthosting.co.za>
Message-ID: <1315710493.4.0.262804882595.issue12483@psf.upfronthosting.co.za>


Meador Inge  added the comment:

This patch seems reasonable, is consistent with the GC docs, and passed all regression tests.  Can someone apply?

----------
nosy: +amaury.forgeotdarc, belopolsky, meadori
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 06:33:50 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Sep 2011 04:33:50 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1315715630.79.0.504455104366.issue12943@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Patch against tip.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +needs review, patch
nosy: +docs at python
stage: needs patch -> patch review
Added file: http://bugs.python.org/file23127/issue12943.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 07:40:43 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Sep 2011 05:40:43 +0000
Subject: [issue12958] test_socket failures on Mac OS X
Message-ID: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>


New submission from Nick Coghlan :

Several of the new socket tests introduced in #6560 are failing on the Mac OS X buildbots. These appear to be due to platform problems rather than anything in the test suite or the new sendmsg/recvmsg code, but it would be good if a developer on Mac OS X could take a closer look at them.

To avoid polluting the buildbot results, the affected tests will be flagged as expected failures when run on Mac OS X (this isn't in the repo yet, but once it is, the tests will be marked with "anticipate_failure" in the test_socket code).

----------
components: Library (Lib)
messages: 143854
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: test_socket failures on Mac OS X
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 07:46:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Sep 2011 05:46:03 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1315719963.84.0.939128805516.issue6560@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

Closing the feature request as complete. The remaining Mac OS X buildbot issues now have their own tracker item: #12958

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> test_socket failures on Mac OS X

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 10:28:29 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Sep 2011 08:28:29 +0000
Subject: [issue12914] Add cram function to textwrap
In-Reply-To: <1315326488.16.0.0777914338919.issue12914@psf.upfronthosting.co.za>
Message-ID: <1315729709.39.0.763519525279.issue12914@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 10:31:22 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Sep 2011 08:31:22 +0000
Subject: [issue12917] Make visiblename and allmethods functions public
In-Reply-To: <1315326868.85.0.0340726084847.issue12917@psf.upfronthosting.co.za>
Message-ID: <1315729882.16.0.465799403494.issue12917@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 10:32:01 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Sep 2011 08:32:01 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za>
Message-ID: <1315729921.76.0.983251453779.issue12916@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 10:49:24 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Sep 2011 08:49:24 +0000
Subject: [issue12958] test_socket failures on Mac OS X
In-Reply-To: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>
Message-ID: <1315730964.2.0.230772745398.issue12958@psf.upfronthosting.co.za>


Changes by Ned Deily :


----------
nosy: +ned.deily

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 10:57:52 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Sep 2011 08:57:52 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315731472.92.0.724402984472.issue1172711@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I left some remarks on Rietveld.

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 10:58:17 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Sep 2011 08:58:17 +0000
Subject: [issue7798] Make generally useful pydoc functions public
In-Reply-To: <1264692401.66.0.0955816094505.issue7798@psf.upfronthosting.co.za>
Message-ID: <1315731497.33.0.249911567169.issue7798@psf.upfronthosting.co.za>


Raymond Hettinger  added the comment:

Resist the urge to fatten APIs until you're sure that:
* they are needed
* they are well developed (many internal utils fail this test)
* they are worth the extra time it takes to learn what is in a module (adding rarely needed tools has the side-effect of obscuring things people actually need)

Georg's advice is spot on.  There are a lot of little internal routines in the standard library that aren't sufficiently fit to be exposed (perhaps a little too ad-hoc or special purpose, perhaps the API isn't sufficiently general, perhaps the routines rely on non-guaranteed aspects of the implementation).  For example, visiblename() is more heuristic than algorithmic -- right now, we can change that as needed (for instance, the recent updates to accommodate named tuples), but as soon as the method or function becomes public, its API freezes and it is hard for us to make changes.

The pager functions are interesting and non-trivial.  Before making them public in the standard library though, it would be best if it had some life as third-party module to let it mature (i.e. making sure it works as well in other contexts as it does in pydoc).

Also consider whether other documentation tools have already encountered and addressed these use cases, perhaps in a different and better way.

----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 11:23:41 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Sep 2011 09:23:41 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315733021.07.0.507054711917.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Traceback with faulthandler disabled:

Core was generated by `./python -m test -uall -r --randseed=8304772'.
Program terminated with signal 11, Segmentation fault.
[New process 3948]
#0  0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2
(gdb) bt
#0  0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2
#1  0x40011d10 in __tls_get_addr () from /lib/ld-linux.so.2
Backtrace stopped: frame did not save the PC

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 11:47:32 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 11 Sep 2011 09:47:32 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315734452.05.0.347869649706.issue12936@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> Traceback with faulthandler disabled:

It crashes when trying to look up TLS (which explains why it doesn't crash when built ``without-threads`).
Looks like a libc bug, but would it be possible to have a backtrace with Python built with `with-pydebug`?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 13:12:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Sep 2011 11:12:32 +0000
Subject: [issue12958] test_socket failures on Mac OS X
In-Reply-To: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>
Message-ID: <1315739552.33.0.175621675746.issue12958@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

First attempt didn't quite work - the FD passing tests somehow seem to be reporting both 'ERROR' *and* 'expected failure', which is causing the test overall to remain red.

http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%20custom/builds/41/steps/test/logs/stdio

----------
hgrepos: +67

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 14:17:44 2011
From: report at bugs.python.org (Pavel Boldin)
Date: Sun, 11 Sep 2011 12:17:44 +0000
Subject: [issue12945] ctypes works incorrectly with _swappedbytes_ = 1
In-Reply-To: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>
Message-ID: <1315743464.59.0.4682150092.issue12945@psf.upfronthosting.co.za>


Pavel Boldin  added the comment:

OK. So, it seems just like ctypes work, but don't for my needs.

Thing that bothers me anyway is the strange code, where size contains either size (when bitsize==0) or bitsize in upper 16 bits and bitoffset in lower 16 bits.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 14:34:27 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 11 Sep 2011 12:34:27 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315744467.84.0.889138662187.issue12936@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
nosy: +meadori

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 14:34:46 2011
From: report at bugs.python.org (July Tikhonov)
Date: Sun, 11 Sep 2011 12:34:46 +0000
Subject: [issue12959] Add 'ChainMap' to collections.__all__
Message-ID: <1315744486.33.0.835466042574.issue12959@psf.upfronthosting.co.za>


New submission from July Tikhonov :

ChainMap is the only item from collections module, that is described in docs, but is not included in collections.__all__

----------
components: Library (Lib)
files: chainmap_in___all__.diff
keywords: patch
messages: 143862
nosy: july
priority: normal
severity: normal
status: open
title: Add 'ChainMap' to collections.__all__
type: feature request
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23128/chainmap_in___all__.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 14:54:03 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 11 Sep 2011 12:54:03 +0000
Subject: [issue12958] test_socket failures on Mac OS X
In-Reply-To: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>
Message-ID: <1315745643.15.0.72256341154.issue12958@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

Ah, I believe I see why the expected failure isn't working properly - the failing testFDPass* tests are causing the subsequent tear down code to also fail.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 15:37:19 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 11 Sep 2011 13:37:19 +0000
Subject: [issue12960] threading.Condition is not a class
Message-ID: <1315748239.01.0.928739848932.issue12960@psf.upfronthosting.co.za>


New submission from Nikolaus Rath :

According to http://docs.python.org/library/threading.html#condition-objects, threading.Condition is a class. However, in fact it turns out to be function that constructs a _Condition instance.

I don't know the reason for that, but it seems to me that either Condition should be a class, or the reason for it being a function should be documented so that people who I would like to inherit from Conditionknow if that is not supported, or if they can safely inherit from _Condition instead.

----------
assignee: docs at python
components: Documentation
messages: 143864
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: threading.Condition is not a class
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 15:40:29 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 11 Sep 2011 13:40:29 +0000
Subject: [issue12704] Language References does not specify exception raised by
	final yield()
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1315748429.85.0.0847589785263.issue12704@psf.upfronthosting.co.za>


Changes by Nikolaus Rath :


----------
versions: +Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 15:53:24 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Sep 2011 13:53:24 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315749204.76.0.39098685124.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Curiously enough python *is* built --with-pydebug.


Version 9d658f000419, which is pre-faulthandler, runs without segfaults.


Could faulthandler cause problems like these:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370060

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 16:21:54 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 11 Sep 2011 14:21:54 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315750914.89.0.495142360946.issue11457@psf.upfronthosting.co.za>


Larry Hastings  added the comment:

Mark Dickinson:
> > I realize a new float type would be a major undertaking

> That's an understatement and a half.  The only way this could ever
> be viable is if float128 support becomes widespread enough that we
> don't have to write our own algorithms for basic float128 operations

As I mentioned earlier in this thread, GCC has supported __float128 since 4.3, Clang added support within the last year, and Intel has a _Quad type.  All are purported to be IEEE 754-2008 quad-precision floats.  Glibc added "quadmath.h" recently (maybe in 4.6), which defines sinq() / tanq() / etc.  Is that not sufficient?

The Windows compilers don't seem to support a float128 yet.  But Windows only supports 100ns resolution for mtime/atime anyway.  The bad news: according to my back-of-the-envelope calcuations, doubles will stop accurately representing 100ns timestamps in less than a year; they'll lose another bit of precision somewhere around 2019.


Alexander Belopolsky
> > How is this superior to using either Decimal or float128?

> It is explicit about the units of time used.  

Why is that a feature?  I'd rather that was abstracted away for me, like the os module currently does.


> And familiarity with C API is expected from users of os module, IMO.

As you say, that's your opinion.  But I've never heard of that as an official policy.  Therefore it is irrelevant as a design constraint for the API.


> > I've drawn an ASCII table summarizing the proposals so far.

> You did not mention "closely matches C API" as an upside.

By "C API", you mean "the POSIX-2008 compatible C API".  This would not match
 * POSIX platforms that don't meet the 2008 spec
 * Windows
 * Java
 * CLR
all of which are supported platforms for Python.

The documentation for the os module states:
"This module provides a portable way of using operating system dependent functionality. [...] The design of all built-in operating system dependent modules of Python is such that as long as the same functionality is available, it uses the same interface"

Since "the most recent modification time / access time of a file" is available on all platforms Python supports, it follows that Python should use the same interface to represent it on all those platforms.  Tying the representation to that of one particular platform is therefore poor API design, particularly when there are representations that abstract away such details within easy reach.

So I don't consider it a compelling upside--in fact I consider it a disadvantage.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 16:24:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Sep 2011 14:24:47 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315751087.77.0.228046849364.issue11457@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

"As I mentioned earlier in this thread, GCC has supported __float128 since 4.3, Clang added support within the last year, and Intel has a _Quad type.  All are purported to be IEEE 754-2008 quad-precision floats.  Glibc added "quadmath.h" recently (maybe in 4.6), which defines sinq() / tanq() / etc.  Is that not sufficient?"

Python is compiled using Visual Studio 2008 on Windows. Portability does matter on Python. If a type is not available on *all* platforms (including some old platforms, e.g. FreeBSD 6 or Windows XP), we cannot use it by default.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 16:50:03 2011
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 11 Sep 2011 14:50:03 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315752603.64.0.416678411165.issue11457@psf.upfronthosting.co.za>


Larry Hastings  added the comment:

Victor STINNER:
> Python is compiled using Visual Studio 2008 on Windows. Portability
> does matter on Python. If a type is not available on *all* platforms
> (including some old platforms, e.g. FreeBSD 6 or Windows XP), we
> cannot use it by default.

The quad-precision float would be highly portable, but not 100% guaranteed.  The idea is that st_mtime would be a float128 on a recent Linux, but still a double on Windows.  Python's "duck typing", combined with a judicious implementation of float128, would permit code that performed simple math on a timestamp to run unchanged.  That should be sufficient for almost all existing code that deals with these timestamps.

But there are obvious, plausible scenarios where this would break.  For example: pickling a float128 mtime on one platform and attempting to unpickle it on Windows.  I can imagine legitimate reasons why one would want to ship ctime/atime/mtime across platforms.

If that's an unacceptable level of portability, then for the proposal to remain viable we'd have to implement our own portable quad-precision floating point type.  That's a staggering amount of work, and I doubt it would happen.  But short of some quad-precision type, there's no way to preserve existing code and have it get more precise automatically.

If float128 isn't viable then the best remaining option is Decimal.  But changing st_mtime to Decimal would be an even more violent change than changing it to float was.  I propose adding the Decimal fields "ctime", "atime", and "mtime" to the named tuple returned by os.stat().

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 17:07:05 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 11 Sep 2011 15:07:05 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315753625.28.0.563122143844.issue12936@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> Could faulthandler cause problems like these:

Well, that would explain why it crashes in the TLS lookup code, and why the core dump looks borked.

1) Apparently, Etch on ARM uses linuxthread instead of NPTL: what does
$ getconf GNU_LIBPTHREAD_VERSION
return on your box?

2) If it's using linxthreads, the culprit is likely the call to PyGILState_GetThisThreadState() from faulthandler_fatal_error(), which does a TLS lookup (which screws up because it's running in a user-allocated stack allocated with sigaltstack).
However, this should only happen when a a fatal signal is handled by faulthandler, which should - AFAICT - only happen in test_faulthandler.

Rebuilding faulthandler with
#undef HAVE_SIGALTSTACK

at the top of the file, should do the trick.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 17:20:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 11 Sep 2011 15:20:03 +0000
Subject: [issue12881] ctypes: segfault with large structure field names
In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za>
Message-ID: <1315754403.05.0.920915809576.issue12881@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

Looks good to me.

----------
nosy: +neologix
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 18:08:36 2011
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Sep 2011 16:08:36 +0000
Subject: [issue12956] 2.7.2 build fails with --enable-framework and space in
	pathname on OS X 10.7.1
Message-ID: <1315757316.68.0.219297921497.issue12956@psf.upfronthosting.co.za>


New submission from Ned Deily :

gcc -o Python.framework/Versions/2.7/Python   -dynamiclib \
		-all_load libpython2.7.a -Wl,-single_module \
		-install_name /tmp/a/empty space/Python.framework/Versions/2.7/Python \
		-compatibility_version 2.7 \
		-current_version 2.7;
i686-apple-darwin11-llvm-gcc-4.2: space/Python.framework/Versions/2.7/Python: No such file or directory

----------
assignee:  -> ned.deily
components: +Macintosh
nosy: +ned.deily
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 18:55:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Sep 2011 16:55:42 +0000
Subject: [issue12959] Add 'ChainMap' to collections.__all__
In-Reply-To: <1315744486.33.0.835466042574.issue12959@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 12bb3cd873c8 by Benjamin Peterson in branch 'default':
add ChainMap to __all__ (closes #12959)
http://hg.python.org/cpython/rev/12bb3cd873c8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 19:17:02 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 11 Sep 2011 17:17:02 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1315752603.64.0.416678411165.issue11457@psf.upfronthosting.co.za>
Message-ID: <4E6CED0B.2030304@v.loewis.de>


Martin v. L?wis  added the comment:

> The quad-precision float would be highly portable

Larry, please stop this discussion in this issue. I believe
a PEP would be needed, and would likely be rejected because
of the very very very long list of issues that can't be
resolved. I think you seriously underestimate the problems.
Please trust Mark on this.

For example, gcc doesn't support __float128 in 32-bit mode
on x86.

> If float128 isn't viable then the best remaining option is Decimal.
> But changing st_mtime to Decimal would be an even more violent change
> than changing it to float was.  I propose adding the Decimal fields
> "ctime", "atime", and "mtime" to the named tuple returned by
> os.stat().

That sounds reasonable to me. While we are at it, I'd rename
"ctime" to "creationtime" on Windows, to prevent people from
believing it is "ctime" (i.e. inode change time).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 20:55:28 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 11 Sep 2011 18:55:28 +0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1315767328.83.0.686919482125.issue1230540@psf.upfronthosting.co.za>


Changes by Nikolaus Rath :


----------
nosy: +Nikratio

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 22:01:51 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Sun, 11 Sep 2011 20:01:51 +0000
Subject: [issue12961] unlabelled balls in boxes
Message-ID: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>


New submission from Phillip Feldman :

The current set of combinatorial functions in `itertools` does not include unlabelled balls in labeled boxes and unlabelled balls in unlabelled boxes.  If the boxes have no capacity limits (i.e., can store an unlimited number of balls), then the unlabelled balls in labelled boxes can be handled with existing tools.  But, this is a special case.  Various people have developed working Python implementations for the "unlabelled balls in labelled boxes with capacity limits" problem.  I believe that "unlabelled balls in unlabelled boxes with capacity limits" can be handled with a minor variation on the same algorithm.  It would be a great benefit to have this capability in `itertools`.

----------
messages: 143874
nosy: Phillip.M.Feldman, rhettinger
priority: normal
severity: normal
status: open
title: unlabelled balls in boxes
type: feature request
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 22:02:53 2011
From: report at bugs.python.org (dirn)
Date: Sun, 11 Sep 2011 20:02:53 +0000
Subject: [issue12853] global name 'r' is not defined in upload.py
In-Reply-To: <1314637700.16.0.440169429003.issue12853@psf.upfronthosting.co.za>
Message-ID: <1315771373.57.0.477542890658.issue12853@psf.upfronthosting.co.za>


dirn  added the comment:

Replacing r with result works only when urlopen doesn't raise HTTPError

----------
nosy: +dirn

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 22:12:38 2011
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 11 Sep 2011 20:12:38 +0000
Subject: [issue12958] test_socket failures on Mac OS X
In-Reply-To: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>
Message-ID: <1315771958.34.0.266354693269.issue12958@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 22:57:00 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 11 Sep 2011 20:57:00 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1315774620.9.0.984860934607.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda :


Added file: http://bugs.python.org/file23129/fe2c9998f329.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 23:01:35 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 11 Sep 2011 21:01:35 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1315774895.34.0.584313822087.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

I've attached another patch (fe2c9998f329.diff) with a more complete
implementation of the lzma module. All that's left now is to write the
documentation, and make sure that the module can build on Windows.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 11 23:06:29 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 11 Sep 2011 21:06:29 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315775189.36.0.333013294125.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I completely removed faulthandler from e91ad9669c08 and the problem
still occurs (with the same broken backtrace).

$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.7


It is a bit unsatisfying that the segfault isn't reproducible with
the earlier revision, but there are several glibc issues with
__tls_get_addr():


1) http://www.cygwin.com/ml/libc-hacker/2008-10/msg00005.html
2) http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453


If I run the demo script from 2), I get a segfault both on
debian-arm as well as on Ubuntu Lucid.

So, it may very well be that some recent change in Python exposes a
glibc problem.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 00:07:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Sep 2011 22:07:15 +0000
Subject: [issue12306] zlib: Expose zlibVersion to query runtime version of zlib
In-Reply-To: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset b21d1de6d78e by Nadeem Vawda in branch 'default':
Issue #12306: Add ZLIB_RUNTIME_VERSION to the zlib module.
http://hg.python.org/cpython/rev/b21d1de6d78e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 00:13:10 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Sun, 11 Sep 2011 22:13:10 +0000
Subject: [issue12306] zlib: Expose zlibVersion to query runtime version of zlib
In-Reply-To: <1307667064.6.0.30417035015.issue12306@psf.upfronthosting.co.za>
Message-ID: <1315779190.61.0.934520110206.issue12306@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

I've committed your patches. I took the liberty of removing the
"versionadded" tag for ZLIB_VERSION; I don't think many people will need
to worry about compatibility with Python 1.5 ;-)

Once again, thanks for the patches!

----------
assignee:  -> nadeem.vawda
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 01:39:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Sep 2011 23:39:58 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315784398.3.0.64380905424.issue12936@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> Looks like a libc bug ...
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453

Yes, the GNU libc has bugs (as every software!): this one has been fixed only recently (in glibc 2.14, released the 2011-05-31). I don't know if this issue is a duplicate of glibc bug 12453.

> Could faulthandler cause problems ...

faulthandler creates two locks at startup. faulthandler.enable() (e.g. called by regrtest when running the the test suite) creates a thread and changes the signal mask of this thread (to ignore all signals).

I don't see how faulthandler can be linked to this issue, but yes, it might be the linked to this issue.

In your case, faulthandler only reads a TLS on a crash. So faulthandler is not the cause of the initial crash, but it may cause a new fault :-)


--

> Apparently, Etch on ARM uses linuxthread instead of NPTL ...

FYI you can also try to print sys.thread_info (which should give the same information, "NPTL 2.7").

NPTL has know issues: see for example the Python issue #4970. NPTL is old and has been replaced by pthread in the glibc on Linux.

--

> Traceback with faulthandler disabled: ...

How did you disabled faulthandler?

--

> Version 9d658f000419, which is pre-faulthandler, runs without segfaults.

If it's a regression, you must try hg bisect! It is slow but it is fully automated! Try something like:

hg bisect -r
hg bisect -b 9d658f000419
hg bisect -c 'make && ./python -m test test_urllib2_localnet test_robotparser test_nntplib'

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 01:56:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Sep 2011 23:56:09 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315785369.77.0.698740163881.issue11457@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> If a two-ints representation
> is considered necessary, I'd favor a rational number (numerator,
> denominator) over a pair (second, subsecond); this would also support
> 2**-32 fractions (as used in NTP !!!).

Which OS uses NTP timestamps in stat()? Or are you thinking about other functions?

> As yet another approach, I propose a set of st_[cma]time_nsec fields
> which always give an int representing the integral part of the time
> stamp in nanoseconds since the epoch.

As I wrote before, I would prefer to keep the same number of fields in the Python structure and in the C structure, but I don't have a strong opinion on this choice. If we want to stay close the C API, we can use a namedtuple:

s = os.stat(filename, time_struct=True)
ctime = s.ctime.tv_sec + ctime + s.ctime.tv_nsec * 1-e9

Or maybe:

s = os.stat(filename, time_struct=True)
ctime = s.ctime.sec + ctime + s.ctime.nsec * 1-e9

A namedtuple is not a good idea if we want to support other time resolutions, because some developer may write "s.ctime[0] + ctime + s.ctime[1]" without taking care of the time resolution.

Because Windows uses a resolution of 100 ns and POSIX uses 1 ns, I still don't see why we should support something else. If we use the following API, we can still add other resolutions later (using a new argument):

s = os.stat(filename, nanoseconds=True)
sec, nsec = s.ctime
ctime = sec + nsec * 1e-9

What should be done if the OS only has a resolution of 1 sec? Raise an exception, or use nsec=0? Same question if we add *_nsec fields: these fields are optional, or always present?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 05:19:42 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Sep 2011 03:19:42 +0000
Subject: [issue12945] ctypes works incorrectly with _swappedbytes_ = 1
In-Reply-To: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>
Message-ID: <1315797582.73.0.621653295159.issue12945@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Would you mind explaining your use case and why ctypes won't fit it?  Maybe there is something that can be fixed.

FWIW, I agree that the overloading of 'size' is unnecessary.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 06:21:47 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Sep 2011 04:21:47 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1315801307.26.0.443126030817.issue7201@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I ran the ctypes tests on Debian GNU/Linux 5.0.8 (lenny) on an ARMv5tejl 
Versatile kernel and everything passed.  Is anyone else still seeing 
errors?

----------
assignee: theller -> 
nosy: +meadori -theller

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 06:30:51 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Sep 2011 04:30:51 +0000
Subject: [issue12959] Add 'ChainMap' to collections.__all__
In-Reply-To: <1315744486.33.0.835466042574.issue12959@psf.upfronthosting.co.za>
Message-ID: <1315801851.04.0.857549469222.issue12959@psf.upfronthosting.co.za>


Raymond Hettinger  added the comment:

Thank you.

----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 08:08:26 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 12 Sep 2011 06:08:26 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1315785369.77.0.698740163881.issue11457@psf.upfronthosting.co.za>
Message-ID: <4E6DA1D8.9010908@v.loewis.de>


Martin v. L?wis  added the comment:

> As I wrote before, I would prefer to keep the same number of fields
> in the Python structure and in the C structure, but I don't have a
> strong opinion on this choice.

I'm with Larry - exposing time fields as structured records is
hostile to the programmer. It is a true pain in C to do any
meaningful computation on timeval or timespec values. It may
be a little more convenient in Python, but we should really
attempt to expose the time stamps as single fields that support
arithmetics and string conversion, else people will hate
us for 500 years (or when we next need to revise this struct).

Nothing is *gained* by exposing structured time. People may see
it as an advantage that this closely matches the POSIX spec, but
all it does in reality is to confront people with platform differences
for no true gain.

> s = os.stat(filename, nanoseconds=True) sec, nsec = s.ctime ctime =
> sec + nsec * 1e-9
>
> What should be done if the OS only has a resolution of 1 sec? Raise
> an exception, or use nsec=0? Same question if we add *_nsec fields:
> these fields are optional, or always present?

If we declare that stat_result has nanosecond resolution, then
it should have that even on systems that only support second
resolution (or 2-second resolution, like FAT).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 08:59:36 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 12 Sep 2011 06:59:36 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315784398.3.0.64380905424.issue12936@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

> 2) http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453

We actually had another issue due to this particular libc bug:

http://bugs.python.org/issue6059

Basically, the problem is that if some libraries are dynamically
loaded in an interleaved way, the TLS can be returned uninitialized,
hence the segfault upon access.
This problem can show up now because the import orders for some
modules have been modified: depending on the test that crashes - or
rather the tests that run just before - you might be able to pinpoint
it quickly (or you could maybe use "ltrace -e dlopen").

>> Apparently, Etch on ARM uses linuxthread instead of NPTL ...
>
> FYI you can also try to print sys.thread_info (which should give the same information, "NPTL 2.7").
>
> NPTL has know issues: see for example the Python issue #4970. NPTL is old and has been replaced by pthread in the glibc on Linux.

I think you're confusing with linuxthreads ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 09:13:36 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 12 Sep 2011 07:13:36 +0000
Subject: [issue12800] 'tarfile.StreamError: seeking backwards is not allowed'
	when extract symlink
In-Reply-To: <1313881060.54.0.449889075101.issue12800@psf.upfronthosting.co.za>
Message-ID: <1315811616.56.0.157451500718.issue12800@psf.upfronthosting.co.za>


Changes by Lars Gust?bel :


----------
assignee:  -> lars.gustaebel

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 09:18:14 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 12 Sep 2011 07:18:14 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315811894.69.0.444382287679.issue12936@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

Oh, and BTW, for the "Backtrace stopped: frame did not save the PC", you might want to install the libc-dbg package. This might help in finding precisely where it's crashing.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 09:27:10 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 12 Sep 2011 07:27:10 +0000
Subject: [issue12962] TitledHelpFormatter and IndentedHelpFormatter are not
	documented
Message-ID: <1315812430.81.0.82881222836.issue12962@psf.upfronthosting.co.za>


New submission from anatoly techtonik :

In optparse module doc this two classes are referenced, but not documented:

http://docs.python.org/library/optparse.html

----------
components: Library (Lib)
messages: 143888
nosy: techtonik
priority: normal
severity: normal
status: open
title: TitledHelpFormatter and IndentedHelpFormatter are not documented
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 09:57:34 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Sep 2011 07:57:34 +0000
Subject: [issue12881] ctypes: segfault with large structure field names
In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za>
Message-ID: <1315814254.56.0.360537835079.issue12881@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc  added the comment:

Note that there is at least one other place where alloca() is used with potentially large values: the POINTER() function in callproc.c.
Also, PyUnicode_FromFormat could be used instead of sprintf.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 10:25:05 2011
From: report at bugs.python.org (Alan Hourihane)
Date: Mon, 12 Sep 2011 08:25:05 +0000
Subject: [issue10898] posixmodule.c redefines FSTAT
In-Reply-To: <1294857148.96.0.548396285489.issue10898@psf.upfronthosting.co.za>
Message-ID: <1315815905.51.0.0339234739245.issue10898@psf.upfronthosting.co.za>


Changes by Alan Hourihane :


----------
resolution: accepted -> remind

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 10:36:11 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Sep 2011 08:36:11 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315784398.3.0.64380905424.issue12936@psf.upfronthosting.co.za>
Message-ID: <20110912083312.GA15987@sleipnir.bytereef.org>


Stefan Krah  added the comment:

STINNER Victor  wrote:
> > Traceback with faulthandler disabled: ...
> 
> How did you disabled faulthandler?

That was a run with all faulthandler references removed from regrtest.py.

But as I said in my previous mail, I also did a run using e91ad9669c08
but without compiling and linking faulthandler, so that _PyFaulthandler_Init()
wouldn't be called. This had the same result, so faulthandler is _not_ the cause
of this bug.

> > Version 9d658f000419, which is pre-faulthandler, runs without segfaults.
> 
> If it's a regression, you must try hg bisect! It is slow but it is fully automated! Try something like:
> 
> hg bisect -r
> hg bisect -b 9d658f000419
> hg bisect -c 'make && ./python -m test test_urllib2_localnet test_robotparser test_nntplib'

If it were that easy! I can't isolate the bug. The only way I can reproduce it
is by running the whole test suite with various random seeds. Then it takes
about 6 hours until the crash occurs in one of those tests.

The whole test suite takes about 24 hours.

I could try to install libc-dbg though.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 11:44:45 2011
From: report at bugs.python.org (Pavel Boldin)
Date: Mon, 12 Sep 2011 09:44:45 +0000
Subject: [issue12945] ctypes works incorrectly with _swappedbytes_ = 1
In-Reply-To: <1315576489.44.0.807779711581.issue12945@psf.upfronthosting.co.za>
Message-ID: <1315820685.75.0.812226938091.issue12945@psf.upfronthosting.co.za>


Pavel Boldin  added the comment:

We have raw data packages from some tools. These packages contains bitfields, arrays, simple data and so on.

We want to parse them into Python objects (structures) for analysis and storage. I tried to use ctypes, but now I wrote myself implementation of raw parser based on bitarray and struct.

I wonder if ctypes can do this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 13:48:28 2011
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Sep 2011 11:48:28 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1315828108.74.0.595990917598.issue11715@psf.upfronthosting.co.za>


Christian Heimes  added the comment:

Hey Nick and Barry,

the fix in http://hg.python.org/cpython/rev/bd0f73a9538e isn't sufficient. You have added /usr/lib/MULTIARCH and /usr/include/MULTIARCH but you forgot to add /lib/MULTIARCH. On my system zlib is installed at /lib/x86_64-linux-gnu/libz.so.

----------
nosy: +christian.heimes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 13:55:24 2011
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 12 Sep 2011 11:55:24 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1315828524.83.0.215737505013.issue11715@psf.upfronthosting.co.za>


Christian Heimes  added the comment:

Update:

It turns out that zlib1g-dev adds a symlink from /usr/lib/x86_64-linux-gnu/libz.so to /lib/x86_64-linux-gnu/libz.so.1 .

$ locate libz.
/lib/x86_64-linux-gnu/libz.so.1
/lib/x86_64-linux-gnu/libz.so.1.2.3.4
/usr/lib/x86_64-linux-gnu/libz.a
/usr/lib/x86_64-linux-gnu/libz.so

Perhaps this symlink is missing on Nick's installation. It might be a wise idea to add /lib/MULTIARCH to the library search paths, too.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:10:13 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Sep 2011 12:10:13 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1315829413.2.0.530868416285.issue7201@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> I ran the ctypes tests on Debian GNU/Linux 5.0.8 (lenny) on an ARMv5tejl 
> Versatile kernel and everything passed.

I believe the problem is specific to machines still using the old ABI ('OABI').  Which ABI was being used on your test machine? (Not sure how to tell, but there's more information about the ABIs at:

http://wiki.debian.org/ArmEabiPort

)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:13:36 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Sep 2011 12:13:36 +0000
Subject: [issue12961] unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1315829616.46.0.627999561225.issue12961@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> "unlabelled balls in unlabelled boxes with capacity limits"

What does this mean?  If the boxes are unlabelled, how can they have individual capacity limits?  Or do you mean just a single limit that applies to all boxes?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:13:46 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Sep 2011 12:13:46 +0000
Subject: [issue12963] PyLong_AsSize_t returns (unsigned long)-1
Message-ID: <1315829626.88.0.38210073004.issue12963@psf.upfronthosting.co.za>


New submission from Stefan Krah :

In one of the error branches PyLong_AsSize_t() returns (unsigned long)-1
instead of (size_t)-1.

----------
components: Interpreter Core
files: pylong_as_size_t.diff
keywords: patch
messages: 143896
nosy: mark.dickinson, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: PyLong_AsSize_t returns (unsigned long)-1
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23130/pylong_as_size_t.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:21:39 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Sep 2011 12:21:39 +0000
Subject: [issue12961] unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1315830099.6.0.740710568857.issue12961@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> "unlabelled balls in labelled boxes with capacity limits"

Out of curiosity, what was the application that you needed this for?

This one feels a bit too specialized to me to be worth adding to the itertools library;  I see itertools more as providing a collection of general-purpose tools that the user can combine for specific situations, and it's easy to do the above with itertools.combinations plus some filtering of the results to satisfy the capacity constraints.  Admittedly, that's less-efficient than a custom-built recursive solution.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:30:42 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Sep 2011 12:30:42 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1315830642.06.0.33751446811.issue11457@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> I propose adding the Decimal fields "ctime", "atime", and "mtime" to the > named tuple returned by os.stat().

That would be an interesting precedent:  I don't think there are many (any?) other places outside the 'decimal' module that deal with Decimal objects (excluding general purpose serialization protocols and the like).

Decimal's support for conversion to-and-from float (and comparison with float) is stronger than it used to be; I think this could work.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:34:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Sep 2011 12:34:06 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1301435300.88.0.0418449859461.issue11715@psf.upfronthosting.co.za>
Message-ID: <1315830846.3.0.572626850371.issue11715@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

It wouldn't surprise me at all if the laptop's links were a little off - I started with a Kubuntu image off VMWare's site quite some time ago, then dist-upgraded it through a couple of releases as they came out.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:35:55 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 12 Sep 2011 12:35:55 +0000
Subject: [issue12963] PyLong_AsSize_t returns (unsigned long)-1
In-Reply-To: <1315829626.88.0.38210073004.issue12963@psf.upfronthosting.co.za>
Message-ID: <1315830955.65.0.206806493471.issue12963@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Yep, clearly a bug.  Please fix!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:37:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Sep 2011 12:37:00 +0000
Subject: [issue12963] PyLong_AsSize_t returns (unsigned long)-1
In-Reply-To: <1315829626.88.0.38210073004.issue12963@psf.upfronthosting.co.za>
Message-ID: <1315831020.14.0.0908002878769.issue12963@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

I suppose that you can test if the bug is tested on Windows 64 bits, where sizeof(long)=32 bits, whereas sizeof(size_t) is 64 bits.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:41:27 2011
From: report at bugs.python.org (Sinisa Segvic)
Date: Mon, 12 Sep 2011 12:41:27 +0000
Subject: [issue12964] Two improvements for the locale aliasing engine
Message-ID: <1315831287.41.0.402878841254.issue12964@psf.upfronthosting.co.za>


New submission from Sinisa Segvic :

Hi,

There appears to be some space for improvement
regarding the stable implementation
of the Python locale aliasing engine.

Sometimes, one wishes to be able
to override the default system locale.
For instance, it would be nice that a program
supposed to sort people according to national rules
would be able to run correctly even when the system
does not default to the national locale.

Judging from the Python manuals and
provided the desired national locale is installed,
this should be doable in at least the following two ways:

import locale
ianaLanguageSubtag='en'       # the desired national locale
locale.setlocale(locale.LC_ALL,
  (ianaLanguageSubtag, locale.getpreferredencoding())) #(1)
locale.setlocale(locale.LC_ALL,
  locale.normalize(ianaLanguageSubtag))                #(2)


For a quicker reference, this is
the relevant part of the manual:
http://docs.python.org/release/3.2/library/locale.html
'''
locale.setlocale(category, locale=None)
  ...
  If (the locale) is a tuple, it is converted
  to a string using the locale aliasing engine.
  ...
'''

The locale aliasing engine binds
the IANA language subtags to POSIX locales.
Its effects can be directly observed
through locale.normalize:
>>> import locale
>>> locale.normalize('hr')
'hr_HR.ISO8859-2'
>>> locale.normalize('en')
'en_US.ISO8859-1'


My first objection concerns the Windows behaviour
of the calls (1) and (2) above.
Both of the two calls *do not work* since Windows
does not recognize strings such as 'en_US.ISO8859-1'.
Instead, Windows provides their own locale nomenclature:
http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.80%29.aspx
Consequently, the following *works*:

locale.setlocale(locale.LC_ALL, 'English_United States.1252')

IMHO this issue should be fixed, perhaps by providing
an alternate definition of the locale alias dictionary
(locale.locale_alias).


My second objection concerns the behaviour on Linux,
where the call (1) above always works,
while (2) in some cases might not work.
It happens that the call (2)
requests an outdated 8-bit encoding
although UTF8 has obtained a world-wide acceptance.
The call shall result in a locale error
whenever the desired national locale
is present only in the UTF8 variant.

This might be fixed by changing the encodings
in the locale.locale_alias from 8-bit variants to UTF8.
Note however that the problem could be circumvented
by issuing the call (1), so this would be
less important than the Windows fix proposed above.

Source code references:
  .../Python-3.2.2/Lib/locale.py
  locale.locale_alias
  locale.normalize
  locale.setlocale

comp.lang.python discussion:
  http://groups.google.com/group/comp.lang.python/browse_thread/thread/3591d496cf108ad2#

Cheers,

Sinisa

----------
components: Library (Lib), Windows
messages: 143902
nosy: ssegvic
priority: normal
severity: normal
status: open
title: Two improvements for the locale aliasing engine
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 14:46:44 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Sep 2011 12:46:44 +0000
Subject: [issue12964] Two improvements for the locale aliasing engine
In-Reply-To: <1315831287.41.0.402878841254.issue12964@psf.upfronthosting.co.za>
Message-ID: <1315831604.91.0.768096111851.issue12964@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +haypo, lemburg

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 16:27:49 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Sep 2011 14:27:49 +0000
Subject: [issue12963] PyLong_AsSize_t returns (unsigned long)-1
In-Reply-To: <1315829626.88.0.38210073004.issue12963@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset d14f717b5e3d by Stefan Krah in branch '3.2':
Issue #12963: PyLong_AsSize_t() now returns (size_t)-1 in all error cases.
http://hg.python.org/cpython/rev/d14f717b5e3d

New changeset c91900e4e805 by Stefan Krah in branch 'default':
Merge fix for issue #12963.
http://hg.python.org/cpython/rev/c91900e4e805

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 17:28:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 15:28:42 +0000
Subject: [issue12914] Add cram function to textwrap
In-Reply-To: <1315326488.16.0.0777914338919.issue12914@psf.upfronthosting.co.za>
Message-ID: <1315841322.51.0.396573375029.issue12914@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> if the API were to be expanded, perhaps it should be as a part of a
> focuse[d], thoughtful effort to provide a more generic set of text
> formatting transformations perhaps modeled on deep experiences with
> similar modules in other languages. (as opposed to piecemeal additions
> that weren't designed with a coherent vision).

That?s a very strong point.

Thanks for the opinions.

----------
stage:  -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 17:29:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 15:29:56 +0000
Subject: [issue12301] Use :role:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1315841396.85.0.51547370538.issue12301@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Thanks Bryce, I will start from your patch.  (BTW, you used func instead of data for sys.stdout.)

----------
stage: needs patch -> patch review
title: Use :data:`sys.thing` instead of ``sys.thing`` throughout -> Use :role:`sys.thing` instead of ``sys.thing`` throughout

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 17:35:46 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Sep 2011 15:35:46 +0000
Subject: [issue11715] Building Python on multiarch Debian and Ubuntu
In-Reply-To: <1315830846.3.0.572626850371.issue11715@psf.upfronthosting.co.za>
Message-ID: <20110912113539.04c0795f@resist.wooz.org>


Barry A. Warsaw  added the comment:

On Sep 12, 2011, at 12:34 PM, Nick Coghlan wrote:

>It wouldn't surprise me at all if the laptop's links were a little off - I
>started with a Kubuntu image off VMWare's site quite some time ago, then
>dist-upgraded it through a couple of releases as they came out.

I'll try to get a VM up with the latest Oneiric Kubuntu image and see what
happens.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 17:42:16 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Sep 2011 15:42:16 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset e5c1de856828 by ?ric Araujo in branch '3.2':
Fix determination of Metadata version (#8933).  Patch by Filip Gruszczy?ski.
http://hg.python.org/cpython/rev/e5c1de856828

New changeset 70298cdc48cd by ?ric Araujo in branch 'default':
Merge fix for #8933 from 3.2
http://hg.python.org/cpython/rev/70298cdc48cd

New changeset ca21a47b1ec2 by ?ric Araujo in branch 'default':
Fix determination of Metadata version in packaging (#8933).
http://hg.python.org/cpython/rev/ca21a47b1ec2

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 17:44:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 15:44:05 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za>
Message-ID: <1315842245.96.0.84652164585.issue12913@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

[Terry]
> If you write 'How to debug Python code' rather than just "How to use pdb",
That is my intention.

> I would start with the use of print statements
You, Ezio and I concur :)

> and binary search.
I?m not familiar with that term.  Is it hg bisect?

> Have short sections on using trace and profile.
I haven?t thought about these, thanks.

> Very useful would be a list of error messages and possible un-obvious
> to beginners but common causes.
These would be great additions to the programming FAQ, and my document could link to it.


[Ezio]
> People coming from other languages often feel the need of using a debugger because that's
> what works best with the other languages, but it's not necessarily true for Python.
I?ll be sure to make this clear, thanks.

> I'm not sure focusing on pdb is the best idea then.
My initial message did not do justice to my outline.  The part about pdb is probably the one that?ll take me more time, because I nearly don?t know it at all, but it won?t be the focus of the document.  A quick ?getting started with pdb? section is what I have in mind, something more newbie-level than the pdb module docs (which seem to assume basic knowledge of how a Unix debugger program works).

> Mentioning unittest and coverage as a way to find errors earlier might also be a good idea
Hadn?t though about coverage.  Will mention it and add a link to the devguide part that talks about it.

I don?t think I?ll have much time for this in the following few weeks, but as your replies appear to accept the idea, I will set up a clone to let us work on this.


Here?s my initial outline:

=== Introduction

- running a script in a terminal or IDLE
- getting a traceback (file and line)
- making sense of the exception message

=== Simple Troubleshooting Techniques

- print debugging
- using facilities provided by modules used
  - increasing logging verbosity
  - httplib.debuglevel
  - your web framework's debug helper
- going into interactive mode

* Using lint tools to catch mistakes early

- pyflakes first
- pylint -E
- pychecker?

* Getting more information out of failing tests

- using the most specialized methods to get diffs
- msg argument for boolean-returning methods
- print! suspend!  All is fair in debugging.

* Automating troubleshooting

- emacs/vim quickfix (mode that runs tests and open faulty files at the right line)


=== Using a Debugger

- pdb intro that does not duplicate what?s in library/pdb.rst
- definitions (breakpoint, etc.)


=== Debugging C code

(just a few pointers, this could have a whole howto in itself)

- running Python in gdb
- using faulthandler


Links to add somewhere: traceback module, cgitb

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 17:47:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 15:47:42 +0000
Subject: [issue12841] Incorrect tarfile.py extraction
In-Reply-To: <1314281834.23.0.939615944176.issue12841@psf.upfronthosting.co.za>
Message-ID: <1315842462.5.0.840970492653.issue12841@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I understand.  Unit tests can work with file permissions, ownership and links, but they can?t create different filesystems or ask for superuser rights.  test_shutil contains a few tests that purport to test cross-filesystems usage but may or may not actually do it (#9999).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 17:49:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Sep 2011 15:49:40 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 4b72d56cf42f by ?ric Araujo in branch '2.7':
Fix determination of Metadata version (#8933).  Patch by Filip Gruszczy?ski.
http://hg.python.org/cpython/rev/4b72d56cf42f

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 17:50:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 15:50:01 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1315842601.31.0.715539099763.issue12915@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Sorry if I was unclear; the functions work with a dotted name as a string and resolve it to an object.  __import__ works with module, whereas this kind of functions work with mod.name, pkg.mod.name.attr, etc., that is, they combine import and getattr.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 17:54:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 15:54:06 +0000
Subject: [issue12299] Stop documenting functions added by site as builtins
In-Reply-To: <1307636270.04.0.997555638345.issue12299@psf.upfronthosting.co.za>
Message-ID: <1315842846.31.0.359805273594.issue12299@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Agreed.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:00:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 16:00:30 +0000
Subject: [issue12917] Make visiblename and allmethods functions public
In-Reply-To: <1315326868.85.0.0340726084847.issue12917@psf.upfronthosting.co.za>
Message-ID: <1315843230.01.0.618575184856.issue12917@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Copied from msg143857:

> There are a lot of little internal routines in the standard library
> that aren't sufficiently fit to be exposed (perhaps a little too
> ad-hoc or special purpose, perhaps the API isn't sufficiently
> general, perhaps the routines rely on non-guaranteed aspects of the
> implementation).  For example, visiblename() is more heuristic than
> algorithmic -- right now, we can change that as needed (for instance,
> the recent updates to accommodate named tuples), but as soon as the
> method or function becomes public, its API freezes and it is hard for
> us to make changes.

I agree with your general point.  For this particular case, I?d be okay if you wanted to reject the request.  Users can filter the output of dir depending on their needs (_private names, __magic__ names, etc.).  For more useful code (that can cope with named tuples for example), I think generic functions would be a nice way to do this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:02:06 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Sep 2011 16:02:06 +0000
Subject: [issue12917] Make visiblename and allmethods functions public
In-Reply-To: <1315326868.85.0.0340726084847.issue12917@psf.upfronthosting.co.za>
Message-ID: <1315843326.6.0.568466033524.issue12917@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:05:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 16:05:23 +0000
Subject: [issue12917] Make visiblename and allmethods functions public
In-Reply-To: <1315326868.85.0.0340726084847.issue12917@psf.upfronthosting.co.za>
Message-ID: <1315843523.6.0.569400777416.issue12917@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

A precision:

> I think generic functions would be a nice way to do this.
I meant: a nice way to experiment this *outside of the stdlib*.  We don?t have official generic function yet, so I?ll wait to see if pprint gets rewritten and/or if we get a generic functions PEP and standard module.

Sorry if these issues I opened are consuming your time; I wanted to make sure we considered the proposals separately and add a good rationale for rejecting them.  Thanks for weighing in.

----------
stage:  -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:07:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 16:07:42 +0000
Subject: [issue12918] New module for terminal utilities
In-Reply-To: <1315327048.11.0.179720377155.issue12918@psf.upfronthosting.co.za>
Message-ID: <1315843662.39.0.634911011285.issue12918@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Copied from msg143857 (Raymond Hettinger):

> Resist the urge to fatten APIs until you're sure that:
> * they are needed
> * they are well developed (many internal utils fail this test)
> * they are worth the extra time it takes to learn what is in a module (adding rarely needed
> tools has the side-effect of obscuring things people actually need)
> [...]
> The pager functions are interesting and non-trivial.  Before making them public in the
> standard library though, it would be best if it had some life as third-party module to let
> it mature (i.e. making sure it works as well in other contexts as it does in pydoc).

I?m thus closing this request.  Someone can run with the idea, publish experiments on PyPI, gather feedback from python-ideas, and we?ll see about stdlib inclusion when the time is right.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:07:59 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Sep 2011 16:07:59 +0000
Subject: [issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
In-Reply-To: <1309741000.66.0.461732700198.issue12483@psf.upfronthosting.co.za>
Message-ID: <1315843679.58.0.959452979936.issue12483@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc  added the comment:

I was going to say that the patch has no visible effect, since PyObject_GC_Del() calls something which has the same effect as PyObject_GC_Untrack...
But the following code crashes the interpreter! And of course the patch fixes it...


import ctypes, gc
class Nasty:
    def __del__(self):
        gc.collect()

ctypes.CFUNCTYPE(None)(lambda x=Nasty(): None)
print("OK")

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:18:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 16:18:01 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1315844281.21.0.20462624304.issue8933@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

It was very easy to verify your patch: PEP 314 lists the new fields.

For packaging (distutils2), I thought the fix would be less easy: I believed that all fields in _314_MARKERS would cause i conflict if used together with 345 fields, but as it turns out they don?t.  I?ll leave it at that for now, but I really want to rework the best_version-related functions to make them easier to grasp.

Thanks for the patches and bumps!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:21:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 16:21:32 +0000
Subject: [issue5977] distutils build_ext.get_outputs returns wrong result
In-Reply-To: <1241875790.11.0.581973280056.issue5977@psf.upfronthosting.co.za>
Message-ID: <1315844492.23.0.519496374235.issue5977@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

The fix you committed uses an absolute path for the C sources, which is invalid: sources should contain relative paths only.

----------
versions:  -Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:24:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 12 Sep 2011 16:24:20 +0000
Subject: =?utf-8?q?=5Bissue9322=5D_Don=E2=80=99t_fail_silently_if_ext=5Fmodules_us?=
	=?utf-8?q?e_absolute_paths?=
In-Reply-To: <1279721130.09.0.919872519995.issue9322@psf.upfronthosting.co.za>
Message-ID: <1315844660.48.0.712879341264.issue9322@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I started to work on a simple patch but it makes one of our tests fail.  It uses absolute paths because it needs to change directory and check that get_outputs works.

----------
dependencies: +distutils build_ext.get_outputs returns wrong result
keywords: +patch
versions: +Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file23131/d1-ext-absolute-sources-9322.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:41:03 2011
From: report at bugs.python.org (Phillip M. Feldman)
Date: Mon, 12 Sep 2011 16:41:03 +0000
Subject: [issue12961] unlabelled balls in boxes
In-Reply-To: <1315829616.46.0.627999561225.issue12961@psf.upfronthosting.co.za>
Message-ID: 


Phillip M. Feldman  added the comment:

Hello Mark,

This is a fair question.  Suppose that I have three boxes with capacity
limits of 3, 2, and 1, and that there are three balls in total.  Two of the
possible distributions are the following:

2, 0, 1
2, 1, 0

Capacity limits of the individual boxes must be observed when distributing
the balls.  Even though the second and third boxes have different
capacities, we must treat the above two distributions of balls as
equivalent.

Combinatorics problems involving boxes with capacity limits arise in such
application domains as physics and reliability.

Phillip

On Mon, Sep 12, 2011 at 5:13 AM, Mark Dickinson wrote:

>
> Mark Dickinson  added the comment:
>
> > "unlabelled balls in unlabelled boxes with capacity limits"
>
> What does this mean?  If the boxes are unlabelled, how can they have
> individual capacity limits?  Or do you mean just a single limit that applies
> to all boxes?
>
> ----------
> nosy: +mark.dickinson
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
nosy: +Phillip.M.Feldman at gmail.com
Added file: http://bugs.python.org/file23132/unnamed

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
Hello Mark,

This is a fair question.?? Suppose that I have three boxes with capacity limits of 3, 2, and 1, and that there are three balls in total.?? Two of the possible distributions are the following:

2, 0, 1

2, 1, 0

Capacity limits of the individual boxes must be observed when distributing the balls.?? Even though the second and third boxes have different capacities, we must treat the above two distributions of balls as equivalent.


Combinatorics problems involving boxes with capacity limits arise in such application domains as physics and reliability.

Phillip

On Mon, Sep 12, 2011 at 5:13 AM, Mark Dickinson <report at bugs.python.org> wrote:




Mark Dickinson <dickinsm at gmail.com> added the comment:




> "unlabelled balls in unlabelled boxes with capacity limits"




What does this mean? ??If the boxes are unlabelled, how can they have individual capacity limits? ??Or do you mean just a single limit that applies to all boxes?



----------

nosy: +mark.dickinson




_______________________________________

Python tracker <report at bugs.python.org>

<http://bugs.python.org/issue12961>

_______________________________________





From report at bugs.python.org  Mon Sep 12 18:46:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Sep 2011 16:46:14 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za>
Message-ID: <1315845974.18.0.361355480391.issue12913@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Binary search with print is done manually. If error not obvious from quick read, in a 20 line function, add print around line 10. If ok there, look down and add print later in function. If not, look up and add print earlier in function. This is not exact at all, but quick reruns (F5 with IDLE) mean no need to load up entire function with prints (that will have to be removed again) all at once (as might do with compiled C 20 years ago). Same idea as binary search through revisions to find buildbot breaker. I am sure you know this, even if not by terms I used.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:57:50 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Sep 2011 16:57:50 +0000
Subject: [issue12965] longobject: documentation improvements
Message-ID: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>


New submission from Stefan Krah :

I think the integer objects documentation could be clearer on a
couple of points:

  - Despite being listed under "Concrete Objects Layer", some
    functions implicitly accept anything with an __int__()
    method. Currently only the PyLong_AsLong() documentation
    states this explicitly.

    The patch clearly distinguishes between functions that
    duck type and functions that don't. 

  - The patch replaces "is greater than *_MAX" instances with
    "out of bounds" to include the other error condition
    "is less than *_MIN".


Additionally, the patch fixes comments in longobject.c that
don't state the duck typing behavior.

----------
assignee: docs at python
components: Documentation
files: longobject-doc.diff
keywords: patch
messages: 143922
nosy: docs at python, mark.dickinson, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: longobject: documentation improvements
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23133/longobject-doc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 18:58:18 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Sep 2011 16:58:18 +0000
Subject: [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <1315846698.38.0.387830566935.issue12965@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
assignee: docs at python -> mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 19:25:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Sep 2011 17:25:19 +0000
Subject: [issue12301] Use :role:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1315848319.66.0.282955260186.issue12301@psf.upfronthosting.co.za>


Raymond Hettinger  added the comment:

It would be best to think about each of the new links individually rather than making blanket changes.   

The new links need to have relevance and add value to the topic; otherwise, they are just distractions from the more relevant links that had been placed there in a thoughtful manner.

For example, I don't think the docs are improved by turning every ``sys.stderr`` into a link.  How does that help users or does it just make the docs harder to read and obscure the move useful links.

----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 19:40:10 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Sep 2011 17:40:10 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1315829413.2.0.530868416285.issue7201@psf.upfronthosting.co.za>
Message-ID: 


Meador Inge  added the comment:

On Mon, Sep 12, 2011 at 7:10 AM, Mark Dickinson  wrote:

> Mark Dickinson  added the comment:
>
> I believe the problem is specific to machines still using the old ABI ('OABI'). ?Which ABI was being used on your test machine?

I tested the new ABI (armel).  I will try the old ABI.  However, after
reading over the ABI differences, the problems seem to be expected.
In particular:

"""
Struct packing and alignment

With the new ABI, default structure packing changes, as do some
default data sizes and alignment (which also have a knock-on effect on
structure packing). In particular the minimum size and alignment of a
structure was 4 bytes. Under the EABI there is no minimum and the
alignment is determined by the types of the components it contains.
This will break programs that know too much about the way structures
are packed and can break code that writes binary files by dumping and
reading structures.
"""

Once I get an OABI system up and running I will substantiate that
claim.  I don't think there is going to be a bug fix here as I don't
think it is practical to support both ABIs.  Just a "these tests are
expected to fail due to ABI differences x, y, z" kind of thing.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 20:12:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Sep 2011 18:12:09 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za>
Message-ID: <1315851129.95.0.90588997453.issue12913@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

More time: read outline, good start.
On syntax errors, IDLE put up message box and OK returns to window with apparent error hi-lited and cursor just after.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 20:26:13 2011
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 12 Sep 2011 18:26:13 +0000
Subject: [issue12301] Use :role:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1315851973.26.0.264458958612.issue12301@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

I agree.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 20:38:21 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 12 Sep 2011 18:38:21 +0000
Subject: [issue12939] Add new io.FileIO using the native Windows API
In-Reply-To: <1315523941.29.0.146575875409.issue12939@psf.upfronthosting.co.za>
Message-ID: <1315852701.09.0.712472585147.issue12939@psf.upfronthosting.co.za>


Changes by Santoso Wijaya :


----------
nosy: +santa4nt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:13:00 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Sep 2011 19:13:00 +0000
Subject: [issue12963] PyLong_AsSize_t returns (unsigned long)-1
In-Reply-To: <1315829626.88.0.38210073004.issue12963@psf.upfronthosting.co.za>
Message-ID: <1315854780.36.0.877377613669.issue12963@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

> Yep, clearly a bug.  Please fix!

Done, thanks for reviewing.


Victor, I don't think we need a unit test for this. I plan to go
over some modules with gcov in the future, and I'll include
longobject.c.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:14:40 2011
From: report at bugs.python.org (Paulie Pena)
Date: Mon, 12 Sep 2011 19:14:40 +0000
Subject: [issue12966] cookielib.LWPCookieJar breaks on cookie values with a
	newline
Message-ID: <1315854880.61.0.95908383563.issue12966@psf.upfronthosting.co.za>


New submission from Paulie Pena :

Even though RFC 6265's cookie-value's cookie-octet definition says that whitespace characters are not allowed (see http://tools.ietf.org/html/rfc6265), there are non-compliant web sites that send cookie values with newlines.  cookielib.LWPCookieJar will save the bad value in a cookie file, but when it tries to load it, it probably is only splitting by newlines, so it crashes on the invalid line.  The easiest thing would probably be to just ignore cookies that have values with a newline.  (Note: I'm using Python 2.5, so this might have been fixed in a later version.)

----------
components: Library (Lib)
messages: 143928
nosy: paulie4
priority: normal
severity: normal
status: open
title: cookielib.LWPCookieJar breaks on cookie values with a newline
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:20:20 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Sep 2011 19:20:20 +0000
Subject: [issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
In-Reply-To: <1309741000.66.0.461732700198.issue12483@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset eb9f566fd8db by Amaury Forgeot d'Arc in branch '2.7':
Issue #12483: ctypes: Fix a crash when the destruction of a callback
http://hg.python.org/cpython/rev/eb9f566fd8db

New changeset eae8e4ab0455 by Amaury Forgeot d'Arc in branch '3.2':
Issue #12483: ctypes: Fix a crash when the destruction of a callback
http://hg.python.org/cpython/rev/eae8e4ab0455

New changeset fe125a3fda54 by Amaury Forgeot d'Arc in branch 'default':
Merge 3.2: Issue #12483: ctypes: Fix a crash when the destruction of a callback
http://hg.python.org/cpython/rev/fe125a3fda54

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:35:40 2011
From: report at bugs.python.org (Jakob Malm)
Date: Mon, 12 Sep 2011 19:35:40 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1315856140.23.0.825968229426.issue8822@psf.upfronthosting.co.za>


Jakob Malm  added the comment:

I agree with Alexander -- I think the current documentation is sufficient to describe 'naive' and 'aware' date and time objects.

The sentence "There are two kinds of date and time objects: ?naive? and ?aware?." is perhaps a bit unfortunate, however. It appears that Anatoly had misinterpreted 'naive' and 'aware' objects to be of different Python types:

> 'naive' and 'aware' are key datetime types

Perhaps the sentence could be changed to something like:

"date and time objects are either 'naive' or 'aware'.

----------
nosy: +shaq

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:36:27 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 12 Sep 2011 19:36:27 +0000
Subject: [issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
In-Reply-To: <1309741000.66.0.461732700198.issue12483@psf.upfronthosting.co.za>
Message-ID: <1315856187.9.0.603734830271.issue12483@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Heh, I was just about to upload another patch with your test case.  Thanks for committing this Amaury.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:40:12 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Sep 2011 19:40:12 +0000
Subject: [issue12483] CThunkObject_dealloc should call PyObject_GC_UnTrack?
In-Reply-To: <1309741000.66.0.461732700198.issue12483@psf.upfronthosting.co.za>
Message-ID: <1315856412.38.0.997043093892.issue12483@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc  added the comment:

Thanks for your help! I fear they are many other places like this one in CPython code.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:49:45 2011
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 12 Sep 2011 19:49:45 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1315436467.8.0.570951848691.issue6560@psf.upfronthosting.co.za>
Message-ID: 


Bill Janssen  added the comment:

I'm guessing these things are due to interaction with some Apple
security update, as the buildbots were working well 8 months ago.

Bill

On Wed, Sep 7, 2011 at 4:01 PM, Nick Coghlan  wrote:
>
> Nick Coghlan  added the comment:
>
> If Bill gets a chance to investigate this before the weekend, great, otherwise my plan to stop making noise in the buildbot results will be to:
>
> 1. Create a separate issue specifically for the errors reported by the Mac OS X buildbots (allowing the problem to be spelled out more clearly for readers, and also allowing the feature request itself to be closed)
>
> 2. Flag the offending tests as expected failures on Mac OS X, with a pointer back to the new tracker issue.
>
> That way, if these failures are due to underlying OS bugs or limitations (as they appear to be), we'll get a clear indication in the buildbots when Apple have fixed the relevant problems.
>
> ----------
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:55:03 2011
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 12 Sep 2011 19:55:03 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315857303.94.0.891677568361.issue1172711@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I made the observation on Rietveld that the following code is never
executed by the test suite. The same applies to similar existing
passages in arraymodule.c:

http://bugs.python.org/review/1172711/diff/3310/10310#newcode394


Meador correctly pointed out that the code allows for duck typing.
But the struct module (and by extension memoryview that must follow
the struct module) don't:

>>> import array, struct
>>> a = array.array('L', [1,2,3])
>>> class T(object):
...     def __init__(self, value):
...         self.value = value
...     def __int__(self):
...          return self.value
...
>>> a = array.array('L', [1,2,3])
>>> struct.pack_into('L', a, 0, 9)
>>> a
array('L', [9, 2, 3])
>>> a[0] = T(100)
>>> a
array('L', [100, 2, 3])
>>> struct.pack_into('L', a, 0, T(200))
Traceback (most recent call last):
  File "", line 1, in 
struct.error: required argument is not an integer
>>>

I vastly prefer the struct module behavior. Since the code isn't executed
by any tests:

Is it really the intention for array to allow duck typing? The documentation
says:

"This module defines an object type which can compactly represent an array
 of basic values: characters, integers, floating point numbers."

"Basic value" doesn't sound to me like "anything that has an __int__() method".


Also, consider this:

>>> sum([T(1),T(2),T(3)])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for +: 'int' and 'T'

>>> sum(array.array('L', [T(1),T(2),T(3)]))
6

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 21:59:27 2011
From: report at bugs.python.org (Phillip M. Feldman)
Date: Mon, 12 Sep 2011 19:59:27 +0000
Subject: [issue12961] unlabelled balls in boxes
In-Reply-To: 
Message-ID: 


Phillip M. Feldman  added the comment:

Here's an example of a problem from an entirely different domain:

An error control coding scheme can correct up to 3 errors in the header of a
packet and up to one error in the body of a packet. A given message is
divided into four consecutive packets. Find all possible correctible
distributions of 6 errors among the four packets, treating the order of the
four packets as significant.

Phillip

On Mon, Sep 12, 2011 at 9:41 AM, Phillip M. Feldman
wrote:

>
> Phillip M. Feldman  added the comment:
>
> Hello Mark,
>
> This is a fair question.  Suppose that I have three boxes with capacity
> limits of 3, 2, and 1, and that there are three balls in total.  Two of the
> possible distributions are the following:
>
> 2, 0, 1
> 2, 1, 0
>
> Capacity limits of the individual boxes must be observed when distributing
> the balls.  Even though the second and third boxes have different
> capacities, we must treat the above two distributions of balls as
> equivalent.
>
> Combinatorics problems involving boxes with capacity limits arise in such
> application domains as physics and reliability.
>
> Phillip
>
> On Mon, Sep 12, 2011 at 5:13 AM, Mark Dickinson  >wrote:
>
> >
> > Mark Dickinson  added the comment:
> >
> > > "unlabelled balls in unlabelled boxes with capacity limits"
> >
> > What does this mean?  If the boxes are unlabelled, how can they have
> > individual capacity limits?  Or do you mean just a single limit that
> applies
> > to all boxes?
> >
> > ----------
> > nosy: +mark.dickinson
> >
> > _______________________________________
> > Python tracker 
> > 
> > _______________________________________
> >
>
> ----------
> nosy: +Phillip.M.Feldman at gmail.com
> Added file: http://bugs.python.org/file23132/unnamed
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
Added file: http://bugs.python.org/file23134/unnamed

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
Here's an example of a problem from an entirely different domain:

An error control coding scheme can correct up to 3 errors in the header of a packet and up to one error in the body of a packet. A given message is divided into four consecutive packets. Find all possible correctible distributions of 6 errors among the four packets, treating the order of the four packets as significant.


Phillip

On Mon, Sep 12, 2011 at 9:41 AM, Phillip M. Feldman <report at bugs.python.org> wrote:



Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:




Hello Mark,



This is a fair question. ??Suppose that I have three boxes with capacity

limits of 3, 2, and 1, and that there are three balls in total. ??Two of the

possible distributions are the following:



2, 0, 1

2, 1, 0



Capacity limits of the individual boxes must be observed when distributing

the balls. ??Even though the second and third boxes have different

capacities, we must treat the above two distributions of balls as

equivalent.



Combinatorics problems involving boxes with capacity limits arise in such

application domains as physics and reliability.



Phillip



On Mon, Sep 12, 2011 at 5:13 AM, Mark Dickinson <report at bugs.python.org>wrote:



>


> Mark Dickinson <dickinsm at gmail.com> added the comment:

>

> > "unlabelled balls in unlabelled boxes with capacity limits"

>

> What does this mean? ??If the boxes are unlabelled, how can they have

> individual capacity limits? ??Or do you mean just a single limit that applies

> to all boxes?

>

> ----------

> nosy: +mark.dickinson

>

> _______________________________________

> Python tracker <report at bugs.python.org>

> <http://bugs.python.org/issue12961>

> _______________________________________

>




----------

nosy: +Phillip.M.Feldman at gmail.com

Added file: http://bugs.python.org/file23132/unnamed




_______________________________________

Python tracker <report at bugs.python.org>

<http://bugs.python.org/issue12961>

_______________________________________



From report at bugs.python.org  Mon Sep 12 22:30:51 2011
From: report at bugs.python.org (Jakob Malm)
Date: Mon, 12 Sep 2011 20:30:51 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1315859451.71.0.36259273322.issue8822@psf.upfronthosting.co.za>


Jakob Malm  added the comment:

I created a patch with the revised wording.

----------
keywords: +patch
Added file: http://bugs.python.org/file23135/datetime_doc.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 22:33:20 2011
From: report at bugs.python.org (David Watson)
Date: Mon, 12 Sep 2011 20:33:20 +0000
Subject: [issue12958] test_socket failures on Mac OS X
In-Reply-To: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>
Message-ID: <1315859600.54.0.706604511301.issue12958@psf.upfronthosting.co.za>


Changes by David Watson :


----------
nosy: +baikie

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 22:35:15 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 12 Sep 2011 20:35:15 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1315859451.71.0.36259273322.issue8822@psf.upfronthosting.co.za>
Message-ID: 


Alexander Belopolsky  added the comment:

On Mon, Sep 12, 2011 at 4:30 PM, Jakob Malm  wrote:
..
> I created a patch with the revised wording.

Your patch seems to reflow the entire paragraph which makes it hard to
review and if applied will appear as a bigger change than it is.  Can
you regenerate the patch so that it does not have whitespace only
diffs?  Thanks.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 22:36:00 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 12 Sep 2011 20:36:00 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1315859760.15.0.48359823309.issue8822@psf.upfronthosting.co.za>


anatoly techtonik  added the comment:

The point was:
1. Create an anchor to definition of "naive" object
2. Create an anchor to definition of "aware" object
3. Make definitions stand out from the inline text
4. Create cross-references for "naive" and "aware" keywords in text that lead directly to appropriate definition
5. Mention the fact: By default all objects are "naive", by definition, because they don't have any TZ information, and there are no classes in stdlib that provide this info (tzclass implemetations)
6. Answer the questions: How to make non-naive object? How to detect if object of naive or aware?

That's it. If it's already done - then this ticket can be closed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 22:50:38 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 12 Sep 2011 20:50:38 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1315859760.15.0.48359823309.issue8822@psf.upfronthosting.co.za>
Message-ID: 


Alexander Belopolsky  added the comment:

On Mon, Sep 12, 2011 at 4:36 PM, anatoly techtonik
 wrote:
..
> 5. Mention the fact: By default all objects are "naive", by definition, because they don't have any
> TZ information, and there are no classes in stdlib that provide this info (tzclass implemetations)

This is simply wrong: in py3k we have the timezone class that
implements tzinfo interface.

> 6. Answer the questions: How to make non-naive object? How to detect if object of naive or aware?

I would go one step further: we should review the examples in datetime
module documentation and use aware datetime objects unless the point
of the example is to demonstrate a naive datetime.  We should also
replace examples that use sample implementations of tzinfo to use the
timezone class.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 12 23:40:03 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 12 Sep 2011 21:40:03 +0000
Subject: [issue12946] PyModule_GetDict() claims it can never fail, but it can
In-Reply-To: <1315585192.34.0.742122652176.issue12946@psf.upfronthosting.co.za>
Message-ID: <1315863603.72.0.265099713623.issue12946@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc  added the comment:

The path with PyDict_New() is never taken, because PyModule_New already fills md_dict.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 00:42:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Sep 2011 22:42:45 +0000
Subject: [issue12924] Missing call to quote_plus() in
	test_urllib.test_default_quoting()
In-Reply-To: <1315375113.16.0.494762103225.issue12924@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset e25526865339 by Senthil Kumaran in branch 'default':
merge from 3.2 - Add the missing quote_plus call. Fix closes Issue12924
http://hg.python.org/cpython/rev/e25526865339

New changeset e8d8eb9e05fd by Senthil Kumaran in branch '2.7':
Port the fix for Issue12924 (missing quote_plus) to 2.7 branch.
http://hg.python.org/cpython/rev/e8d8eb9e05fd

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 00:43:24 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Sep 2011 22:43:24 +0000
Subject: [issue12924] Missing call to quote_plus() in
	test_urllib.test_default_quoting()
In-Reply-To: <1315375113.16.0.494762103225.issue12924@psf.upfronthosting.co.za>
Message-ID: <1315867404.43.0.858199928867.issue12924@psf.upfronthosting.co.za>


Senthil Kumaran  added the comment:

jon, thanks for the bug report. Fixed and closed in all the branches.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 01:01:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Sep 2011 23:01:12 +0000
Subject: [issue12938] html.escape docstring does not mention single quotes (')
In-Reply-To: <1315508448.5.0.992592094222.issue12938@psf.upfronthosting.co.za>
Message-ID: <1315868472.83.0.677348259434.issue12938@psf.upfronthosting.co.za>


Senthil Kumaran  added the comment:

Yes, single quotes should not escaped in the CGI escape. We should remove that from the table.

----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 01:07:19 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 12 Sep 2011 23:07:19 +0000
Subject: [issue12938] html.escape docstring does not mention single quotes (')
In-Reply-To: <1315508448.5.0.992592094222.issue12938@psf.upfronthosting.co.za>
Message-ID: <1315868839.53.0.525548126125.issue12938@psf.upfronthosting.co.za>


Senthil Kumaran  added the comment:

The single quote escape was added due to Issue9061 and Issue2830. Since it was included deliberately due to above raised issues, it is best to document it, instead of removing it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 01:15:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Sep 2011 23:15:01 +0000
Subject: [issue12938] html.escape docstring does not mention single quotes (')
In-Reply-To: <1315508448.5.0.992592094222.issue12938@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset bc5b96c92770 by Senthil Kumaran in branch '3.2':
Fix issue12938 - Update the docstring of html.escape. Include the information on single quote.
http://hg.python.org/cpython/rev/bc5b96c92770

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 02:05:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Sep 2011 00:05:50 +0000
Subject: [issue12913] Add a debugging howto
In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za>
Message-ID: <1315872350.74.0.444778268154.issue12913@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

> Hadn?t though about coverage.  Will mention it and add a link
> to the devguide part that talks about it.

Is devguide/coverage.html#using-coverage-py generic enough?  We don't have to duplicate the coverage documentation though, mentioning the tool and what it does, provide a couple of simple example and a link to the coverage doc should be enough.

Talking about unittest and coverage is not strictly about debugging (you don't have any bug yet), but it's useful because it might reveal bugs earlier and avoid debugging sessions later.  This might also go with pyflakes and friends, since they both provide a way to detect bugs earlier.

> - running Python in gdb

This is somewhat orthogonal, but the devguide/gdb page doesn't say how to start running Python in gdb (it might be obvious to people used to use gdb, but it should still be mentioned).

> If error not obvious from quick read, in a 20 line function,
> add print around line 10.

I usually print variables in order of suspiciousness, i.e., I usually have an idea about where the problem might be, if it's not there I move to the next suspect.  This also applies when I know which variable is "wrong" but I don't know where it got wrong: I just add the prints around the most suspicious function that might have changed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 02:30:59 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 13 Sep 2011 00:30:59 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1315873859.73.0.50241829525.issue6560@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

The feature patch for sendmsg/recvmsg support came with a swathe of new tests, and the failures are in those new tests rather than anything breaking in the old ones.

As Charles-Fran?ois noted though, it doesn't look like the feature implementation itself is doing anything wrong, just that there are limits to what Mac OS X allows us to do with it (hence why I closed this feature request and opened issue #12958 to cover the task of updating the test suite to accurately reflect that situation).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 04:15:40 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 13 Sep 2011 02:15:40 +0000
Subject: [issue1172711] long long support for array module
In-Reply-To: <1315857303.94.0.891677568361.issue1172711@psf.upfronthosting.co.za>
Message-ID: 


Meador Inge  added the comment:

>>>> import array, struct
>>>> a = array.array('L', [1,2,3])
>>>> class T(object):
> ... ? ? def __init__(self, value):
> ... ? ? ? ? self.value = value
> ... ? ? def __int__(self):
> ... ? ? ? ? ?return self.value
> ...
>>>> a = array.array('L', [1,2,3])
>>>> struct.pack_into('L', a, 0, 9)
>>>> a
> array('L', [9, 2, 3])
>>>> a[0] = T(100)
>>>> a
> array('L', [100, 2, 3])
>>>> struct.pack_into('L', a, 0, T(200))
> Traceback (most recent call last):
> ?File "", line 1, in 
> struct.error: required argument is not an integer
>>>>
>
> I vastly prefer the struct module behavior. Since the code isn't executed
> by any tests:

Yeah, but if it is a good feature we can always add more tests.  I think the
real issue is whether or not this behavior is even desirable.  Also, similar
behavior can be achieved with struct by using '__index__':

...      def __init__(self, value):
...          self.value = value
...      def __int__(self):
...           return self.value
...      def __index__(self):
...           return self.value
...
>>> a = array.array('L', [1,2,3])
>>> struct.pack_into('L', a, 0, T(200))
>>> a
array('L', [200, 2, 3])

Also, check out issue1530559.  Originally, struct did allow the
'__int__' and '__long__' behavior, but it was deprecated and replaced
with '__index__'.  Maybe we should do the same for array?

IMO, having some way to convert objects to integers is a nice feature
and I think we will find more cases like the PyCUDA case from
issue1530559 where folks need this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 06:21:53 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 13 Sep 2011 04:21:53 +0000
Subject: [issue12961] unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1315887713.2.0.323099540195.issue12961@psf.upfronthosting.co.za>


Changes by Chris Rebert :


----------
nosy: +cvrebert

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 06:38:11 2011
From: report at bugs.python.org (ben)
Date: Tue, 13 Sep 2011 04:38:11 +0000
Subject: [issue12967] AttributeError distutils\log.py
Message-ID: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>


New submission from ben :

AttributeErrors on log.py in the distutils directory

import sys
stream = sys.stdout
if stream.errors == 'strict': pass'=> this will raise an AttributeError'

----------
assignee: tarek
components: Distutils
files: log.py
messages: 143949
nosy: Ben.thelen, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: AttributeError distutils\log.py
type: compile error
versions: Python 3.2
Added file: http://bugs.python.org/file23136/log.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 08:51:35 2011
From: report at bugs.python.org (=?utf-8?b?SmnFmcOtIEt1xI1lcmE=?=)
Date: Tue, 13 Sep 2011 06:51:35 +0000
Subject: [issue12969] Command 'open(0,
	"wb").close()' cause crash of Python interpreter [interactive mode]
Message-ID: <1315896695.55.0.887775413024.issue12969@psf.upfronthosting.co.za>


New submission from Ji?? Ku?era :

Invoking the `close' method of `_io.BufferedWriter' instance created by `open(0,"wb")' command cause the Python interpreter crash.

Python interpreter info:
  mode: interactive
  version info: Python 3.2.1 (default, Jul 10 2011, 21:51:15) [MSC v.1500 32 bit (Intel)] on win32

Operanting system info:
  Microsoft Windows XP
  Home Edition
  Version 2002
  Service Pack 3

Commands:
>>> fd = open(0,"wb")
>>> fd.close()

----------
components: Interpreter Core
messages: 143951
nosy: i386x
priority: normal
severity: normal
status: open
title: Command 'open(0,"wb").close()' cause crash of Python interpreter [interactive mode]
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 12:02:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Sep 2011 10:02:16 +0000
Subject: [issue12969] Command 'open(0,
	"wb").close()' cause crash of Python interpreter [interactive mode]
In-Reply-To: <1315896695.55.0.887775413024.issue12969@psf.upfronthosting.co.za>
Message-ID: <1315908136.48.0.463582472258.issue12969@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
components: +IO
nosy: +benjamin.peterson, ezio.melotti, pitrou, stutzbach
stage:  -> test needed
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 12:51:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 10:51:49 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315911109.26.0.723023732008.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

The failure was introduced by issue #12655. I attach a minimal script
to reproduce the segfault.

----------
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file23138/crash.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 13:00:33 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 11:00:33 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315911633.28.0.515765538016.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

And here's a full backtrace of crash.py:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x400225f0 (LWP 633)]
0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2
(gdb) bt
#0  0x40011d20 in __tls_get_addr () from /lib/ld-linux.so.2
#1  0x40035a14 in __h_errno_location () from /lib/libpthread.so.0
#2  0x40a788dc in __libc_res_nsearch () from /lib/libresolv.so.2
#3  0x40a66e9c in _nss_dns_gethostbyname3_r () from /lib/libnss_dns.so.2
#4  0x40a670ac in _nss_dns_gethostbyname2_r () from /lib/libnss_dns.so.2
#5  0x40180480 in gaih_inet () from /lib/libc.so.6
#6  0x40181da8 in getaddrinfo () from /lib/libc.so.6
#7  0x406084a4 in socket_getaddrinfo (self=0x405d7bcc, args=0x4089a8b4, 
    kwargs=0x0)
    at /home/user/mercurial-1.9.2/cpython/Modules/socketmodule.c:4787
#8  0x001ea384 in PyCFunction_Call (func=0x405da1f4, arg=0x4089a8b4, kw=0x0)
    at Objects/methodobject.c:84
#9  0x000a3634 in call_function (pp_stack=0xbeab7d1c, oparg=4)
    at Python/ceval.c:4000
#10 0x0009cab8 in PyEval_EvalFrameEx (f=0x407457b4, throwflag=0)
    at Python/ceval.c:2625
#11 0x000a0bfc in PyEval_EvalCodeEx (_co=0x405d6ab8, globals=0x40591a34, 
    locals=0x0, args=0x408884dc, argcount=2, kws=0x408884e4, kwcount=0, 
    defs=0x40512a20, defcount=2, kwdefs=0x0, closure=0x0)
    at Python/ceval.c:3375
#12 0x000a3cfc in fast_function (func=0x405e30e4, pp_stack=0xbeab8068, n=2, 
    na=2, nk=0) at Python/ceval.c:4098
#13 0x000a3838 in call_function (pp_stack=0xbeab8068, oparg=2)
---Type  to continue, or q  to quit---
    at Python/ceval.c:4021
#14 0x0009cab8 in PyEval_EvalFrameEx (f=0x40888374, throwflag=0)
    at Python/ceval.c:2625
#15 0x000a0bfc in PyEval_EvalCodeEx (_co=0x4089d5d8, globals=0x4088d854, 
    locals=0x0, args=0x404e2ac8, argcount=2, kws=0x405b43c8, kwcount=2, 
    defs=0x4098fbd0, defcount=6, kwdefs=0x0, closure=0x0)
    at Python/ceval.c:3375
#16 0x001c3060 in function_call (func=0x40a2dea4, arg=0x404e2ab4, 
    kw=0x409a98f4) at Objects/funcobject.c:629
#17 0x0017f1a0 in PyObject_Call (func=0x40a2dea4, arg=0x404e2ab4, 
    kw=0x409a98f4) at Objects/abstract.c:2149
#18 0x001a1a9c in method_call (func=0x40a2dea4, arg=0x404e2ab4, kw=0x409a98f4)
    at Objects/classobject.c:318
#19 0x0017f1a0 in PyObject_Call (func=0x4050b9d4, arg=0x404e2574, 
    kw=0x409a98f4) at Objects/abstract.c:2149
#20 0x0004a6c0 in slot_tp_init (self=0x405ae504, args=0x404e2574, 
    kwds=0x409a98f4) at Objects/typeobject.c:5431
#21 0x00037650 in type_call (type=0x40a31034, args=0x404e2574, kwds=0x409a98f4)
    at Objects/typeobject.c:691
#22 0x0017f1a0 in PyObject_Call (func=0x40a31034, arg=0x404e2574, 
    kw=0x409a98f4) at Objects/abstract.c:2149
#23 0x000a46bc in do_call (func=0x40a31034, pp_stack=0xbeab84f0, na=1, nk=2)
    at Python/ceval.c:4220
#24 0x000a3858 in call_function (pp_stack=0xbeab84f0, oparg=513)
    at Python/ceval.c:4023
#25 0x0009cab8 in PyEval_EvalFrameEx (f=0x40558544, throwflag=0)
    at Python/ceval.c:2625
#26 0x000a0bfc in PyEval_EvalCodeEx (_co=0x40479d28, globals=0x403d5034, 
    locals=0x403d5034, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
    defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3375
#27 0x000916f4 in PyEval_EvalCode (co=0x40479d28, globals=0x403d5034, 
    locals=0x403d5034) at Python/ceval.c:770
#28 0x000e0cb4 in run_mod (mod=0x37c8f8, filename=0x405028c8 "crash.py", 
    globals=0x403d5034, locals=0x403d5034, flags=0xbeab8864, arena=0x2e5178)
    at Python/pythonrun.c:1793
#29 0x000e0a58 in PyRun_FileExFlags (fp=0x2ce260, 
    filename=0x405028c8 "crash.py", start=257, globals=0x403d5034, 
    locals=0x403d5034, closeit=1, flags=0xbeab8864) at Python/pythonrun.c:1750
#30 0x000debcc in PyRun_SimpleFileExFlags (fp=0x2ce260, 
    filename=0x405028c8 "crash.py", closeit=1, flags=0xbeab8864)
    at Python/pythonrun.c:1275
#31 0x000dde68 in PyRun_AnyFileExFlags (fp=0x2ce260, 
    filename=0x405028c8 "crash.py", closeit=1, flags=0xbeab8864)
    at Python/pythonrun.c:1046
#32 0x000ff984 in run_file (fp=0x2ce260, filename=0x401fe028, p_cf=0xbeab8864)
    at Modules/main.c:299
#33 0x00100780 in Py_Main (argc=2, argv=0x401fc028) at Modules/main.c:693
#34 0x0001a914 in main (argc=2, argv=0xbeab8994) at ./Modules/python.c:59

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 13:39:30 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 11:39:30 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1315913970.93.0.205299101377.issue1813@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

https://bugzilla.redhat.com/show_bug.cgi?id=726536 claims that the
glibc issue (which is relevant for skipping the test case) is fixed
in glibc-2.14.90-8.

I suspect the only way of running the test case reliably is whitelisting
a couple of known good glibc versions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 13:43:27 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Sep 2011 11:43:27 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315914207.45.0.296949943899.issue1172711@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 13:45:39 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Sep 2011 11:45:39 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315914339.3.0.265752982131.issue1172711@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Yes, please let's not add any new __int__-based duck typing here; IMO, we should be moving away from such uses of __int__.  I'd be fine with __index__ based duck-typing.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 13:52:52 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Sep 2011 11:52:52 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1315914772.34.0.601822565756.issue7201@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> I don't think it is practical to support both ABIs.

I suspect you're right.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 13:57:46 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 13 Sep 2011 11:57:46 +0000
Subject: [issue12969] Command 'open(0,
	"wb").close()' cause crash of Python interpreter [interactive mode]
In-Reply-To: <1315896695.55.0.887775413024.issue12969@psf.upfronthosting.co.za>
Message-ID: <1315915066.23.0.943092519913.issue12969@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

Under Python 3, open(integer) tries to open a file descriptor.

So, "f=open(0,...); f.close()" closes stdin, rightly shutting down the interpreter. It is not a crash, it is a shutdown. Tested under Linux.

The point is if opening a file descriptor is actually supported in Python 3...

In python 2.7 I get this: "TypeError: coercing to Unicode: need string or buffer, int found".

----------
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 14:03:23 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 13 Sep 2011 12:03:23 +0000
Subject: [issue12969] Command 'open(0,
	"wb").close()' cause crash of Python interpreter [interactive mode]
In-Reply-To: <1315896695.55.0.887775413024.issue12969@psf.upfronthosting.co.za>
Message-ID: <1315915403.21.0.442851533911.issue12969@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

In "help(open)" I see this:

"""
    file is either a text or byte string giving the name (and the path
    if the file isn't in the current working directory) of the file to
    be opened or an integer file descriptor of the file to be
    wrapped. (If a file descriptor is given, it is closed when the
    returned I/O object is closed, unless closefd is set to False.)
"""

So, file descriptors are allowed.

The interpreter shutdowns because your are closing STDIN. This is correct, in my opinion.

Closing this bug as "invalid". If you think this is an error, feel free to argue.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 14:04:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2011 12:04:13 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315915453.08.0.0188285151511.issue12936@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> The failure was introduced by issue #12655

Wow, great job!

crash.py looks like a libc and/or kernel bug. Can you try the glibc 2.14 (released the 2011-05-31)? You should first check if it is not a duplicate of http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 14:26:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Sep 2011 12:26:02 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1315916762.23.0.182726875334.issue12915@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

In addition, error handling/reporting is not trivial to get right.  We?ve had to fix the code in distutils2 and it?s still not quite right (#12703).

I opened this report because I?d like to see all stdlib modules use the same functions and I?d prefer people to copy-paste the same robust code for backports.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 14:39:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Sep 2011 12:39:18 +0000
Subject: [issue5845] rlcompleter should be enabled automatically
In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za>
Message-ID: <1315917558.9.0.280991980168.issue5845@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

FTR, I tried checking sys.ps1 instead of argv but it?s the same problem.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 14:49:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Sep 2011 12:49:16 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1315918156.21.0.00237020999182.issue12785@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I have added tests to make sure the return value (depending on the local parameter) is correct.  Please test when you have a free slot.  If it fails, the usual line after the XXX comment should be deleted and the test re-run.

----------
Added file: http://bugs.python.org/file23139/fix-list_distinfo_files.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 14:52:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Sep 2011 12:52:27 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1315918347.68.0.269080784851.issue12785@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


Removed file: http://bugs.python.org/file22948/fix-list_distinfo_files.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 14:52:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Sep 2011 12:52:30 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1315918350.13.0.501254206384.issue12785@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


Removed file: http://bugs.python.org/file23065/fix-list_distinfo_files-2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 14:54:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Sep 2011 12:54:32 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1315918472.42.0.350073693662.issue12967@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

When will it raise an AttributeError?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 14:56:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Sep 2011 12:56:23 +0000
Subject: [issue12969] Command 'open(0,
	"wb").close()' cause crash of Python interpreter [interactive mode]
In-Reply-To: <1315896695.55.0.887775413024.issue12969@psf.upfronthosting.co.za>
Message-ID: <1315918583.12.0.837309207439.issue12969@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

fd support is intentional, see Modules/_io/_iomodule.c:318

OTOH closing sys.stdin doesn't exit Python, so I'm not sure why closing fd 0 should.

I was also thinking about possible security implications of this, but if someone tries to pass '0' as filename, it will most likely be passed to open as a string.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:02:12 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 13 Sep 2011 13:02:12 +0000
Subject: [issue12970] os.wlak() consider some symlinks as dirs instead of
	non-dirs
Message-ID: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>


New submission from ???? ????????? :

Consider code:

for (root, dirs, nondirs) in os.walk(path, followlinks=False):
    print (nondirs)

This code will not print symlinks that refer to some dir. I think it is the bug.

In other words: If followlinks is True, we should consider some symlinks as dirs. If not, any symlink is the non-dir.

Patch included.

Also, please fix documentation about this nuance.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: z.patch
keywords: patch
messages: 143965
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: os.wlak() consider some symlinks as dirs instead of non-dirs
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23140/z.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:06:17 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2011 13:06:17 +0000
Subject: [issue12970] os.wlak() consider some symlinks as dirs instead of
	non-dirs
In-Reply-To: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>
Message-ID: <1315919177.23.0.691759375472.issue12970@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:06:48 2011
From: report at bugs.python.org (sbt)
Date: Tue, 13 Sep 2011 13:06:48 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1315919208.86.0.852232046929.issue8713@psf.upfronthosting.co.za>


sbt  added the comment:

Here is a patch which adds the following functions:

  forking_disable()
  forking_enable()
  forking_is_enabled()
  set_semaphore_prefix()
  get_semaphore_prefix()

To create child processes using fork+exec on Unix, call
forking_disable() at the beginning of the program.

I have tested the patch on Linux (by adding forking_disable() to
test_multiprocessing), and it seems to work.  However, the patch does
not modify test_multiprocessing, and I am not sure of the best way to
do so.  (See below.)

There are some issues with named semaphores.  When forking is
disabled, the name of the semaphore must be left unlinked so that
child processes can use sem_open() on the name.  The patch therefore
delays unlinking the name (only when forking is disabled) until the
original SemLock object is garbage collected or the process which
created it exits.

But if a process is killed without exiting cleanly then the name may
be left unlinked.  This happens, for instance, if I run
test_multiprocessing and then keep hitting ^C until all the processes
exit.  On Linux this leaves files with names like

  /dev/shm/sem.mp-fa012c80-4019-2

which represent leaked semaphores.  These won't be destroyed until the
computer reboots or the semaphores are manually removed (by using
sem_unlink() or by unlinking the entry from the file system).

If some form of this patch is accepted, then the problem of leaked
semaphores needs to be addressed, otherwise the buildbots are likely
run out of named semaphores.  But I am not sure how best to do this in
a platform agnostic way.  (Maybe a forked process could collect names
of all semaphores created, via a pipe.  Then it could try to
sem_unlink() all those names when all write-ends of the pipe are
closed.)

----------
keywords: +patch
nosy: +sbt
Added file: http://bugs.python.org/file23141/mp_fork_exec.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:16:05 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 13 Sep 2011 13:16:05 +0000
Subject: [issue12970] os.wlak() consider some symlinks as dirs instead of
	non-dirs
In-Reply-To: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>
Message-ID: <1315919765.32.0.34777559758.issue12970@psf.upfronthosting.co.za>


???? ?????????  added the comment:

Also, there is some mis-optimisation for followlinks=False: stat() and then lstat() will be called. Instead of one lstat().

Code may be rewritten as (but I don't know about cross-platform issues):
---------------------------------
if followlinks:
    mode = os.stat(path).st_mode
else:
    mode = os.lstat(path).st_mode

if stat.S_ISDIR(mode):
    dirs.append(path)
else:
    nondir.append(path)
---------------------------------
It will be much cleaner than current (or patched with my patch) implementation

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:23:58 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 13 Sep 2011 13:23:58 +0000
Subject: [issue12971] os.isdir() should contain skiplinks=False in arguments
Message-ID: <1315920238.53.0.290032380593.issue12971@psf.upfronthosting.co.za>


New submission from ???? ????????? :

When skiplinks is False (by default), it should as in current implementation, i.e. using stat().

if skiplinks is True, isidr() should use lstat() and same logick. 

If one will be implemented, os.walk() should be patched (see issue12970) to use this new isdir() with this new parameter instead of own logick in os.walk().

----------
components: Library (Lib)
messages: 143968
nosy: mmarkk
priority: normal
severity: normal
status: open
title: os.isdir() should contain skiplinks=False in arguments
type: feature request
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:24:15 2011
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 13 Sep 2011 13:24:15 +0000
Subject: [issue12970] os.walk() consider some symlinks as dirs instead of
	non-dirs
In-Reply-To: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>
Message-ID: <1315920255.41.0.0477039657026.issue12970@psf.upfronthosting.co.za>


Changes by ???? ????????? :


----------
title: os.wlak() consider some symlinks as dirs instead of non-dirs -> os.walk() consider some symlinks as dirs instead of non-dirs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:36:08 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 13 Sep 2011 13:36:08 +0000
Subject: =?utf-8?b?W2lzc3VlMTI5NjhdIHZ2Y2Nj55WZ5p+l77yB77yB77yB?=
In-Reply-To: <007202305333$51526051$02344076@ufdrqfphs>
Message-ID: <1315920968.18.0.113082638156.issue12968@psf.upfronthosting.co.za>


Changes by Benjamin Peterson :


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:48:57 2011
From: report at bugs.python.org (sbt)
Date: Tue, 13 Sep 2011 13:48:57 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1315921737.49.0.221622986473.issue8713@psf.upfronthosting.co.za>


Changes by sbt :


Removed file: http://bugs.python.org/file23141/mp_fork_exec.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 15:50:30 2011
From: report at bugs.python.org (sbt)
Date: Tue, 13 Sep 2011 13:50:30 +0000
Subject: [issue8713] multiprocessing needs option to eschew fork() under Linux
In-Reply-To: <1273853591.12.0.245920632829.issue8713@psf.upfronthosting.co.za>
Message-ID: <1315921830.01.0.300052537415.issue8713@psf.upfronthosting.co.za>


sbt  added the comment:

Small fix to patch.

----------
Added file: http://bugs.python.org/file23142/mp_fork_exec.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 16:06:46 2011
From: report at bugs.python.org (Alan McIntyre)
Date: Tue, 13 Sep 2011 14:06:46 +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: <1315922806.47.0.533967660275.issue11981@psf.upfronthosting.co.za>


Alan McIntyre  added the comment:

I also can't see any file operations that might occur between the two .tell() calls, and a full test pass (including test_zipfile64) on the py3k development branch doesn't turn up any problems on Linux (2.6.38, x86_64) for me, so I agree the second .tell() could be removed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 16:09:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Sep 2011 14:09:23 +0000
Subject: [issue12301] Use :role:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1315922963.47.0.555336425265.issue12301@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Alright, I?ll propose piecemeal patches.

Georg, two questions:
1) In the tutorial, should classes with no target use ``MyClass`` or :class:`!MyClass`?  

2) Should file extensions use ``.py`` or :file:`.py`?  We currently have both.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 16:48:01 2011
From: report at bugs.python.org (Alan McIntyre)
Date: Tue, 13 Sep 2011 14:48:01 +0000
Subject: [issue1739648] zipfile.testzip() using progressive file reads
Message-ID: <1315925281.5.0.765535014076.issue1739648@psf.upfronthosting.co.za>


Alan McIntyre  added the comment:

I re-checked testzip-patch3.diff since some time has passed since I last commented on it, and it still seems to work ok (the small test_zipfile.py block failed to apply, but that's easy enough to do manually).  Passes full test run, test_zipfile64.py, etc., on Linux x86_64.

If there is something about the patch that still needs to be addressed before it can be committed, let me know and I'll see what I can do.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 17:00:35 2011
From: report at bugs.python.org (Alan McIntyre)
Date: Tue, 13 Sep 2011 15:00:35 +0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1315926035.8.0.681974110419.issue1757072@psf.upfronthosting.co.za>


Alan McIntyre  added the comment:

So far I haven't had the opportunity to sit down and write up a "lenient zipfile handling" patch; my apologies to those that could really use one.  If somebody does propose a patch, I'll be glad to test and review it.

I suppose I would like to see the issue kept open for a while, even if just to collect common "bending of the rules" cases that people would like to see supported.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 17:00:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Sep 2011 15:00:52 +0000
Subject: [issue12397] re match object methods have no docstrings
In-Reply-To: <1308919603.82.0.975273627438.issue12397@psf.upfronthosting.co.za>
Message-ID: <1315926052.88.0.0618541935256.issue12397@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 17:14:52 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 15:14:52 +0000
Subject: [issue12936] armv5tejl: random segfaults in getaddrinfo()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315926892.24.0.656491462595.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I wonder whether it is http://sources.redhat.com/bugzilla/show_bug.cgi?id=12453.

The demo script from there crashes both on debian-arm and Ubuntu Lucid,
but this specific segfault only occurs on debian arm.

Attached is a minimal C test case that only crashes on debian-arm
when sched_setaffinity() is called *and* the program is linked to
pthread:


$ gcc -Wall -W -O0 -g -o crash crash.c
$ ./crash
$
$ gcc -Wall -W -O0 -g -o crash crash.c -pthread
$ ./crash
Segmentation fault (core dumped)

# comment out: sched_setaffinity(0, size, cpusetp);

$ gcc -Wall -W -O0 -g -o crash crash.c -pthread
$ ./crash
$ 


On Ubuntu all three cases run fine. Perhaps this is a bug in
sched_setaffinity()?

----------
Added file: http://bugs.python.org/file23143/crash.c

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 17:20:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 13 Sep 2011 15:20:03 +0000
Subject: [issue11473] upload command no longer accepts repository by section
	name
In-Reply-To: <1299882717.19.0.490703720004.issue11473@psf.upfronthosting.co.za>
Message-ID: <1315927203.67.0.106067628316.issue11473@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

This is a strange bug.  I added a test using -r server2, using the already-existing PYPIRC_LONG_PASSWORD string as .pypirc contents.  The test passes.  To make sure changing one test would not affect another one, I created a new .pypirc file, PYPIRC_CUSTOM_SERVER, and then I got to see your bug!  I tried various combinations of keys (realm or not, user or not), changed the markup (: or = as delimiter, spaces or not) but could not easily find the root of the bug.

Can you publish a .pypirc file that works with 2.7 and not with 3.2?  That would be a good starting point.

----------
keywords: +patch
Added file: http://bugs.python.org/file23144/test-11473-py32.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 17:27:00 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 13 Sep 2011 15:27:00 +0000
Subject: [issue12301] Use :role:`sys.thing` instead of ``sys.thing`` throughout
In-Reply-To: <1307636549.73.0.554335270504.issue12301@psf.upfronthosting.co.za>
Message-ID: <1315927620.46.0.183825530834.issue12301@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Basically, :class:`!Foo` has no advantage over ``Foo``. The no-linking syntax is really only there for completeness, but I would prefer the plainer and easier to read (in source) ``Foo``.

For files, :file: really only has an advantage if you do something with the information that it's a file (which we don't, currently), or if you use the special feature that you can embed variable parts with {}.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 17:29:32 2011
From: report at bugs.python.org (Damian)
Date: Tue, 13 Sep 2011 15:29:32 +0000
Subject: [issue12972] Color prompt + readline
Message-ID: <1315927772.69.0.871921956001.issue12972@psf.upfronthosting.co.za>


New submission from Damian :

Hi, when using terminal coloring codes (for instance '\x1b[32mhello world\x1b[0m' for a green 'hello world') the raw_input function and readline module behave well except under a very specific use case...

========================================

import readline # provides history via up/down

prompt = '\x1b[32m>>> \x1b[0m' # green '>>> ' prompt

while True:
  raw_input(prompt)

========================================

This provides a green prompt and up/down cycles through prior input. This works well as long as the input is shorter than the prompt string length (in this case 13 characters). However, if the input is longer than the prompt then up/down thinks that the first thirteen rendered characters now belong to the prompt. For instance...

atagar at fenrir:~/Desktop/arm$ python tmp.py 
>>> http://docs.python.org/library/readline

Press up, then down to get back to a blank prompt. You'll have...
>>> http://do

This is probably due to a len() check on the raw_input argument...
>>> len('>>> http://do')
13
>>> len('\x1b[32m>>> \x1b[0m')
13

I'm at a bit of a loss for investigating this further - help would be appreciated! -Damian

----------
messages: 143977
nosy: atagar1
priority: normal
severity: normal
status: open
title: Color prompt + readline
type: behavior
versions: Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 17:54:04 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 15:54:04 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315929244.05.0.413939328321.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I think I got it: pthread_setaffinity_np() does not crash. 
 
`man sched_setaffinity` is slightly ambiguous, but there is this remark:

(If  you  are  using  the POSIX threads API, then use pthread_setaffinity_np(3) 
 instead of sched_setaffinity().)


I'm attaching the non-crashing version.

----------
title: armv5tejl: random segfaults in getaddrinfo() -> armv5tejl segfaults: sched_setaffinity() vs. pthread_setaffinity_np()
Added file: http://bugs.python.org/file23145/pthread_nocrash.c

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 19:26:14 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 13 Sep 2011 17:26:14 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315934774.39.0.412054047579.issue12936@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> I think I got it: pthread_setaffinity_np() does not crash.

Nice.
Out of curiosity, I just looked at the source code, and it just does sched_setaffinity(thread->tid), so you can do the same with sched_setaffinity(syscall(SYS_gettid)) for the current thread.
However, I don't think we should/could add this to the posix module: it expects a pthread_t instead of a PID, to which we don't have access.
Furthermore, even though we're linked with pthread, this should normally succeed - or at least not crash - when called from the main thread - and it does on my Debian squeeze box.
So I'd suggest closing this issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 19:52:25 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 13 Sep 2011 17:52:25 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315936345.18.0.340841868393.issue1172711@psf.upfronthosting.co.za>


Meador Inge  added the comment:

> Yes, please let's not add any new __int__-based duck typing here;

Mark, just to clarify a bit, the behavior is already there in the array module (by way of 'PyLong_AsLong').  The fact that it is there was picked up on a code review for this issue.

Anyway, I think we should open a new issue to track the '__index__' vs. '__int__' stuff.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 19:55:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2011 17:55:50 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315936550.19.0.0253691544449.issue12936@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> However, I don't think we should/could add this to the posix module: 
> it expects a pthread_t instead of a PID, to which we don't have access.

We already have such function:
http://docs.python.org/dev/library/signal.html#signal.pthread_kill

I added threading.get_ident() to easily get the thread identifier. In Python < 3.3, you can use threading.current_thread().ident.

It's not documented, but if you pass a random integer, signal.pthread_kill() does crash.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 19:56:16 2011
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 13 Sep 2011 17:56:16 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1315936576.23.0.391294490605.issue12785@psf.upfronthosting.co.za>


Jeremy Kloth  added the comment:

The attached patch seems to work as-is.  That is, just testing for `self.path` as the prefix.  On Windows, at least, the paths in RECORD are always absolute.

Further changes will be necessary, of course, once changes for alternative paths (--prefix, --home, and so on) are incorporated.

----------
nosy: +jkloth

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 21:03:20 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Sep 2011 19:03:20 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315940600.05.0.137136366724.issue1172711@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> Mark, just to clarify a bit, the behavior is already there in the array module

Okay, understood.  But the new 'long long' support provided by this patch still allows for __int__-based duck typing, right?

>>> array('Q', [1, 2, Decimal(3.2)])
array('Q', [1, 2, 3])

That's the new duck typing I meant.  I see this acceptance of things with an __int__ method as a mistake, and my gut reaction earlier was that it seems wrong to propagate that mistake into the new long long functionality, even though it's already present in other places in the array module.

On second thoughts though, it would be a peculiar inconsistency to be able to pass Decimal objects to array('L', ...) but not to array('Q', ...).  So probably better to accept this behaviour for now, and open another issue for the __int__ / __index__ discussion, as you suggest.

BTW, the patch and tests look good to me, and all tests pass here (OS X !0.6, 64-bit) (Well, not quite true, but I fail to see how these changes could be responsible for the test_socket and test_packaging failures I'm seeing :-).  I get compile-time warnings from the 'int' declarations that should be 'Py_ssize_t', but I understand that's taken care of already...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 21:13:59 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 19:13:59 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315934774.39.0.412054047579.issue12936@psf.upfronthosting.co.za>
Message-ID: <20110913191100.GA25752@sleipnir.bytereef.org>


Stefan Krah  added the comment:

Charles-Fran?ois Natali  wrote:
> Out of curiosity, I just looked at the source code, and it just does
> sched_setaffinity(thread->tid), so you can do the same with
> sched_setaffinity(syscall(SYS_gettid)) for the current thread.

sched_setaffinity(syscall(SYS_gettid), size, cpusetp) crashes, too.
This seems to be a violation of the man page, which states:

"The value returned from a call to gettid(2) can be passed in
 the argument pid."

Unless one uses a somewhat warped interpretation that linking
against pthread constitutes "using the POSIX threads API". That
would be the only loophole that would allow the crash.

> However, I don't think we should/could add this to the posix module:
> it expects a pthread_t instead of a PID, to which we don't have access.

If we have access (and as I understood from Victor's post we do):
pthread_getaffinity_np() also exists on FreeBSD, which would be
an advantage.

> So I'd suggest closing this issue.

I don't care strongly about using pthread_getaffinity_np(), but at least I'd
like to skip the scheduling sections on arm-linux if they don't work reliably.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 21:46:50 2011
From: report at bugs.python.org (Adam)
Date: Tue, 13 Sep 2011 19:46:50 +0000
Subject: [issue12973] int_pow() implementation is incorrect
Message-ID: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>


New submission from Adam :

int_pow() (from Objects/intobject.c) shows incorrect results when Python is compiled with Clang (llvm.org); long story short: int_pow() function should use 'unsigned long' type instead of 'long' or some code gets optimised out.

Please, refer to this bug report to find out the details:
http://llvm.org/bugs/show_bug.cgi?id=10923

----------
messages: 143985
nosy: adam at NetBSD.org
priority: normal
severity: normal
status: open
title: int_pow() implementation is incorrect
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 21:59:50 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 19:59:50 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1315943990.19.0.262411803415.issue12973@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I think this is related to issue #11149. Can you try compiling with
-fwrapv?

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 22:25:42 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 13 Sep 2011 20:25:42 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: <1315945542.21.0.280897363684.issue12720@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis  added the comment:

There is an inconsistency in used header and library.
attr/xattr.h and libattr.so belong to attr package (http://savannah.nongnu.org/projects/attr).
glibc provides sys/xattr.h and libc.so.
Both libattr.so and libc.so define getxattr(), setxattr() and other functions.
Modules/posixmodule.c includes attr/xattr.h from attr package, but libpython3.3.so isn't linked against libattr.so and is linked against libc.so, so functions from glibc are used at run time.

I suggest to use sys/xattr.h:
- sys/xattr.h instead of attr/xattr.h in Modules/posixmodule.c, configure, configure.in and pyconfig.h.in
- HAVE_SYS_XATTR_H instead of HAVE_ATTR_XATTR_H in Modules/posixmodule.c and pyconfig.h.in

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 22:47:10 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 13 Sep 2011 20:47:10 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315946830.17.0.273226137403.issue12936@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> If we have access (and as I understood from Victor's post we do):
> pthread_getaffinity_np() also exists on FreeBSD, which would be
> an advantage.

Yes, but I see several drawbacks:
- as noted by Victor, it's really easy to crash the interpreter by passing an invalid thread ID, which IMHO, should be avoided at all cost
- to be safe, we would need to have a different API depending on whether Python is built with threads or not (i.e. sched_setaffinity() without threads, and pthread_setaffinity_np())
- pthread_setaffinity_np() is really non-portable (it's guarded by __USE_GNU in my system's header)
- sched_setaffinity() seems to work fine on most systems even when linked with pthread

> I don't care strongly about using pthread_getaffinity_np(), but at least I'd
> like to skip the scheduling sections on arm-linux if they don't work reliably.

Sounds reasonable.
I guess you could use os.uname() or platform.machine().

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 13 23:20:56 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Sep 2011 21:20:56 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 33f7044b5682 by Benjamin Peterson in branch 'default':
Use xattr functions from sys/xattr.h instead of attr/xattr.h (closes #12720)
http://hg.python.org/cpython/rev/33f7044b5682

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 00:46:53 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 22:46:53 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1315954013.7.0.582286717855.issue12973@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I can reproduce your results with a recent clang. gcc has similar
optimization behavior, but for gcc ./configure automatically adds
-fwrapv, which prevents the incorrect results.

I'm closing this as a duplicate of #11149.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> [PATCH] Configure should enable -fwrapv for clang

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 00:47:22 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 22:47:22 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1315954042.04.0.261224737459.issue11149@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
nosy: +adam at NetBSD.org, skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 00:53:28 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 13 Sep 2011 22:53:28 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1315954408.99.0.85435359366.issue11149@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Recent clang and Python2.7 (without the patch):

Python 2.7.2+ (2.7:e8d8eb9e05fd, Sep 14 2011, 00:35:51) 
[GCC 4.2.1 Compatible Clang 3.0 (trunk 139637)] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> 2**63
-9223372036854775808
>>> 2**64
0
>>> 


The patch is fine and I'm going to commit it tomorrow if there are no
objections.

----------
priority: high -> critical

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 01:10:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2011 23:10:04 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1315955404.14.0.736327686756.issue12936@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> as noted by Victor, it's really easy to crash the interpreter
> by passing an invalid thread ID, which IMHO, should be avoided
> at all cost

Do you mean that signal.pthread_kill() should be removed? This function is very useful and solve some issues that cannot be solved differently. At the same time, I don't think that it's possible to workaround the crashes. At least, I don't see how: pthread_kill(tid, 0) is supposed to check if tid exists, but it does crash...

> to be safe, we would need to have a different API depending
> on whether Python is built with threads or not
> (i.e. sched_setaffinity() without threads,
> and pthread_setaffinity_np())

We cannot use the same name for two different C function. One expects a process identifier, whereas the other expects a thread identifier! If Python is compiled without thread, the thread will not exist (as some modules and many other functions).

> pthread_setaffinity_np() is really non-portable
> (it's guarded by __USE_GNU in my system's header)

We can check it in configure. We already use some functions which are GNU extensions, like makedev(). Oh, os.makedev() availability is just not documented :-)

> sched_setaffinity() seems to work fine on most systems
> even when linked with pthread

Again, it looks like a libc/kernel bug. I don't think that Python can work around such issue.

> I don't care strongly about using pthread_getaffinity_np()

I don't really care of pthread_getaffinity_np() :-) To add a new function, we need a usecase and it should be requested. This issue is about a crash using sched_setaffinity(), not about pthread_getaffinity_np.

I don't know or need (), but the difference between sched_setaffinity and pthread_getaffinity_np is the same between sigprocmask() and pthread_sigmask(). I chose to expose only the later because the behaviour of sigprocmask is undefined in a process using threads. sched_setaffinity manual contains the sentence "If you are using the POSIX threads API, then use pthread_setaffinity_np(3) instead of sched_setaffinity()".

See also Portable Hardware Locality (hwloc):
http://www.open-mpi.org/projects/hwloc/

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 01:12:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2011 23:12:08 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1315955528.52.0.346283923434.issue11149@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

"Recent clang and Python2.7 (without the patch):

>>> 2**64
0"

Does the test suite catch this bug?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 01:13:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2011 23:13:03 +0000
Subject: [issue12946] PyModule_GetDict() claims it can never fail, but it can
In-Reply-To: <1315585192.34.0.742122652176.issue12946@psf.upfronthosting.co.za>
Message-ID: <1315955583.92.0.241872666252.issue12946@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

So, can we close this issue?

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 01:21:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2011 23:21:13 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1315956073.01.0.422887896551.issue8828@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

According to the following article, a fsync is also needed on the directory after a rename. I don't understand if is it always needed for an atomic rename, or if we only need it for the "atomic write" pattern.

http://lwn.net/Articles/457667/

"The more subtle usages deal with newly created files, or overwriting existing files. A newly created file may require an fsync() of not just the file itself, but also of the directory in which it was created (since this is where the file system looks to find your file). This behavior is actually file system (and mount option) dependent. You can either code specifically for each file system and mount option combination, or just perform fsync() calls on the directories to ensure that your code is portable."

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 01:41:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2011 23:41:32 +0000
Subject: [issue12960] threading.Condition is not a class
In-Reply-To: <1315748239.01.0.928739848932.issue12960@psf.upfronthosting.co.za>
Message-ID: <1315957292.16.0.452443636016.issue12960@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> According to http://docs.python.org/library/threading.html#condition-objects, threading.Condition is a class.

Nope, it's a factory, and it's written in the doc:

"threading.Condition()
A factory function that returns a new condition variable object. A condition variable allows one or more threads to wait until they are notified by another thread.

See Condition Objects."

It has been changed in Python 3.3 (#10968): threading.Condition is now a class, instead of a factory.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 01:43:06 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 13 Sep 2011 23:43:06 +0000
Subject: [issue10968] threading.Timer should be a class so that it can be
	derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1315957386.5.0.278274867212.issue10968@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

@eric: The doc has to be updated:

http://docs.python.org/dev/library/threading.html#threading.activeCount

"threading.Condition()
A factory function that returns a new condition variable object. A condition variable allows one or more threads to wait until they are notified by another thread.

See Condition Objects."

--

See also (maybe) issue #12960.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 01:45:54 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 13 Sep 2011 23:45:54 +0000
Subject: [issue12960] threading.Condition is not a class
In-Reply-To: <1315957292.16.0.452443636016.issue12960@psf.upfronthosting.co.za>
Message-ID: <4E6FEB2B.5040506@rath.org>


Nikolaus Rath  added the comment:

On 09/13/2011 07:41 PM, STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
>> According to http://docs.python.org/library/threading.html#condition-objects, threading.Condition is a class.
> 
> Nope, it's a factory, and it's written in the doc:
> 
> "threading.Condition()
> A factory function that returns a new condition variable object. A condition variable allows one or more threads to wait until they are notified by another thread.
> 
> See Condition Objects."

Yes, but further down it still says:

"""
class threading.Condition([lock])

    If the lock argument is given and not None, [....]
"""

Best,

   -Nikolaus

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 02:34:38 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Wed, 14 Sep 2011 00:34:38 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1315960478.04.0.82748790281.issue12930@psf.upfronthosting.co.za>


Changes by Caio Rom?o :


Removed file: http://bugs.python.org/file23118/caioromao-fix-12930-v2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 02:36:42 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Wed, 14 Sep 2011 00:36:42 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1315960602.55.0.226587683898.issue12930@psf.upfronthosting.co.za>


Caio Rom?o  added the comment:

Third version, with slightly less code and my name added to the Misc/ACKS file.

----------
Added file: http://bugs.python.org/file23146/caioromao-fix-12930-v3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 02:48:15 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 14 Sep 2011 00:48:15 +0000
Subject: [issue12974] array module: deprecate '__int__' conversion support for
	array elements
Message-ID: <1315961295.78.0.425877150438.issue12974@psf.upfronthosting.co.za>


New submission from Meador Inge :

When reviewing the fix for issue1172711 it was discovered that the 'array' module allows for '__int__' conversions:

>>> import array, struct
>>> a = array.array('L', [1,2,3])
>>> class T(object):
...     def __init__(self, value):
...         self.value = value
...     def __int__(self):
...          return self.value
...
>>> a = array.array('L', [1,2,3])
>>> struct.pack_into('L', a, 0, 9)
>>> a
array('L', [9, 2, 3])
>>> a[0] = T(100)
>>> a
array('L', [100, 2, 3])

As discussed in issue1172711, this behavior may not be desirable.  We should look at deprecating '__int__' and adding '__index__' as was done for the struct module in issue1530559.

----------
components: Library (Lib)
messages: 144000
nosy: mark.dickinson, meadori, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: array module: deprecate '__int__' conversion support for array elements
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 02:56:44 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 14 Sep 2011 00:56:44 +0000
Subject: [issue1172711] long long support for array module
In-Reply-To: <1315940600.05.0.137136366724.issue1172711@psf.upfronthosting.co.za>
Message-ID: 


Meador Inge  added the comment:

> Okay, understood. ?But the new 'long long' support provided by this patch still allows for __int__-based duck typing, right?

Yes, but ...

> That's the new duck typing I meant. ?I see this acceptance of things with an __int__ method as a mistake, and my gut
> reaction earlier was that it seems wrong to propagate that mistake into the new long long functionality, even though it's already
> present in other places in the array module.
>
> On second thoughts though, it would be a peculiar inconsistency to be able to pass Decimal objects to array('L', ...) but not
> to array('Q', ...). ?So probably better to accept this behaviour for now, and open another issue for the __int__ / __index__ discussion,
> as you suggest.

... I had this inconsistency in mind.  I opened issue12974 for the
__int__/__index__ problem.

Now we just have to figure out which issue gets fixed first :-D  I am
OK with applying the fix for this issue first.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 03:08:22 2011
From: report at bugs.python.org (ben)
Date: Wed, 14 Sep 2011 01:08:22 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315918472.42.0.350073693662.issue12967@psf.upfronthosting.co.za>
Message-ID: <1315962499.82319.YahooMailNeo@web45810.mail.sp1.yahoo.com>


ben  added the comment:

Error?had been?raised when installing the distribute package, but it could be raised on any other usage as sys.stdout does not have an 'error' attribute.
?
?

From: ?ric Araujo 
To: thelen_ben at yahoo.com
Sent: Tuesday, 13 September 2011 8:54 PM
Subject: [issue12967] AttributeError distutils\log.py

?ric Araujo  added the comment:

When will it raise an AttributeError?

----------

_______________________________________
Python tracker 

_______________________________________

----------
Added file: http://bugs.python.org/file23147/unnamed

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------

Error had been raised when installing the distribute package, but it could be raised on any other usage as sys.stdout does not have an 'error' attribute.


 


 









From: ??ric Araujo <report at bugs.python.org>
To: thelen_ben at yahoo.com
Sent: Tuesday, 13 September 2011 8:54 PM
Subject: [issue12967] AttributeError distutils\log.py


??ric Araujo <merwok at netwok.org> added the comment:

When will it raise an AttributeError?

----------

_______________________________________
Python tracker
 <report at bugs.python.org>
<http://bugs.python.org/issue12967>
_______________________________________




From report at bugs.python.org  Wed Sep 14 03:20:30 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 14 Sep 2011 01:20:30 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1315963230.96.0.359355709935.issue1172711@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Updated patch with the 'Py_ssize_t' fixes.

----------
Added file: http://bugs.python.org/file23148/issue-1172711.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 03:29:07 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 14 Sep 2011 01:29:07 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1315963747.05.0.1481365506.issue1621@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 03:29:45 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 14 Sep 2011 01:29:45 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1315963785.86.0.621020117089.issue11149@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 04:23:11 2011
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Wed, 14 Sep 2011 02:23:11 +0000
Subject: [issue1947] Exception exceptions.AttributeError '_shutdown' in
	
Message-ID: <1315966991.86.0.483569616924.issue1947@psf.upfronthosting.co.za>


Brandon Craig Rhodes  added the comment:

In case Google brings anyone else to this bug: this error typically indicates that a `threading.py` which is not actually the Standard Library's `threading` module has somehow wound up on an earlier path in `sys.path` and is therefore shadowing the Standard Library module. This upsets the Python exit logic, which tries to run `threading._shutdown()` if `threading` exists in `sys.modules`. I just helped someone on Stack Overflow with a situation like this, which in that case resulted from an error in how `pylint` works.

----------
nosy: +brandon-rhodes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 04:24:55 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Sep 2011 02:24:55 +0000
Subject: [issue12956] builds fail when installing to --prefix with space in
	path name
In-Reply-To: <1315757316.68.0.219297921497.issue12956@psf.upfronthosting.co.za>
Message-ID: <1315967095.71.0.111124278996.issue12956@psf.upfronthosting.co.za>


Ned Deily  added the comment:

It turns out that supporting a framework path name that contains spaces (or other special characters) is a much more pervasive change that I had originally expected.  That's because the path specified by ./configure --enable-framework= also becomes the default for --prefix which is referenced directly (and indirectly via derived variables) throughout Makefile.pre.in and currently the Makefile does not handle installing a standard Unix-style build on any platform to prefix path that includes spaces, much less a Mac framework build.  That is the following will fail during the install phases:

    ./configure --prefix="/path/with space"
    make && make install

This needs to be addressed first, primarily by quote-protecting all uses of prefix and its derivatives in Makefile shell rules and then the uses of PYTHONFRAMEWORK* variables in the Makefile also need to be protected.  It should be fairly straightforward to find all such uses but there are many of them and changes would affect all platforms that use the Makefile to build and the many variants for each platform (i.e. --enable-shared, --enable-framework, etc) so proper testing would be a major effort.

While I'm sympathetic to supporting arbitrary path names, I'm not sure if it is worth the effort.  I'm going to leave this open for now but I don't plan to work on it myself in the near future.

----------
assignee: ned.deily -> 
components:  -Macintosh
priority: normal -> low
title: 2.7.2 build fails with --enable-framework and space in pathname on OS X 10.7.1 -> builds fail when installing to --prefix with space in path name

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 04:42:59 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 14 Sep 2011 02:42:59 +0000
Subject: [issue12881] ctypes: segfault with large structure field names
In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za>
Message-ID: <1315968179.55.0.207902575775.issue12881@psf.upfronthosting.co.za>


Meador Inge  added the comment:

> Note that there is at least one other place where alloca() is
> used with potentially large values:

Ouch!  I found three more crashers (including the one you found)
by grepping for 'alloca' in ctypes:

>>> from ctypes import *
>>> T = type('x' * 2 ** 25, (Structure,), {})
>>> p = POINTER(T)
Segmentation fault (core dumped)

>>> from ctypes import *
>>> p = POINTER('x' * 2 ** 25)
Segmentation fault (core dumped)

>>> from ctypes import *
>>> NARGS = 2 ** 20
>>> proto = CFUNCTYPE(None, *(c_int,) * NARGS)
>>> def func(*args):
...    return (1, "abc", None)
... 
>>> cb = proto(func)
>>> cb(*(1,) * NARGS)
Segmentation fault (core dumped)

I will fix those too.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 06:06:14 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 14 Sep 2011 04:06:14 +0000
Subject: [issue12946] PyModule_GetDict() claims it can never fail, but it can
In-Reply-To: <1315585192.34.0.742122652176.issue12946@psf.upfronthosting.co.za>
Message-ID: <1315973174.68.0.434416949034.issue12946@psf.upfronthosting.co.za>


Stefan Behnel  added the comment:

I gave two reasons why this function can fail, and one turns out to be assumed-to-be-dead code. So, no, there are two issues now, one with the documentation, one with the code.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 06:17:55 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 14 Sep 2011 04:17:55 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1315973875.09.0.882829394127.issue1621@psf.upfronthosting.co.za>


Changes by Alex Gaynor :


----------
nosy: +alex

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 07:03:21 2011
From: report at bugs.python.org (Eric Snow)
Date: Wed, 14 Sep 2011 05:03:21 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1315976601.96.0.245968509576.issue12857@psf.upfronthosting.co.za>


Eric Snow  added the comment:

Finally had a chance to get back to this.  Here's a new patch in response to Nick's review.

My only concern is the new _PyEval_EvalFunctionCode function.  It is basically the existing PyEval_EvalCodeEx function with an extra parameter.  I've turned PyEval_EvalCodeEx() into a very light wrapper around _PyEval_EvalFunctionCode().  This is how I tackled the backwards incompatibility of my previous patch.  However, I am nervous about messing around with something like PyEval_EvalCodeEx().

I was toying with the idea of doing a more comprehensive refactor involving call_function, fast_function, and do_call, which seems like it would be a better fix.  However, I'm even more reticent to make that scale of changes, especially on something so critical, even if it seems right to me currently.

I figured the safe thing for now would be to name the new function with a leading underscore to mark it as private.

Here are the results from my cursory check before and after my latest patch:

BEFORE
3 tests failed:
    test_distutils test_packaging test_socket
[293234 refs]
real	14m40.578s
user	11m43.547s
sys	0m52.096s

AFTER
3 tests failed:
    test_distutils test_packaging test_socket
[293171 refs]
real	14m33.785s
user	11m55.437s
sys	0m53.850s

----------
Added file: http://bugs.python.org/file23149/called_function_2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 07:19:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Sep 2011 05:19:34 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315955404.14.0.736327686756.issue12936@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

> Do you mean that signal.pthread_kill() should be removed? This function is very useful and solve some issues that cannot be solved differently. At the same time, I don't think that it's possible to workaround the crashes. At least, I don't see how: pthread_kill(tid, 0) is supposed to check if tid exists, but it does crash...

No, I don't suggest to remove it, it is useful.
As for the crashes, with glibc pthread_t is really a pointer, so
there's no way to check its validity beforehand. Even if we did check
the thread ID against the list of Python-created threads IDs (stored
in Thread._ident), this could still crash, because the ID becomes
invalid as soon as the thread terminates (all threads are started
detached). Furthermore, this wouldn't work for non-Python created
threads.

> We cannot use the same name for two different C function. One expects a process identifier, whereas the other expects a thread identifier! If Python is compiled without thread, the thread will not exist (as some modules and many other functions).
>

I know, that's why I said "different API": but I must admit it was
poorly worded ;-)
However, this wouldn't solve this particular problem: as long as we
expose sched_setaffinity(), it will crash as soon as someone passes
`0` or getpid() as PID.

>> pthread_setaffinity_np() is really non-portable
>> (it's guarded by __USE_GNU in my system's header)
>
> We can check it in configure. We already use some functions which are GNU extensions, like makedev(). Oh, os.makedev() availability is just not documented :-)

As I said, this wouldn't solve this problem. If someone deems it
necessary, we can open another issue for this feature request.

>> sched_setaffinity() seems to work fine on most systems
>> even when linked with pthread
>
> Again, it looks like a libc/kernel bug. I don't think that Python can work around such issue.
>

Agreed.

> I don't know or need (), but the difference between sched_setaffinity and pthread_getaffinity_np is the same between sigprocmask() and pthread_sigmask(). I chose to expose only the later because the behaviour of sigprocmask is undefined in a process using threads.

Exactly.
However, nothing prevents someone from using sigprocmask() in a
multithreaded process, the only difference is that it won't crash
(AFAICT).

So I suggest to:
1) skip the problematic tests on ARM when built with threads to avoid segfaults
2) if someone wants pthread_getaffinity_np(), then we can still open a
separate feature request

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 08:08:33 2011
From: report at bugs.python.org (Alexey Smirnov)
Date: Wed, 14 Sep 2011 06:08:33 +0000
Subject: [issue12970] os.walk() consider some symlinks as dirs instead of
	non-dirs
In-Reply-To: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>
Message-ID: <1315980513.81.0.810104068545.issue12970@psf.upfronthosting.co.za>


Changes by Alexey Smirnov :


----------
nosy: +alexey-smirnov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 08:08:44 2011
From: report at bugs.python.org (Alexey Smirnov)
Date: Wed, 14 Sep 2011 06:08:44 +0000
Subject: [issue12971] os.isdir() should contain skiplinks=False in arguments
In-Reply-To: <1315920238.53.0.290032380593.issue12971@psf.upfronthosting.co.za>
Message-ID: <1315980524.71.0.550801387242.issue12971@psf.upfronthosting.co.za>


Changes by Alexey Smirnov :


----------
nosy: +alexey-smirnov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 08:41:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Sep 2011 06:41:12 +0000
Subject: [issue12975] Invitation to connect on LinkedIn
In-Reply-To: <1833930473.1026192.1315981987270.JavaMail.app@ela4-bed82.prod>
Message-ID: <1315982472.76.0.570629772125.issue12975@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 08:41:18 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Sep 2011 06:41:18 +0000
Subject: [issue12975] Invitation to connect on LinkedIn
In-Reply-To: <1833930473.1026192.1315981987270.JavaMail.app@ela4-bed82.prod>
Message-ID: <1315982478.96.0.589845989457.issue12975@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


Removed file: http://bugs.python.org/file23150/unnamed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 08:42:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Sep 2011 06:42:24 +0000
Subject: [issue12975] Invitation to connect on LinkedIn
Message-ID: <1315982544.99.0.87993317197.issue12975@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
Removed message: http://bugs.python.org/msg144010

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 08:42:56 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 14 Sep 2011 06:42:56 +0000
Subject: [issue12975] spam
Message-ID: <1315982576.59.0.98808845764.issue12975@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
stage:  -> committed/rejected
title: Invitation to connect on LinkedIn -> spam

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 08:53:41 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Sep 2011 06:53:41 +0000
Subject: [issue8828] Atomic function to rename a file
In-Reply-To: <1274917301.93.0.503310941815.issue8828@psf.upfronthosting.co.za>
Message-ID: <1315983221.99.0.670292205036.issue8828@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> According to the following article, a fsync is also needed on the 
> directory after a rename. I don't understand if is it always needed for 
> an atomic rename, or if we only need it for the "atomic write" pattern.

It's not needed if you just want atomicity, i.e. the file is visible either under its old name or its new name, but not neither or both.
If is however needed if you want durability, i.e. you want to guarantee that the file is visible under its new name after your atomic_rename returns.

----------
nosy: +neologix

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 09:32:25 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Sep 2011 07:32:25 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1315985545.8.0.638710289762.issue11149@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

>>> 2**64
0

Urk!  I'd call that a release blocker.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 09:36:42 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Sep 2011 07:36:42 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1315985802.09.0.679107775179.issue12973@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Reopening and assigning to me;  it would be good to fix this in intobject.c as well as adding the Clang-specific -fwrapv fix.

----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 10:29:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 08:29:15 +0000
Subject: [issue12960] threading.Condition is not a class
In-Reply-To: <4E6FEB2B.5040506@rath.org>
Message-ID: <4E7065DF.3000703@haypocalc.com>


STINNER Victor  added the comment:

> Yes, but further down it still says:
>
> """
> class threading.Condition([lock])
>
>      If the lock argument is given and not None, [....]
> """

What do you suggest? Replace it by class threading._Condition?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 10:31:19 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 14 Sep 2011 08:31:19 +0000
Subject: [issue12386] packaging fails in install_distinfo when writing
	RESOURCES
In-Reply-To: <1308741745.2.0.628902356429.issue12386@psf.upfronthosting.co.za>
Message-ID: <1315989079.53.0.636779451058.issue12386@psf.upfronthosting.co.za>


Vinay Sajip  added the comment:

I looked at this bug again - I was getting a little confused about it ;-) The problem is happening not when writing out a resource, but the RESOURCES file listing the resources installed. This is a text file, of course, so my suggested fix of using open(resources_path, 'w', encoding='utf-8') would be reasonable.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 10:58:18 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 14 Sep 2011 08:58:18 +0000
Subject: [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1315990698.4.0.757764174108.issue9871@psf.upfronthosting.co.za>


Popa Claudiu  added the comment:

Hello. This happens with this version of IDLE too: 

Python 3.2.1 (default, Jul 10 2011, 21:51:15) [MSC v.1500 32 bit (Intel)] on win32. 
I could write a patch if I knew where to start.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 11:23:21 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 14 Sep 2011 09:23:21 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1315992201.38.0.991301936054.issue12973@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

Notice that this "signed overflow" issue is also tracked as #1621. I don't mind keeping this issue open, though - it's unlikely that #1621 will be fixed within this decade. unless somebody does some heroic effort.

----------
nosy: +loewis

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 11:36:04 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 14 Sep 2011 09:36:04 +0000
Subject: [issue12960] threading.Condition is not a class
In-Reply-To: <1315748239.01.0.928739848932.issue12960@psf.upfronthosting.co.za>
Message-ID: <1315992964.75.0.219003098742.issue12960@psf.upfronthosting.co.za>


Eli Bendersky  added the comment:

> What do you suggest? Replace it by class threading._Condition?

-1 on this

IMHO just documenting the situation as it is would make more sense

----------
nosy: +eli.bendersky

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 12:33:47 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 14 Sep 2011 10:33:47 +0000
Subject: [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1315996427.3.0.963764991666.issue9871@psf.upfronthosting.co.za>


Popa Claudiu  added the comment:

I found the culprit. I wrote b"\x" in IDLE and the window immediatly disappeared. Then, to traceback the problem, I started a python shell and typed the following lines. It seems that in showsyntaxerror, value is different that what was expected. 

C:\>python
Python 3.2.1 (default, Jul 10 2011, 21:51:15) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import idlelib.PyShell
>>> idlelib.PyShell.main()
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python32\lib\code.py", line 63, in runsource
    code = self.compile(source, filename, symbol)
  File "C:\Python32\lib\codeop.py", line 168, in __call__
    return _maybe_compile(self.compiler, source, filename, symbol)
  File "C:\Python32\lib\codeop.py", line 82, in _maybe_compile
    code = compiler(source, filename, symbol)
  File "C:\Python32\lib\codeop.py", line 133, in __call__
    codeob = compile(source, filename, symbol, self.flags, 1)
ValueError: invalid \x escape

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python32\lib\tkinter\__init__.py", line 1399, in __call__
    return self.func(*args)
  File "C:\Python32\lib\idlelib\MultiCall.py", line 166, in handler
    r = l[i](event)
  File "C:\Python32\lib\idlelib\PyShell.py", line 1126, in enter_callback
    self.runit()
  File "C:\Python32\lib\idlelib\PyShell.py", line 1167, in runit
    more = self.interp.runsource(line)
  File "C:\Python32\lib\idlelib\PyShell.py", line 617, in runsource
    return InteractiveInterpreter.runsource(self, source, filename)
  File "C:\Python32\lib\code.py", line 66, in runsource
    self.showsyntaxerror(filename)
  File "C:\Python32\lib\idlelib\PyShell.py", line 654, in showsyntaxerror
    msg = value.msg or ""
AttributeError: 'ValueError' object has no attribute 'msg'
>>>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 13:06:31 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 14 Sep 2011 11:06:31 +0000
Subject: [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1315998391.91.0.419110828456.issue9871@psf.upfronthosting.co.za>


Popa Claudiu  added the comment:

I've attached a patch, hope it is ok.

----------
keywords: +patch
Added file: http://bugs.python.org/file23151/idle.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 13:07:39 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 14 Sep 2011 11:07:39 +0000
Subject: [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1315998459.99.0.871785886775.issue9871@psf.upfronthosting.co.za>


Changes by Popa Claudiu :


Removed file: http://bugs.python.org/file23151/idle.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 13:07:57 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 14 Sep 2011 11:07:57 +0000
Subject: [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1315998477.48.0.400980642649.issue9871@psf.upfronthosting.co.za>


Popa Claudiu  added the comment:

Wrong patch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 13:08:17 2011
From: report at bugs.python.org (Popa Claudiu)
Date: Wed, 14 Sep 2011 11:08:17 +0000
Subject: [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1315998497.69.0.899961682954.issue9871@psf.upfronthosting.co.za>


Changes by Popa Claudiu :


Added file: http://bugs.python.org/file23152/idle.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 13:57:19 2011
From: report at bugs.python.org (Benny Siegert)
Date: Wed, 14 Sep 2011 11:57:19 +0000
Subject: [issue12976] select module: only use EVFILT_TIMER if available
	(kqueue backend)
Message-ID: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>


New submission from Benny Siegert :

When building python-2.6 on MirBSD, building the select module (which uses the kqueue backend on this platform) fails. This is because EVFILT_TIMER is not available on the platform.

The proposed patch is for python-2.6 but should apply to tip too.

This was discovered when building the python package from NetBSD pkgsrc, so the patch is taken from there.

----------
components: Extension Modules
files: patch-az
messages: 144022
nosy: bsiegert
priority: normal
severity: normal
status: open
title: select module: only use EVFILT_TIMER if available (kqueue backend)
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file23153/patch-az

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 15:16:52 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 14 Sep 2011 13:16:52 +0000
Subject: [issue12960] threading.Condition is not a class
In-Reply-To: <4E7065DF.3000703@haypocalc.com>
Message-ID: <4E70A939.2000704@rath.org>


Nikolaus Rath  added the comment:

On 09/14/2011 04:29 AM, STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
>> Yes, but further down it still says:
>>
>> """
>> class threading.Condition([lock])
>>
>>      If the lock argument is given and not None, [....]
>> """
> 
> What do you suggest? Replace it by class threading._Condition?

I don't have an optimal solution that would fit into the prescribed
layout. I think the best we can do is keep calling it class threading
Condition, but mention in the very first sentence that it isn't actually
a class:

class threading.Condition([lock]):

    threading.Condition is not actually a class but a factory function.
    The returned instance, however, is guaranteed to have the behaviour
    of a threading.Condition class as described here.

    If the lock argument...

Best,

   -Nikolaus

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 15:42:00 2011
From: report at bugs.python.org (Florian Ludwig)
Date: Wed, 14 Sep 2011 13:42:00 +0000
Subject: [issue12977] socket.socket.setblocking does not raise exception if no
	data available
Message-ID: <1316007719.98.0.0164178020562.issue12977@psf.upfronthosting.co.za>


New submission from Florian Ludwig :

The documentation states:

> In non-blocking mode, if a recv() call doesn?t find any data, [...], a error exception is raised; [0]

Which is wrong. If no data is available recv() does not raise an exception but returns an empty string.

[0] http://docs.python.org/library/socket.html#socket.socket.setblocking

----------
assignee: docs at python
components: Documentation
messages: 144024
nosy: Florian.Ludwig, docs at python
priority: normal
severity: normal
status: open
title: socket.socket.setblocking does not raise exception if no data available
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 16:15:30 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 14 Sep 2011 14:15:30 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1316009730.65.0.903138197773.issue11149@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

> Does the test suite catch this bug?

I think all of those fail due to the bug in pow():

20 tests failed:
    test_array test_builtin test_bytes test_decimal test_float
    test_fractions test_getargs2 test_index test_int test_itertools
    test_list test_long test_long_future test_math test_random test_re
    test_strtod test_tokenize test_types test_xrange

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 16:17:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Sep 2011 14:17:35 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 0f1e8c246a7b by Stefan Krah in branch '3.2':
Issue #11149: recent versions of clang require the -fwrapv flag.
http://hg.python.org/cpython/rev/0f1e8c246a7b

New changeset 637c67b34a1a by Stefan Krah in branch 'default':
Merge fix for issue #11149.
http://hg.python.org/cpython/rev/637c67b34a1a

New changeset feed6d2097b1 by Stefan Krah in branch '2.7':
Backport fix for issue #11149.
http://hg.python.org/cpython/rev/feed6d2097b1

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 17:10:27 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 14 Sep 2011 15:10:27 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: <1316013027.9.0.228331747934.issue12720@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

The OS X buildbots fail to compile posixmodule.c:

gcc -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE  -c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function ?try_getxattr?:
./Modules/posixmodule.c:10045: error: ?XATTR_SIZE_MAX? undeclared (first use in this function)
./Modules/posixmodule.c:10045: error: (Each undeclared identifier is reported only once
./Modules/posixmodule.c:10045: error: for each function it appears in.)
./Modules/posixmodule.c: In function ?getxattr_common?:
./Modules/posixmodule.c:10083: error: ?XATTR_SIZE_MAX? undeclared (first use in this function)
./Modules/posixmodule.c: In function ?posix_getxattr?:
./Modules/posixmodule.c:10101: warning: passing argument 3 of ?getxattr_common? from incompatible pointer type
./Modules/posixmodule.c: In function ?posix_lgetxattr?:
./Modules/posixmodule.c:10119: error: ?lgetxattr? undeclared (first use in this function)
./Modules/posixmodule.c: In function ?wrap_fgetxattr?:
./Modules/posixmodule.c:10129: error: too few arguments to function ?fgetxattr?
./Modules/posixmodule.c:10130: warning: control reaches end of non-void function
./Modules/posixmodule.c: In function ?posix_setxattr?:
./Modules/posixmodule.c:10165: error: too few arguments to function ?setxattr?
./Modules/posixmodule.c: In function ?posix_lsetxattr?:
./Modules/posixmodule.c:10190: warning: implicit declaration of function ?lsetxattr?
./Modules/posixmodule.c: In function ?posix_fsetxattr?:
./Modules/posixmodule.c:10216: error: too few arguments to function ?fsetxattr?
./Modules/posixmodule.c: In function ?posix_removexattr?:
./Modules/posixmodule.c:10239: error: too few arguments to function ?removexattr?
./Modules/posixmodule.c: In function ?posix_lremovexattr?:
./Modules/posixmodule.c:10262: warning: implicit declaration of function ?lremovexattr?
./Modules/posixmodule.c: In function ?posix_fremovexattr?:
./Modules/posixmodule.c:10285: error: too few arguments to function ?fremovexattr?
./Modules/posixmodule.c: In function ?listxattr_common?:
./Modules/posixmodule.c:10327: error: ?XATTR_LIST_MAX? undeclared (first use in this function)
./Modules/posixmodule.c: In function ?posix_listxattr?:
./Modules/posixmodule.c:10369: warning: passing argument 2 of ?listxattr_common? from incompatible pointer type
./Modules/posixmodule.c: In function ?posix_llistxattr?:
./Modules/posixmodule.c:10385: error: ?llistxattr? undeclared (first use in this function)
./Modules/posixmodule.c: In function ?wrap_flistxattr?:
./Modules/posixmodule.c:10394: error: too few arguments to function ?flistxattr?
./Modules/posixmodule.c:10395: warning: control reaches end of non-void function
./Modules/posixmodule.c: In function ?all_ins?:
./Modules/posixmodule.c:11342: error: ?XATTR_SIZE_MAX? undeclared (first use in this function)
make: *** [Modules/posixmodule.o] Error 1
program finished with exit code 2
elapsedTime=20.601350

----------
nosy: +skrah
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 17:35:26 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 14 Sep 2011 15:35:26 +0000
Subject: [issue12978] Figure out extended attributes on BSDs
Message-ID: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za>


New submission from Benjamin Peterson :

Extended attribute support currently exists in the os module for Linux. BSD's (including OSX) have a similar (but of course incompatible) interface. They should be exposed through the same functions. For example,

os.getxattr("myfile", "user.whatever")

should call on the C level

getxattr("myfile", "user.whatever", value, sizeof(value), 0, 0);

----------
messages: 144028
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: Figure out extended attributes on BSDs
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 17:46:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Sep 2011 15:46:23 +0000
Subject: [issue12720] Expose linux extended filesystem attributes
In-Reply-To: <1312921495.72.0.753559040108.issue12720@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset f325439d7f84 by Benjamin Peterson in branch 'default':
only compile xattrs on glibc (closes #12720)
http://hg.python.org/cpython/rev/f325439d7f84

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 18:13:53 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 14 Sep 2011 16:13:53 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1316016833.82.0.860738791123.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I'd prefer to disable the misbehaving functions entirely on arm.
With the patch this combination of tests now works:

  ./python -m test -uall test_posix test_nntplib


If you think the patch is good, I can run the whole test suite, too.
[I'd rather wait for review due to the slowness of the setup.]

----------
keywords: +patch
Added file: http://bugs.python.org/file23154/arm_setaffinity.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 19:03:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Sep 2011 17:03:06 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1316019786.87.0.86986748761.issue12936@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> I'd prefer to disable the misbehaving functions entirely on arm.

-10

If we start disabling features on platforms with partly bogus implementations, we might as well drop threading on OpenBSD, sendmsg() on OS-X, etc.

Furthermore, it's really just a libc bug, which might be fixed in a more recent version, or with another libc provider (eglibc, uclibc, etc.).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 19:29:06 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 14 Sep 2011 17:29:06 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1316021346.47.0.634499856637.issue7201@psf.upfronthosting.co.za>


Meador Inge  added the comment:

OK, I got an OABI system setup.  I am seeing the 'test_struct_return_2H' 
failure, which actually segfaults in my setup.  The difference does, 
indeed, seem like an ABI mismatch.

The test code that is failing has a Python side like:

   def test_struct_return_2H(self):
        class S2H(Structure):
            _fields_ = [("x", c_short),
                        ("y", c_short)]
        dll.ret_2h_func.restype = S2H
        dll.ret_2h_func.argtypes = [S2H]
        inp = S2H(99, 88)
        s2h = dll.ret_2h_func(inp)
        self.assertEqual((s2h.x, s2h.y), (99*2, 88*3))

and a C code side that looks like:

   typedef struct {
      short x;
      short y;
   } S2H;

   S2H ret_2h_func(S2H inp)
   {
      inp.x *= 2;
      inp.y *= 3;
      return inp;
   }

The APCS Section 5.4 Result Return [1], says:

"""
A Composite Type not larger than 4 bytes is returned in r0.  The format 
is as if the result had been stored in memory at a word-aligned address 
and then loaded into r0 with an LDR instruction.  Any bits in r0 that 
lie outside the bounds of the result have unspecified values.
"""

The EABI implementation does exactly this and packs the structure into r0, where as the OABI implementation places the address of a structure in r0.  'ctypes' is assuming the former and on an OABI system the contents of r0 are treated as an address, where they are actually a value.  Boom goes the dynamite.

I am looking into 'test_endian_double' and 
'test_unaligned_native_struct_fields' now.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 20:06:24 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 14 Sep 2011 18:06:24 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1316023584.91.0.936946947716.issue7201@psf.upfronthosting.co.za>


Meador Inge  added the comment:

The 'test_endian_double' test fails because the 'double' floating-point 
type for an interpreter built for OABI is unknown:

>>> float.__getformat__("float")
'IEEE, little-endian'
>>> float.__getformat__("double")
'unknown'

According to [1], the double format discrepancies seem to be expected.

[1] http://wiki.debian.org/ArmEabiPort#ARM_floating_points

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 20:31:46 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Sep 2011 18:31:46 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316025106.88.0.739849109774.issue12973@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Here's a simple patch.  Is anyone in a good position to see if this fixes the tests failures for Clang (without the fwrapv flag)?

----------
keywords: +patch
Added file: http://bugs.python.org/file23155/issue12975.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 20:36:31 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Sep 2011 18:36:31 +0000
Subject: [issue12978] Figure out extended attributes on BSDs
In-Reply-To: <1316014526.21.0.982877507813.issue12978@psf.upfronthosting.co.za>
Message-ID: <1316025391.61.0.845045519044.issue12978@psf.upfronthosting.co.za>


Ned Deily  added the comment:

Have you looked at Bob Ippolito's xattr module which has been out for some time and wraps Linux, OS X, BSD, and Solaris extended attributes?

http://pypi.python.org/pypi/xattr

----------
nosy: +ned.deily

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 20:39:32 2011
From: report at bugs.python.org (ilikepython)
Date: Wed, 14 Sep 2011 18:39:32 +0000
Subject: [issue12979] tkinter.font.Font object not usable as font option
Message-ID: <1316025572.88.0.893423233334.issue12979@psf.upfronthosting.co.za>


New submission from ilikepython :

If a Font object is passed as a font option to a Tk widget e. g.:

import tkinter
import tkinter.font

f = tkinter.font.Font(family='Arial', size=30)
root = Tk()
label = tkinter.Label(root, text="Hello", font=f)
label.pack()

the font does not get respected at runtime.

----------
messages: 144036
nosy: ilikepython
priority: normal
severity: normal
status: open
title: tkinter.font.Font object not usable as font option
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 20:48:37 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Sep 2011 18:48:37 +0000
Subject: [issue12976] select module: only use EVFILT_TIMER if available
	(kqueue backend)
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316026117.75.0.79861141329.issue12976@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

Hello,

According to http://fxr.watson.org/fxr/ident?v=NETBSD;im=3;i=EVFILT_TIMER EVFILT_TIMER is defined on NetBSD.
As for MirBSD, with all due respect, it really looks like a niche platform, definitely not officially supported by Python.
Of course, this patch is so trivial and small that it can easily be merged, but it would be nice if MirBSD defined it in its header file instead (it's not the first problem due to kqueue-incompatibilities between on BSD platforms, see for example issue #12181 and issue #6419).

----------
nosy: +haypo, neologix

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 20:56:20 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 18:56:20 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316026580.53.0.640441337688.issue12973@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

I removed -fwrapv from configure and Makefile, but I'm unable to reproduce the issue with clang 2.8 on x86_64 (Fedora 15).

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 20:57:37 2011
From: report at bugs.python.org (Benny Siegert)
Date: Wed, 14 Sep 2011 18:57:37 +0000
Subject: [issue12976] select module: only use EVFILT_TIMER if available
	(kqueue backend)
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316026657.36.0.324392551843.issue12976@psf.upfronthosting.co.za>


Benny Siegert  added the comment:

There are actually only two things that need to be touched for supporting MirBSD: This and the Configure script. I was planning to submit the Configure patches separately, I just started with this patch as it is so trivial.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:06:40 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Sep 2011 19:06:40 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316027200.56.0.679713695896.issue12973@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Thanks Victor; I just managed to install Clang, and it looks I can reproduce the failures.  I'm testing right now to see if the patch fixes them all...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:09:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 19:09:00 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316027340.1.0.866124389175.issue12973@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> Thanks Victor; I just managed to install Clang,
> and it looks I can reproduce the failures.

What is your clang version? I ran ./python -m test -v test_long to check the issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:17:55 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 14 Sep 2011 19:17:55 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316027875.09.0.0507152865398.issue12973@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

I've got Clang from MacPorts, on OS X 10.6.8.

iwasawa:cpython mdickinson$ clang --version
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-apple-darwin10
Thread model: posix

Without the patch (and before the -fwrapv inclusion), I get the following failures:

20 tests failed:
    test_array test_builtin test_bytes test_ctypes test_float
    test_fractions test_getargs2 test_index test_int test_itertools
    test_list test_long test_long_future test_math test_random test_re
    test_strtod test_tokenize test_types test_xrange

... and also test_decimal, which I had to delete because the failure caused the test run to hang.

With the patch, only test_ctypes is failing, for reasons that I presume are unrelated to int_pow.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:27:15 2011
From: report at bugs.python.org (Andrew Grover)
Date: Wed, 14 Sep 2011 19:27:15 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1316028435.19.0.657771238902.issue6560@psf.upfronthosting.co.za>


Changes by Andrew Grover :


----------
nosy:  -Andrew.Grover

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:32:20 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Sep 2011 19:32:20 +0000
Subject: [issue12976] select module: only use EVFILT_TIMER if available
	(kqueue backend)
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316028740.66.0.833619834711.issue12976@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

Since this patch alone won't be enough to support MirBSD (and is required only for MirBSD), I suggest you to post the complete patch, and rename this issue "add support for MirBSD platform", or something along those lines.
That way, we can consider this as a feature request, and apply it in one chunk, if accepted.
However, I think that the current consensus is somewhat hostile to adding support for so-called "exotic platforms", so I can't guarantee this will be included (posting the whole patch will certainly help making a decision).
I'm adding Martin to the noisy list, he'll probably give you more insight on this.

----------
nosy: +loewis

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:34:13 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 19:34:13 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316028853.12.0.610493401695.issue12973@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

Aaaah, int_pow. I was testing Python 3.3.

I tested Python 2.7 with clang 2.8, optimization level at -03 and without -fwrapv... I'm still unable to reproduce the issue. It's maybe an optimization introduced by clang 2.9.

--

This issue remembers me the great "What Every C Programmer Should Know About Undefined Behavior" article serie (3 parts).

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html

See also this tool to detect such bug:
http://blog.regehr.org/archives/508

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:36:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 19:36:33 +0000
Subject: [issue12980] segfault in test_json on AMD64 FreeBSD 8.2 2.7
Message-ID: <1316028993.76.0.263196651772.issue12980@psf.upfronthosting.co.za>


New submission from STINNER Victor :

http://www.python.org/dev/buildbot/all/builders/AMD64%20FreeBSD%208.2%202.7/builds/301

---------------------------------------------
[ 44/359] test_json
Fatal Python error: Segmentation fault

Current thread 0x00000008010041c0:
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 420 in _iterencode
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 309 in _iterencode_list
  File "/usr/home/buildbot/buildarea/2.7.krah-freebsd/build/Lib/json/encoder.py", line 408 in _iterencode
  ...
*** Signal 11
---------------------------------------------

Can it be an unlimited loop (recursive loop)? It looks like a stack overflow.

----------
components: Library (Lib)
messages: 144045
nosy: ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: segfault in test_json on AMD64 FreeBSD 8.2 2.7
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:50:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 19:50:21 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1316029821.76.0.671844247097.issue11149@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

The new issue #12980 may be a regression introduced by this issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:51:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 14 Sep 2011 19:51:24 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
Message-ID: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali :

Now that sendmsg()/recvmsg() are exposed in socketmodule, we could use them to replace the ad-hoc FD-passing routines used by multiprocessing.reduction.
Antoine suggested adding sendfd()/recvfd() methods to socket objects, but I'm not sure about this, since those only make sense for Unix domain sockets.
Two remarks on the patch attached:
- this removes sendfd()/recvfd() from _multiprocessing (but AFAICT those were never documented as part of the public API)
- EOF/invalid data received result in a RuntimeError

----------
components: Library (Lib)
files: multiprocessing_fd.diff
keywords: patch
messages: 144047
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: rewrite multiprocessing (senfd|recvfd) in Python
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file23156/multiprocessing_fd.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:52:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 19:52:48 +0000
Subject: [issue12976] select module: only use EVFILT_TIMER if available
	(kqueue backend)
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316029968.03.0.597425863271.issue12976@psf.upfronthosting.co.za>


Changes by STINNER Victor :


_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 21:55:47 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 14 Sep 2011 19:55:47 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1316030147.36.0.261750095038.issue11149@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

No, that's me playing around. I tried to use clang as the compiler
for the build slave. I can't figure out yet why the segfaults occur.

When I'm running the test manually, everything seems to work.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 22:32:43 2011
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Wed, 14 Sep 2011 20:32:43 +0000
Subject: [issue12982] .pyo file cannot be imported
Message-ID: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>


New submission from Eric O. LEBIGOT :

When creating a .pyo file (either with -O or -OO) and removing any .pyc or .py original file, import  complains with "No module called ".  The import does work with .pyc files.

I'm not sure that this is the correct behavior, as the documentation does not seem to make any difference between .pyc and .pyo files on this point:

"It is possible to have a file called spam.pyc (or spam.pyo when -O is used) without a file spam.py for the same module. This can be used to distribute a library of Python code in a form that is moderately hard to reverse engineer."

----------
components: Interpreter Core
messages: 144049
nosy: lebigot
priority: normal
severity: normal
status: open
title: .pyo file cannot be imported
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 22:35:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 20:35:14 +0000
Subject: [issue12982] .pyo file cannot be imported
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1316032514.71.0.656157067967.issue12982@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

You need to run Python with -O command line option to ask Python to search for *.pyo files.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 22:55:38 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 20:55:38 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1316033738.48.0.967220615254.issue12678@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

test_packaging is still failing on Windows, example:

======================================================================
ERROR: test_uses (packaging.tests.test_database.TestDistribution)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\tests\test_database.py", line 148, in setUp
    os.path.join(distinfo_dir, file)))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\packaging\tests\test_database.py", line 36, in record_pieces
    path = relpath(file, sys.prefix)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\ntpath.py", line 622, in relpath
    raise ValueError(error)
ValueError: path is on mount 'c:', start on mount 'D:'

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5186/steps/test/logs/stdio

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 23:14:15 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Wed, 14 Sep 2011 21:14:15 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1316034855.26.0.127176212827.issue12678@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

Issue 12785 has a patch for the test_database failures.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 23:52:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 21:52:29 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <201109142352.12695.victor.stinner@haypocalc.com>


STINNER Victor  added the comment:

I don't think that it's a problem to remove private functions.

Is it mandatory to send a non-empty message (first argument for sendmsg, b'x' 
in your patch)? The original C function sends a random byte :-)

multiprocessing_recvfd() contains cmsg_level=SOL_SOCKET and 
cmsg_type=SCM_RIGHTS, your Python function doesn't check cmsg_level or 
cmsg_type. Should it be checked?

I don't know sendmsg/recvmsg API. Do they guarantee to send/receive all data?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 23:53:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 21:53:04 +0000
Subject: [issue12980] segfault in test_json on AMD64 FreeBSD 8.2 2.7
In-Reply-To: <1316028993.76.0.263196651772.issue12980@psf.upfronthosting.co.za>
Message-ID: <1316037184.14.0.756183493343.issue12980@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 23:54:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Sep 2011 21:54:10 +0000
Subject: [issue12980] segfault in test_json on AMD64 FreeBSD 8.2 2.7
In-Reply-To: <1316028993.76.0.263196651772.issue12980@psf.upfronthosting.co.za>
Message-ID: <1316037250.52.0.11833823456.issue12980@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

I ran test_json (and then the full test suite using make buildbottest) on FreeBSD 8.2, with Python compiled by clang 2.8, and I'm unable to reproduce the bug.

@skrah: Feel free to close the issue if we cannot reproduce it outside your buildbot :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 14 23:57:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Sep 2011 21:57:31 +0000
Subject: [issue9871] IDLE dies when using some regex
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset e74860883a9c by Ned Deily in branch '3.2':
Issue #9871: Prevent IDLE 3 crash when given byte stings
http://hg.python.org/cpython/rev/e74860883a9c

New changeset fe6c7771c25c by Ned Deily in branch 'default':
Issue #9871: Prevent IDLE 3 crash when given byte stings
http://hg.python.org/cpython/rev/fe6c7771c25c

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 00:03:27 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Sep 2011 22:03:27 +0000
Subject: [issue9871] IDLE 3 crashes processing byte strings with invalid hex
	escape sequences
In-Reply-To: <1284627325.17.0.642526416241.issue9871@psf.upfronthosting.co.za>
Message-ID: <1316037807.07.0.136263547913.issue9871@psf.upfronthosting.co.za>


Ned Deily  added the comment:

Thanks for your suggested patch!  A similar change was needed in idle lib/ScriptBinding.py to handle the same case for script files in edit windows.  Applied in 3.2 (for 3.2.3) and default (for 3.3).

----------
assignee:  -> ned.deily
nosy: +ned.deily
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
title: IDLE dies when using some regex -> IDLE 3 crashes processing byte strings with invalid hex escape sequences
versions: +Python 3.3 -Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 00:04:33 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 14 Sep 2011 22:04:33 +0000
Subject: [issue12980] segfault in test_json on AMD64 FreeBSD 8.2 2.7
In-Reply-To: <1316028993.76.0.263196651772.issue12980@psf.upfronthosting.co.za>
Message-ID: <1316037873.22.0.64519536473.issue12980@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I'm completely puzzled by this. I ran *all* tests manually on the same
machine with clang with the same parameters as the buildbot
(--with-pydebug, make buildbottest) and they pass.

I reverted the buildbot to gcc, it'll be green again soon.

Closing, since it can't be reproduced.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 00:33:13 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 14 Sep 2011 22:33:13 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316039593.79.0.864032884704.issue12973@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

== CPython 2.7.2+ (2.7:a698ad2741da+, Sep 15 2011, 00:17:28) [GCC 4.2.1 Compatible Clang 3.0 (trunk 139637)]
==   FreeBSD-8.0-RELEASE-amd64-64bit-ELF little-endian
==   /usr/home/stefan/pydev/cpython/build/test_python_71451

With clang 3.0 from trunk, the pow() failures are fixed. I still get:

test test_itertools failed -- Traceback (most recent call last):
  File "/usr/home/stefan/pydev/cpython/Lib/test/test_itertools.py", line 788, in test_islice
    self.assertEqual(len(list(islice(count(), 1, 10, maxsize))), 1)
AssertionError: 3 != 1


test test_list failed -- Traceback (most recent call last):
  File "/usr/home/stefan/pydev/cpython/Lib/test/test_list.py", line 59, in test_overflow
    self.assertRaises((MemoryError, OverflowError), mul, lst, n)
AssertionError: (, ) not raised



But these are exactly the failures from 3.x. so they are probably
unrelated to this issue (and they are "fixed" by -fwrapv).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 00:51:36 2011
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Sep 2011 22:51:36 +0000
Subject: [issue12983] byte string literals with invalid hex escape codes raise
	ValueError instead of SyntaxError
Message-ID: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za>


New submission from Ned Deily :

In behavior carried over from Python 2 string literals, Python 3 byte string literals raise a less helpful ValueError exception when an invalid hex escape code is given:

    >>> x = b'\x0'
    ValueError: invalid \x escape

A string literal raises a SyntaxError and a full traceback including line number:

    >>> x = '\x0'
      File "", line 1
    SyntaxError: (unicode error) 'unicodeescape' codec can't decode
     bytes in position 0-2: end of string in escape sequence

----------
components: Interpreter Core
messages: 144059
nosy: ned.deily
priority: normal
severity: normal
status: open
title: byte string literals with invalid hex escape codes raise ValueError instead of SyntaxError
type: behavior
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 01:11:48 2011
From: report at bugs.python.org (Matthew Newcomb)
Date: Wed, 14 Sep 2011 23:11:48 +0000
Subject: [issue12984] XML NamedNodeMap ( attribName in NamedNodeMap fails )
Message-ID: <1316041908.49.0.966708119681.issue12984@psf.upfronthosting.co.za>


New submission from Matthew Newcomb :

I was cleaning up some old code to make it pep8 compliant and came across this bug.  Switching from 'has_key' to 'in' does not work with a xml.dom.minidom.NamedNodeMap.  An easy solution appears to be to add a '__contains__' method to NamedNodeMap.  

This is with:
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24) 
[GCC 4.5.2] on linux2

I've tried it with 2.4.3 as well ( on some older machines ).

import xml.dom.minidom

def show_bug():
    document = 'foobar_attributes'
    dom = xml.dom.minidom.parseString(document)
    attribs = dom.getElementsByTagName('dom')[0].attributes

    if attribs.has_key('mbid'):
        print "This works..  found 'mbid' attribute"

    if 'mbid' in attribs:
        print "Will never get here, the above will throw an exception"


>>> show_bug()
This works..  found 'mbid' attribute
Traceback (most recent call last):
  File "", line 1, in 
  File "show_bug.py", line 11, in show_bug
    if 'mbid' in attribs:
  File "/usr/lib/python2.7/xml/dom/minidom.py", line 524, in __getitem__
    return self._attrs[attname_or_tuple]
KeyError: 0

----------
components: XML
files: show_bug.py
messages: 144060
nosy: spolematt
priority: normal
severity: normal
status: open
title: XML NamedNodeMap ( attribName in NamedNodeMap fails )
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file23157/show_bug.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 02:29:48 2011
From: report at bugs.python.org (David Lam)
Date: Thu, 15 Sep 2011 00:29:48 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1316046588.63.0.763803137504.issue12537@psf.upfronthosting.co.za>


David Lam  added the comment:

Hi hi, noob here. I found this today after clicking 'Easy issues' link. 

Would something like this work?  test_mailbox.py seems to pass. However, I'm not too sure what more needs to be done in the _explain_to. It seems like everything to convert headers/flags between message formats are already there ?


diff -r 63bf3bae20ef Lib/mailbox.py
--- a/Lib/mailbox.py    Wed Sep 14 11:46:17 2011 -0400
+++ b/Lib/mailbox.py    Wed Sep 14 17:12:51 2011 -0700
@@ -1467,8 +1467,7 @@
 
     def _become_message(self, message):
         """Assume the non-format-specific state of message."""
-        for name in ('_headers', '_unixfrom', '_payload', '_charset',
-                     'preamble', 'epilogue', 'defects', '_default_type'):
+        for name in message.__dict__:
             self.__dict__[name] = message.__dict__[name]

----------
nosy: +dlam

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 03:12:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Sep 2011 01:12:10 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1316049130.91.0.278392088991.issue1172711@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

@meadori: please write the version of your patch directly in the filename. For example, I use the pattern: name.patch, name-2.patch, name-3.patch, ...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 03:27:10 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Sep 2011 01:27:10 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1316050030.24.0.326949502315.issue12537@psf.upfronthosting.co.za>


R. David Murray  added the comment:

That is the first step, yes.  In addition to that we need to have the various explain_to methods delete the special attributes that aren't valid for the new Message subtype.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 05:17:26 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Sep 2011 03:17:26 +0000
Subject: [issue12983] byte string literals with invalid hex escape codes raise
	ValueError instead of SyntaxError
In-Reply-To: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za>
Message-ID: <1316056646.79.0.676345571869.issue12983@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 07:38:08 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 15 Sep 2011 05:38:08 +0000
Subject: [issue12857] Expose called function on frame object
In-Reply-To: <1314683667.85.0.876885324202.issue12857@psf.upfronthosting.co.za>
Message-ID: <1316065088.26.0.0235399001527.issue12857@psf.upfronthosting.co.za>


Eric Snow  added the comment:

Nick, does thing look better?

----------
nosy: +ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 08:12:44 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 15 Sep 2011 06:12:44 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316067164.92.0.858913639442.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda :


Added file: http://bugs.python.org/file23158/95016f363e6c.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 08:54:39 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 15 Sep 2011 06:54:39 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <201109142352.12695.victor.stinner@haypocalc.com>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

> I don't think that it's a problem to remove private functions.
>

Alright.

> Is it mandatory to send a non-empty message (first argument for sendmsg, b'x'
> in your patch)? The original C function sends a random byte :-)
>

Some implementation can return EINVAL if no data is sent (i.e. you
can't send only ancillary data).

> multiprocessing_recvfd() contains cmsg_level=SOL_SOCKET and
> cmsg_type=SCM_RIGHTS, your Python function doesn't check cmsg_level or
> cmsg_type. Should it be checked?
>

Yes, it should be checked, I'll update the patch.

> I don't know sendmsg/recvmsg API. Do they guarantee to send/receive all data?
>

For data no, but ancillary data, yes. The only thing that could go
wrong would be a buffer too short to hold the ancillary data, but:
- the buffer size is computed with CMSG_DATA(), so it should be enough
- if the ancillay data is truncated, struct.unpack will raise an exception

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 10:00:33 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 15 Sep 2011 08:00:33 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316073633.67.0.727642943662.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda :


Added file: http://bugs.python.org/file23159/3017ee1d548d.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 10:12:33 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 15 Sep 2011 08:12:33 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316074353.95.0.0705091957572.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda :


Removed file: http://bugs.python.org/file23063/f3cf187208ea.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 10:13:01 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 15 Sep 2011 08:13:01 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316074381.13.0.358632248171.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda :


Removed file: http://bugs.python.org/file23129/fe2c9998f329.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 10:13:31 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 15 Sep 2011 08:13:31 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316074411.15.0.345841359125.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda :


Removed file: http://bugs.python.org/file23158/95016f363e6c.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 10:15:20 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 15 Sep 2011 08:15:20 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316074520.65.0.218158239097.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

I've attached another patch that includes proper ReST documentation, a
few more tests, and some fixups following Ezio and Amaury's reviews.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 10:39:46 2011
From: report at bugs.python.org (Eric O. LEBIGOT)
Date: Thu, 15 Sep 2011 08:39:46 +0000
Subject: [issue12982] .pyo file cannot be imported
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1316075986.48.0.999988234622.issue12982@psf.upfronthosting.co.za>


Eric O. LEBIGOT  added the comment:

Indeed.  Thanks.  I wish it had been in the documentation. :)  This is yet another reason for me to check how I can submit patches to the doc. :)

I also found out that renaming the .pyo file as .pyc makes Python happy upon import.  That's the solution I chose, because I don't want users to have to type "python -O" when calling programs compiled with -O or -OO.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 11:11:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Sep 2011 09:11:16 +0000
Subject: [issue12982] .pyo file cannot be imported
In-Reply-To: <1316075986.48.0.999988234622.issue12982@psf.upfronthosting.co.za>
Message-ID: <4E71C135.5030904@haypocalc.com>


STINNER Victor  added the comment:

> Indeed.  Thanks.  I wish it had been in the documentation. :)  This is yet another reason for me to check how I can submit patches to the doc. :)

Read http://docs.python.org/devguide/ to learn how to get the source of 
the documentation and how to write a patch.

> I also found out that renaming the .pyo file as .pyc makes Python happy upon import.  That's the solution I chose, because I don't want users to have to type "python -O" when calling programs compiled with -O or -OO.

Oh, I didn't know this trick, but yeah PYO and PYC are basically the 
same thing. The main difference is that PYO doesn't contain docstrings 
and doesn't contain "set the current line to ..." bytecode instructions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 11:12:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Sep 2011 09:12:16 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: 
Message-ID: <4E71C179.3060309@haypocalc.com>


STINNER Victor  added the comment:

> - if the ancillay data is truncated, struct.unpack will raise an exception

Well, the current C code doesn't check that the data is truncated and it 
works correctly, so I don't think that it would be different in Python. 
And yes, Python adds an extra check thanks to struct.unpack.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 11:18:27 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Sep 2011 09:18:27 +0000
Subject: [issue11149] [PATCH] Configure should enable -fwrapv for clang
In-Reply-To: <1297162007.28.0.193963502998.issue11149@psf.upfronthosting.co.za>
Message-ID: <1316078307.09.0.603520102448.issue11149@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

The buildbots are fine, though I think that in this instance
Gentoo-Non-Debug-3.x is the only bot that actually exercises
the new code path.

So I tested manually on FreeBSD/clang-3.0 and I don't see
anything surprising.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 11:34:37 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Sep 2011 09:34:37 +0000
Subject: [issue12985] Check signed arithmetic overflow in ./configure
Message-ID: <1316079277.71.0.960663177072.issue12985@psf.upfronthosting.co.za>


New submission from Stefan Krah :

I'm not sure if this is a good idea: I wonder if it would be an option
to check for overflow behavior at the bottom of ./configure and print a
warning. The patch appears to work for gcc, clang and suncc. It would
have caught the problem in #12973.


The Intel compiler is the odd one here. Even with -O0 this particular
overflow is undefined, but I can't remember seeing the specific
test failures from #12973. So the drawback is that the patch might
give false positives.



$ cat overflow_is_defined.c
#include 
int overflow_is_defined(int x) {
    if (x + 1000 < x)
        return 0;
    return 1;
}
int main() {
    return overflow_is_defined(INT_MAX);
}



gcc-4.4.3
=========

$ gcc -Wall -W -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ gcc -Wall -W -O2 -o overflow_is_defined overflow_is_defined.c
overflow_is_defined.c: In function ?overflow_is_defined?:
overflow_is_defined.c:3: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false
$ ./overflow_is_defined || echo "undefined"
undefined
$ gcc -Wall -W -O2 -fwrapv -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$

clang-3.0
=========

$ clang -Wall -W -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ clang -Wall -W -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$ clang -Wall -W -fwrapv -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$

suncc-12.2
==========

$ suncc -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ suncc -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$

icc-12.0.0
==========

$ icc -Wall -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$ icc -Wall -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$

----------
files: configure_catch_overflow.diff
keywords: patch
messages: 144071
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Check signed arithmetic overflow in ./configure
type: feature request
Added file: http://bugs.python.org/file23160/configure_catch_overflow.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 11:39:55 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Sep 2011 09:39:55 +0000
Subject: [issue12985] Check signed arithmetic overflow in ./configure
In-Reply-To: <1316079277.71.0.960663177072.issue12985@psf.upfronthosting.co.za>
Message-ID: <1316079595.72.0.957052539308.issue12985@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 13:12:59 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Sep 2011 11:12:59 +0000
Subject: [issue12985] Check signed arithmetic overflow in ./configure
In-Reply-To: <1316079277.71.0.960663177072.issue12985@psf.upfronthosting.co.za>
Message-ID: <1316085179.18.0.417489549576.issue12985@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

I don't see how this is helpful---all it's reporting on is whether that compiler happened to decide to optimize away that particular comparison;  something which is going to be highly dependent on compiler version, flags, platform, etc., and still doesn't tell us anything about whether that compiler guarantees to wrap all signed integer overflows.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 13:16:39 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Sep 2011 11:16:39 +0000
Subject: [issue12985] Check signed arithmetic overflow in ./configure
In-Reply-To: <1316079277.71.0.960663177072.issue12985@psf.upfronthosting.co.za>
Message-ID: <1316085399.35.0.882775814031.issue12985@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

BTW, I suspect that the reason there were no related test failures with the Intel compiler is that most of the problems in the Python code stem from multiplications rather than additions.  Probably icc isn't sophisticated enough to optimize those multiplication + division checks away.

Seems like we should probably be looking for an icc flag that forces wrapping on signed integer overflow.

In the long run, it would still be good to eliminate the need for fwrapv and the like;  it can have a significant performance hit (in theory;  haven't done any timings recently).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 13:25:14 2011
From: report at bugs.python.org (Andrew Jewett)
Date: Thu, 15 Sep 2011 11:25:14 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1316085914.5.0.437382682382.issue1170@psf.upfronthosting.co.za>


Andrew Jewett  added the comment:

Proposed solution and patch to follow.  Please let me know if I am posting it in the wrong place.

The main problem with shlex is that the shlex interface is inadequate to handle unicode.  Specifically it is no longer feasible to provide a list of every possible character that the user could want to appear within a token.  Suppose the user wants the ability to parse words in simplified Chinese.  If I understand correctly, then currently, they would have to set "self.wordchars" to a string (or some other container) of 6000 (unicode) characters, and this enormous string would need to be searched each time a new character is read.  This was a problem with shlex from the beginning, but it became more acute when support for unicode was added.  Generally, in some cases, it is much more convenient instead to specify a short list of characters you -don't- want to appear in a word (word delimiters), than to list all the characters you do.

An obvious (although perhaps not optimal) solution is to add an additional data member to shlex, consisting of the characters which terminate the reading of a token.  (In other words, the set-inverse of wordchars.)  In the attached example code, I call it "self.wordterminators".  To remain backwards-compatible with shlex, self.wordterminators is empty by default.  But if not-empty, self.wordterminators overrides self.wordchars.

I've been distributing a customized version of shlex with my own software which implements this modest change (shlex_wt).  (See attachment.)  It is otherwise identical to the version of shlex.py that ships with python 3.2.2.  (It has been further modified only slightly to be compatible with both python 2.7 and python 3.)  It's not beautiful code, but it seems to be a successful kluge for this particular issue.  I don't know if it makes a worthy patch, but perhaps somebody out there finds it useful.  To make it easy to spot the changes, each of the lines I changed ends in a comment "#WORDTERMINATORS".  (There are only 15 of these lines.)
-Andrew Jewett

----------
nosy: +wombat
versions:  -Python 2.7
Added file: http://bugs.python.org/file23161/shlex_wt.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 13:33:16 2011
From: report at bugs.python.org (Darren Dale)
Date: Thu, 15 Sep 2011 11:33:16 +0000
Subject: [issue11610] Improved support for abstract base classes with
	descriptors
In-Reply-To: <1300560551.62.0.116291646024.issue11610@psf.upfronthosting.co.za>
Message-ID: <1316086396.72.0.554008977402.issue11610@psf.upfronthosting.co.za>


Darren Dale  added the comment:

Any additional comments?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 13:38:43 2011
From: report at bugs.python.org (Andrew Jewett)
Date: Thu, 15 Sep 2011 11:38:43 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1316086723.12.0.210805847581.issue1170@psf.upfronthosting.co.za>


Andrew Jewett  added the comment:

Not to get side-tracked, but on a related note, it would be nice if there was a python module which defined sets of unicode characters corresponding to different categories (similar to the categories listed here: http://www.fileformat.info/info/unicode/category/index.htm)
That way, for example, if the user wants to categorically ignore ALL mathematical symbols or punctuation marks, they could assign: 

self.wordterminators = unicode_math + unicode_punctuation.
(The + means set union.)

If somebody tried to specify all of them manually, this would be painful.  There are hundreds of punctuation symbols in unicode, for example.  (I suppose most of the time, one does not need to be so thorough.  This feature not really necessary for getting shlex to work.  But I think this would be a easy feature to add.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 14:00:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Sep 2011 12:00:21 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1316088021.87.0.929747212198.issue1170@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

That can be done programmatically using the unicodedata module.  The regex module (that will hopefully be include in 3.3) is also able to match characters that belongs to specific categories.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 14:28:08 2011
From: report at bugs.python.org (John Chandler)
Date: Thu, 15 Sep 2011 12:28:08 +0000
Subject: [issue12820] Tests for Lib/xml/dom/minicompat.py
In-Reply-To: <1314071659.09.0.625804560965.issue12820@psf.upfronthosting.co.za>
Message-ID: <1316089688.51.0.724542007153.issue12820@psf.upfronthosting.co.za>


John Chandler  added the comment:

Just to let you know I haven't forgotten this! I've been pretty busy recently so might be a while before I implement the changes to the patch suggested in the code review.

John

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 16:22:56 2011
From: report at bugs.python.org (Evgeny Kapun)
Date: Thu, 15 Sep 2011 14:22:56 +0000
Subject: [issue12983] byte string literals with invalid hex escape codes raise
	ValueError instead of SyntaxError
In-Reply-To: <1316040696.89.0.548775164505.issue12983@psf.upfronthosting.co.za>
Message-ID: <1316096576.89.0.146892116435.issue12983@psf.upfronthosting.co.za>


Changes by Evgeny Kapun :


----------
nosy: +abacabadabacaba

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 16:39:29 2011
From: report at bugs.python.org (Evgeny Kapun)
Date: Thu, 15 Sep 2011 14:39:29 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1316097569.85.0.999782444383.issue12729@psf.upfronthosting.co.za>


Changes by Evgeny Kapun :


----------
nosy: +abacabadabacaba

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 16:47:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Sep 2011 14:47:38 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1316098058.22.0.504912931251.issue12967@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


Removed file: http://bugs.python.org/file23147/unnamed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 16:49:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Sep 2011 14:49:52 +0000
Subject: [issue10968] threading.Timer should be a class so that it can be
	derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1316098192.35.0.120355385592.issue10968@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Victor: Yes, I know the doc needs an update, that?s why I posted a patch six weeks ago and asked for a review.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 16:50:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Sep 2011 14:50:33 +0000
Subject: [issue12960] threading.Condition is not a class
In-Reply-To: <1315748239.01.0.928739848932.issue12960@psf.upfronthosting.co.za>
Message-ID: <1316098233.82.0.615767026934.issue12960@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
versions:  -Python 2.6, Python 3.1, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 16:53:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Sep 2011 14:53:48 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1316098428.82.0.0551903837069.issue1170@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Andrew: Thanks for your contribution, but your patch cannot go into 2.7, as we don?t add new features in stable versions (re-read the whole thread if you need more info).  This report is still open because we need a doc patch to explain how to work around that.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 16:54:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Sep 2011 14:54:18 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1316098458.44.0.608490404504.issue12967@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> when installing the distribute package
How?  Please tell exactly what command you ran with what Python version.

> it could be raised on any other usage as sys.stdout does not have
> an 'error' attribute.
It does, in 3.x.  Do you think Python has no tests or no users? :)

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 16:56:02 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Sep 2011 14:56:02 +0000
Subject: [issue10968] threading.Timer should be a class so that it can be
	derived
In-Reply-To: <1295574501.95.0.0935688829986.issue10968@psf.upfronthosting.co.za>
Message-ID: <1316098562.98.0.903755311341.issue10968@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> that?s why I posted a patch six weeks ago and asked for a review

Oh ok, cool, I missed the patches.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 17:00:05 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 15 Sep 2011 15:00:05 +0000
Subject: [issue12976] select module: only use EVFILT_TIMER if available
	(kqueue backend)
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316098805.47.0.377631081527.issue12976@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 18:01:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Sep 2011 16:01:06 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1316102466.12.0.617450126798.issue5689@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
components: +Library (Lib) -Extension Modules
nosy: +nadeem.vawda
title: please support lzma compression as an extension and in	the tarfile module -> Support xz compression in tarfile module
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 18:03:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 15 Sep 2011 16:03:53 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1316102633.81.0.373921365618.issue828450@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I?ve just found another problem with MANIFEST files created in Windows: they use CRLF.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 18:13:24 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 15 Sep 2011 16:13:24 +0000
Subject: [issue5689] Support xz compression in tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1316103204.53.0.867503738872.issue5689@psf.upfronthosting.co.za>


Lars Gust?bel  added the comment:

Attached is a patch with the current state of my work on lzma integration into tarfile (17 test errors).

----------
assignee:  -> lars.gustaebel
keywords: +patch
Added file: http://bugs.python.org/file23162/2011-09-15-tarfile-lzma.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 18:14:16 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Thu, 15 Sep 2011 16:14:16 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316103256.93.0.161325210701.issue6715@psf.upfronthosting.co.za>


Lars Gust?bel  added the comment:

Today I played around with lzma support for tarfile based on your last patch (see issue5689). There are a few minor issues that I just wanted to mention, as they break the tarfile testsuite:

- LZMAFile does not expose a name attribute. BZ2File doesn't either (not in 3.x anyway), but GzipFile does.
- LZMAFile does not allow a 'b' in the mode argument, unlike GzipFile and BZ2File.
- The bz2 module exposes many error conditions as standard Python exceptions, e.g. IOError, EOFError. The lzma module uses LZMAError for all errors without distinction.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 18:19:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Sep 2011 16:19:42 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset c6d52971dd2a by ?ric Araujo in branch 'default':
Fix packaging.database.Distribution.list_distinfo_files (#12785).
http://hg.python.org/cpython/rev/c6d52971dd2a

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 18:30:17 2011
From: report at bugs.python.org (Matt Chaput)
Date: Thu, 15 Sep 2011 16:30:17 +0000
Subject: [issue12986] Using getrandbits() in uuid.uuid4() is faster and more
	readable
Message-ID: <1316104217.68.0.381815581788.issue12986@psf.upfronthosting.co.za>


New submission from Matt Chaput :

Currently the 'uuid' module uses os.urandom (in the absence of a system UUID generation function) to generate random UUIDs in the uuid.uudi4() function. This patch changes the implementation of uuid4() to use random.getrandbits() as the source of randomness instead, for the following reasons:

* In my quick tests, using getrandbits() is much faster on Windows and Linux. Some applications do need to generate UUIDs quickly.

  >>> setup = "import uuid, os, random"
  >>> ur = "uuid.UUID(bytes=os.urandom(16), version=4)"
  >>> grb = "uuid.UUID(int=random.getrandbits(128), version=4)"
  >>> # Windows --------
  >>> timeit.Timer(ur, setup).timeit()
  22.861042160383903
  >>> timeit.Timer(grb, setup).timeit()
  3.8689128309085135
  >>> # Linux --------
  >>> timeit.Timer(ur, setup).timeit()
  29.32686185836792
  >> timeit.Timer(grb, setup).timeit()
  3.7429409027099609

* The patched code is cleaner. It avoids the try...finally required by the possibly unavailable os.urandom function, and the fallback to generating random bytes.

----------
components: Library (Lib)
files: fastuuid4.patch
keywords: patch
messages: 144087
nosy: mattchaput
priority: normal
severity: normal
status: open
title: Using getrandbits() in uuid.uuid4() is faster and more readable
type: performance
Added file: http://bugs.python.org/file23163/fastuuid4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 19:06:16 2011
From: report at bugs.python.org (jan matejek)
Date: Thu, 15 Sep 2011 17:06:16 +0000
Subject: [issue12987] Demo/scripts/newslist.py has non-commercial license
	clause
Message-ID: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za>


New submission from jan matejek :

from Demo/scripts/newslist.py :

# Feel free to copy, distribute and modify this code for
# non-commercial use. If you make any useful modifications, let me
# know!
#
# (c) Quentin Stafford-Fraser 1994
# fraser at europarc.xerox.com                     qs101 at cl.cam.ac.uk


this is not very nice for commercial distros - we have to drop the file (for now anyway)

i'm not sure what the "right" solution for upstream is - you might want to remove the file, ask Quentin to relicense it, or just acknowledge its existence and keep it

----------
components: Demos and Tools
messages: 144088
nosy: matejcik
priority: normal
severity: normal
status: open
title: Demo/scripts/newslist.py has non-commercial license clause
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 19:13:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Sep 2011 17:13:19 +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: <1316106799.41.0.843158786625.issue12986@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 20:01:31 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Sep 2011 18:01:31 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316109691.31.0.428195408814.issue12973@psf.upfronthosting.co.za>


Changes by Stefan Krah :


Added file: http://bugs.python.org/file23164/listobject_overflow.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 20:01:50 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Sep 2011 18:01:50 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316109710.44.0.0567191870214.issue12973@psf.upfronthosting.co.za>


Changes by Stefan Krah :


Added file: http://bugs.python.org/file23165/itertools_overflow.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 20:08:04 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Sep 2011 18:08:04 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316110084.89.0.806730924208.issue12973@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

With issue12975.diff, listobject_overflow.diff and itertools_overflow.diff
I don't get any more failures.


Also, of course issue12975.diff looks correct to me if we assume:

http://mail.python.org/pipermail/python-dev/2009-December/094392.html
http://yarchive.net/comp/linux/signed_unsigned_casts.html


Mark, did you write those rules down somewhere? I had to think
a bit about the unsigned -> signed casts.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 20:24:36 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Sep 2011 18:24:36 +0000
Subject: [issue12985] Check signed arithmetic overflow in ./configure
In-Reply-To: <1316085399.35.0.882775814031.issue12985@psf.upfronthosting.co.za>
Message-ID: <20110915182136.GA12018@sleipnir.bytereef.org>


Stefan Krah  added the comment:

My rationale was something like this: If a compiler optimizes away signed
arithmetic overflow, this particular comparison will most likely be in
the set of optimizations, since it seems like low hanging fruit.

Of course it doesn't guarantee wrapping behavior in general.

> BTW, I suspect that the reason there were no related test failures
> with the Intel compiler is that most of the problems in the Python
> code stem from multiplications rather than additions.  Probably icc
> isn't sophisticated enough to optimize those multiplication + division
> checks away.

Yes, I think that's it.

> Seems like we should probably be looking for an icc flag that forces
> wrapping on signed integer overflow.

I didn't find any in the man page or search engines.

> In the long run, it would still be good to eliminate the need
> for fwrapv and the like;  it can have a significant performance hit.

I agree, but it's progressing quite slowly. ;)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 20:27:49 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 15 Sep 2011 18:27:49 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316111269.9.0.190802227865.issue12981@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


Added file: http://bugs.python.org/file23166/multiprocessing_fd-1.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 20:28:03 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 15 Sep 2011 18:28:03 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316111283.77.0.709662664707.issue12981@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


Removed file: http://bugs.python.org/file23156/multiprocessing_fd.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 21:26:10 2011
From: report at bugs.python.org (Jakob Malm)
Date: Thu, 15 Sep 2011 19:26:10 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1316114770.91.0.528982216522.issue8822@psf.upfronthosting.co.za>


Jakob Malm  added the comment:

Patch without reflow attached.

This is my first patch to CPython. I considered submitting the patch without reflowing the paragraph, to make the changes clearer, but I thought that that would mean more work for the committer, if the patch were to be accepted. Are non-reflown paragraphs like this generally preferred, then?

Concerning timezone aware objects in the examples, this may make the examples more verbose and less to-the-point, which may not be desirable. I'm still on Python 2.6 and haven't actually used the new timezone class yet...

----------
Added file: http://bugs.python.org/file23167/datetime_doc_noreflow.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 21:32:06 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Sep 2011 19:32:06 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316115126.81.0.655688148809.issue12973@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Gah;  did I really misnumber that issue patch?  Sorry.

> Mark, did you write those rules down somewhere?

Well, they're all in the standard, which is publicly available.  (Or at least, a draft of the standard that's pretty much interchangeable with the real thing is publicly available;  Google for n1256.pdf, or see hyperlink [1] below.)

The correctness of the patch depends on:

(1) the 'usual arithmetic conversions', C99 6.3.1.8, paragraph 1.
     This implies that the other (uncast) long argument will be
     converted to unsigned long before the operation is performed.
    This part is safe.  When reading the rules, note that the 'long'
    and 'unsigned long' types have the same rank. (C99 6.3.1.1, 4th
    listed point.)

(2) an assumption that the C implementation will never raise an
    'implementation-defined' signal (C99 6.3.1.3p3).  This seems
    reasonable:  I'm fairly sure that this provision is there mainly
    for systems using ones' complement or sign-magnitude
    representations for signed integers, and it's safe to assume
    that Python won't meet such systems.

(3) an assumption that integer division for negative arguments
    follows C99 semantics, namely that the quotient is rounded
    towards zero.  C99 requires this (C99 6.5.5p6);  the older
    1989 standard allows quotients to be truncated either towards
    zero (like C99), or towards -infinity (like Python does).  In
    the presence of rounding towards -infinity, the style of
    overflow check used in int_pow can fail.  Even on C89 systems,
    truncation is much more common than flooring for this, so I
    think we're safe again here:  I don't know of any existing
    compilers with issues;  new/future compilers are likely to follow
    the C99 standard here.

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 21:33:51 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Sep 2011 19:33:51 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316115231.85.0.217469846578.issue12973@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> an assumption that the C implementation will never raise an
> 'implementation-defined' signal (C99 6.3.1.3p3).

Sorry, this should have been more explicit: "will never raise ... when converting long to unsigned long"

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 21:42:28 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 15 Sep 2011 19:42:28 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1316114770.91.0.528982216522.issue8822@psf.upfronthosting.co.za>
Message-ID: 


Alexander Belopolsky  added the comment:

-There are two kinds of date and time objects: "naive" and "aware". This
+Date and time objects are either "naive" or "aware". This

Shouldn't we say "datetime and time" instead of "date and time"?
There is no tzinfo attribute in date objects.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 21:44:36 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 15 Sep 2011 19:44:36 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316115876.69.0.304128985166.issue12973@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Those two patches (for listobject and itertools) look fine to me.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 21:46:55 2011
From: report at bugs.python.org (Jakob Malm)
Date: Thu, 15 Sep 2011 19:46:55 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1316116015.57.0.880595985618.issue8822@psf.upfronthosting.co.za>


Jakob Malm  added the comment:

> Shouldn't we say "datetime and time" instead of "date and time"?
> There is no tzinfo attribute in date objects.

Perhaps like this?

:class:`datetime` and :class:`time` objects are...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 21:52:01 2011
From: report at bugs.python.org (Andrew Jewett)
Date: Thu, 15 Sep 2011 19:52:01 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1316116321.43.0.883789811618.issue1170@psf.upfronthosting.co.za>


Andrew Jewett  added the comment:

> That can be done programmatically using the unicodedata module.  
> The regex module (that will hopefully be include in 3.3) is 
> also able to match characters that belongs to specific categories.

Ezio:  Thanks.  (New to me, actually)  Is this what you mean?:
http://www.regular-expressions.info/unicode.html
For the purposes of patching shlex, should we use regex instead of sets of characters (or strings) to test for membership in shlex.wordterminators?  (Or should we create a different class member?  Unfortunately, I guess shlex.wordchars has to be left as some kind of container object to maintain backwards compatibility.)
Something like that would definitely solve the problem nicely.

> Andrew: Thanks for your contribution, but your patch cannot 
> go into 2.7, as we don?t add new features in stable versions

Eric: That's fine.  I just posted here because this page currently gets the top hit when searching for "shlex unicode".  If you think it's appropriate to repost my message for python version 3.4, let me know.  The issue with shlex.wordchars that I raised is valid for any version of python.  I'm not sure my solution is optimal.  (I like the regex idea).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 21:57:28 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 15 Sep 2011 19:57:28 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1316115126.81.0.655688148809.issue12973@psf.upfronthosting.co.za>
Message-ID: <20110915195428.GA12658@sleipnir.bytereef.org>


Stefan Krah  added the comment:

Mark Dickinson  wrote:
> Well, they're all in the standard, which is publicly available. 

I have the real thing. :)

> The correctness of the patch depends on:
> (2) an assumption that the C implementation will never raise an
>     'implementation-defined' signal (C99 6.3.1.3p3).  This seems
>     reasonable:  I'm fairly sure that this provision is there mainly
>     for systems using ones' complement or sign-magnitude
>     representations for signed integers, and it's safe to assume
>     that Python won't meet such systems.

This is what I was concerned about, but the assumption seems safe.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 22:17:57 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 15 Sep 2011 20:17:57 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: 
Message-ID: 


anatoly techtonik  added the comment:

On Thu, Sep 15, 2011 at 10:42 PM, Alexander Belopolsky
 wrote:
>
> Shouldn't we say "datetime and time" instead of "date and time"?
> There is no tzinfo attribute in date objects.

Does that mean that if aware `datetime` is converted to `date` and
then back, the tzinfo information is lost and object implicitly
becomes naive? In this case it should mentioned IMO.
--
anatoly t.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 22:24:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Sep 2011 20:24:35 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316118275.69.0.119353450658.issue12981@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

The patch looks correct. Did you try it on Linux, FreeBSD and/or Windows?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 22:26:48 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 15 Sep 2011 20:26:48 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
	definition that can be cross-referenced
In-Reply-To: 
Message-ID: 


Alexander Belopolsky  added the comment:

On Thu, Sep 15, 2011 at 4:17 PM, anatoly techtonik
 wrote:
..
> Does that mean that if aware `datetime` is converted to `date` and
> then back, the tzinfo information is lost and object implicitly
> becomes naive?

Yes, but one cannot convert "back" from date to datetime.  To get a
datetime object, one needs to combine date and time and tzinfo is
attached to the time component.

> In this case it should mentioned IMO.

I agree.  The following is not really intuitive:

-> None

In order to preserve tzinfo, one has to preserve it when extracting
the time component:

-> datetime.timezone.utc

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 22:55:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 15 Sep 2011 20:55:12 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316120112.55.0.254581925252.issue12981@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

I only tried on Linux.
By the way, what's the simplest way to create a personal clone to test patches on some of the buildbots before committing them?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 23:08:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Sep 2011 21:08:00 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316120880.91.0.728524360776.issue12981@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

- Click on "Server-side clone" on http://hg.python.org/cpython
 - on your computer, hg clone default myclone # default if your local clone of cpython, default branch
 - cd myclone; edit code; hg ci
 - edit .hg/hgrc to update the repository URL
 - hg push
 - force a build on custom buildbots of your choice

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 23:08:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Sep 2011 21:08:15 +0000
Subject: [issue12935] Typo in findertools.py
In-Reply-To: <1315474344.82.0.220434823255.issue12935@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset b5f4c4085ae6 by Ned Deily in branch '2.7':
Issue #12935: Correct typo in findertools.
http://hg.python.org/cpython/rev/b5f4c4085ae6

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 23:12:25 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Sep 2011 21:12:25 +0000
Subject: [issue12935] Typo in findertools.py
In-Reply-To: <1315474344.82.0.220434823255.issue12935@psf.upfronthosting.co.za>
Message-ID: <1316121145.32.0.708955992023.issue12935@psf.upfronthosting.co.za>


Ned Deily  added the comment:

Thanks for the report.  Fixed, although findertools is woefully obsolete and no longer exists in Python 3.  For working with the Finder in current OS X releases, use appscript instead (http://pypi.python.org/pypi/appscript/).

----------
assignee: ronaldoussoren -> ned.deily
nosy: +ned.deily
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 23:45:06 2011
From: report at bugs.python.org (Brian Gernhardt)
Date: Thu, 15 Sep 2011 21:45:06 +0000
Subject: [issue12988] IDLE on Win7 crashes when saving to Documents Library
Message-ID: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za>


New submission from Brian Gernhardt :

Python 3.2.1 (default, Jul 10 2011, 20:02:51) [MSC v.1500 64 bit (AMD64)] on win32

Steps:
1) Start IDLE
2) Open Save dialog (File > Save or Ctrl-S)
3) Select Libraries from the buttons on the left or the dropdown on top.
4) Double-click on Documents
5) Enter any file name (test.txt)
6) Hit enter or click save
7) See "pythonw.exe has stopped working dialog"

I tried running it from the command line (via c:\python32\python -m idlelib.idle) and it produced no useful error messages.

----------
components: IDLE
messages: 144106
nosy: Brian.Gernhardt
priority: normal
severity: normal
status: open
title: IDLE on Win7 crashes when saving to Documents Library
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 23:53:14 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 15 Sep 2011 21:53:14 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316123594.69.0.579428150887.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda :


Added file: http://bugs.python.org/file23168/591277fe6b4a.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 15 23:54:24 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 15 Sep 2011 21:54:24 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316123664.07.0.125341766559.issue6715@psf.upfronthosting.co.za>


Changes by Nadeem Vawda :


Removed file: http://bugs.python.org/file23159/3017ee1d548d.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 00:03:26 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 15 Sep 2011 22:03:26 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316124206.15.0.203335206677.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

Thanks for getting the ball rolling with that. I'll want to try and
familiarize myself with the code for tarfile module before I start
changing stuff, but those points shouldn't be hard to fix, one way
or the other.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 00:10:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Sep 2011 22:10:32 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset d3e072083ff3 by Ned Deily in branch 'default':
Issue #12765: Fix packaging.test.test_database failures on OS X due
http://hg.python.org/cpython/rev/d3e072083ff3

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 00:16:43 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Sep 2011 22:16:43 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1316125003.16.0.158500485821.issue12765@psf.upfronthosting.co.za>


Ned Deily  added the comment:

The database test failures were due to the fact that, on OS X, the tempdir was created in /var which on OS X is actually a symlink to /private/var so the tests for path inclusion which used startswith were failing.  I added a call to os.path.realpath to normalize fake_dists_path to the actual full path. (/etc and /tmp on OS X are also symlinked to /private, BTW).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 00:45:18 2011
From: report at bugs.python.org (Matt Chaput)
Date: Thu, 15 Sep 2011 22:45:18 +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: <1316126718.26.0.638677760384.issue2636@psf.upfronthosting.co.za>


Matt Chaput  added the comment:

Not sure if this is better as a separate feature request or a comment here, but... the new version of .NET includes an option to specify a time limit on evaluation of regexes (not sure if this is a feature in other regex libs). This would be useful especially when you're executing regexes configured by the user and you don't know if/when they might go exponential. Something like this maybe:

# Raises an re.Timeout if not complete within 60 seconds
match = myregex.match(mystring, maxseconds=60.0)

----------
nosy: +mattchaput

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 02:08:16 2011
From: report at bugs.python.org (Nam Nguyen)
Date: Fri, 16 Sep 2011 00:08:16 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
	Windows
Message-ID: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>


New submission from Nam Nguyen :

The module search path is constructed from PYTHONPATH env-var, then zip path, then HKCU PythonPath, then HKLM PythonPath, then PYTHONPATH define (in pyconfig.h), and finally argv[0]. If PYTHONHOME is available, the PYTHONPATH define is expanded. These paths are separated by semicolon.

Without PYTHONHOME, PYTHONPATH define is appended to module_search_path as-is, and a semicolon comes **after** that. With PYTHONHOME, PYTHONPATH define is expanded, and there is no semicolon after it. Then, finally, when argv[0] is added to module_search_path, a semicolon is **prepended** before it.

This inconsistency in handling path delimiter leads to a case where two semicolons are next to each other (;;), which is translated to the current directory. It happens when PYTHONHOME is not found. The current directory is put in front of the application directory (argv[0]) causing a security issue whereby external modules might be imported inadvertently.

This patch makes semicolon handling consistent. A semicolon is appended at the end of every path component, except argv[0].

----------
components: Interpreter Core, Windows
files: getpath.consistent.delim.patch
keywords: patch
messages: 144111
nosy: Nam.Nguyen
priority: normal
severity: normal
status: open
title: Consistently handle path separator in Py_GetPath on Windows
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/file23169/getpath.consistent.delim.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 03:40:32 2011
From: report at bugs.python.org (John Reese)
Date: Fri, 16 Sep 2011 01:40:32 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316137232.53.0.0324467593964.issue6715@psf.upfronthosting.co.za>


Changes by John Reese :


----------
nosy:  -jreese

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 03:42:32 2011
From: report at bugs.python.org (David Lam)
Date: Fri, 16 Sep 2011 01:42:32 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1316137352.97.0.624366104427.issue12537@psf.upfronthosting.co.za>


David Lam  added the comment:

Hm, it seems right now that the only time that happens is when creating a message based on an mbox message.  The 'status' and 'x-status' attributes are deleted.

Any hints on what I could to do figure out what special attributes should be deleted?  I was thinking I might try to find and go through the mailbox specs, and find out what headers are mandatory for each of them.

I think I see some hints on... http://docs.python.org/library/mailbox.html#mailbox.mboxMessage.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 04:06:16 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 16 Sep 2011 02:06:16 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1316138776.55.0.975358846914.issue7201@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I think Mark's original pointer to issue1762561 was right on.  The last
two cases are failing due to the mixed-endian format (mentioned
in that issue) used in OABI.

You can see this in the output of 'test_endian_double':

   '182D4454FB210940' != 'FB210940182D4454'

Note that the values are the same except the two 32-bit words are
swapped.

Similarly, in 'test_unaligned_native_struct_fields':

   '123412007856341200B81E09401F85EB51' !=
   '1234120078563412001F85EB51B81E0940'

The first 8 bytes in each case are the same.   The last 8 bytes of
each (which represent floating-point doubles) are the same except,
again, the words are swapped.

I am going to close this out as "won't fix".  As mentioned in issue1762561, supporting OABI will involve taking on another
host platform.  EABI is surely more predominant these days anyway.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 04:38:03 2011
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 16 Sep 2011 02:38:03 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
	Windows
In-Reply-To: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>
Message-ID: <1316140683.59.0.066922378071.issue12989@psf.upfronthosting.co.za>


Changes by Brian Curtin :


----------
keywords: +needs review
stage:  -> patch review
type:  -> security
versions:  -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 09:45:56 2011
From: report at bugs.python.org (ben)
Date: Fri, 16 Sep 2011 07:45:56 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1316098458.44.0.608490404504.issue12967@psf.upfronthosting.co.za>
Message-ID: <1316159151.49044.YahooMailNeo@web45816.mail.sp1.yahoo.com>


ben  added the comment:

Hi Eric,
?
I'm not suggesting that python does not test the applications. just reporting what I experience.
The python version installed is r32:88445
?
What I did, I opened the setup file (in IDLE) from the distribute 0.6.21 and run this.
?
On my python 3.2 version (clean without extentions). when I type in (on the command line)
?
>>>import sys
>>>sys.stdout.error
'strict'
?
However on the IDLE when I do the same.
a AttributeError is being raised.
?
Not sure why the difference between the two (I thought these were the same).
?
Ben

From: ?ric Araujo 
To: thelen_ben at yahoo.com
Sent: Thursday, 15 September 2011 10:54 PM
Subject: [issue12967] AttributeError distutils\log.py

?ric Araujo  added the comment:

How?? Please tell exactly what command you ran with what Python version.

It does, in 3.x.? Do you think Python has no tests or no users? :)

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker 

_______________________________________

----------
Added file: http://bugs.python.org/file23170/unnamed

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------

Hi Eric,


 


I'm not suggesting that python does not test the applications. just reporting what I experience.


The python version installed is r32:88445


 


What I did, I opened the setup file (in IDLE) from the distribute 0.6.21 and run this.


 


On my python 3.2 version (clean without extentions). when I type in (on the command line)


 


>>>import sys


>>>sys.stdout.error


'strict'


 


However on the IDLE when I do the same.


a AttributeError is being raised.


 


Not sure why the difference between the two (I thought these were the same).


 


Ben









From: ??ric Araujo <report at bugs.python.org>
To: thelen_ben at yahoo.com
Sent: Thursday, 15 September 2011 10:54 PM
Subject: [issue12967] AttributeError distutils\log.py


??ric Araujo <merwok at netwok.org> added the comment:

> when installing the distribute package
How?  Please tell exactly what command you ran with what Python
 version.

> it could be raised on any other usage as sys.stdout does not have
> an 'error' attribute.
It does, in 3.x.  Do you think Python has no tests or no users? :)

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12967>
_______________________________________




From report at bugs.python.org  Fri Sep 16 09:59:19 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Sep 2011 07:59:19 +0000
Subject: [issue8237] multiprocessing.Queue() blocks program
In-Reply-To: <1269574347.06.0.0761043608444.issue8237@psf.upfronthosting.co.za>
Message-ID: <1316159959.76.0.371591367001.issue8237@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

It's a dupe of issue #8426: the Queue isn't full, but the underlying pipe is, so the feeder thread blocks on the write to the pipe (actually when trying to acquire the lock protecting the pipe from concurrent access).
Since the children processes join the feeder thread on exit (to make sure all data has been flushed to pipe), they block.

----------
nosy: +neologix
resolution: invalid -> duplicate
stage: test needed -> committed/rejected
status: open -> closed
superseder:  -> multiprocessing.Queue fails to get() very large objects

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 11:21:21 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 16 Sep 2011 09:21:21 +0000
Subject: [issue6103] Static library (libpythonX.Y.a) installed in incorrect
	location
In-Reply-To: <1243229174.04.0.856181043806.issue6103@psf.upfronthosting.co.za>
Message-ID: <1316164881.89.0.42154591692.issue6103@psf.upfronthosting.co.za>


Dirkjan Ochtman  added the comment:

It would be nice to get some feedback on this.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 11:25:13 2011
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Fri, 16 Sep 2011 09:25:13 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1316165113.57.0.421762836521.issue1222585@psf.upfronthosting.co.za>


Dirkjan Ochtman  added the comment:

Could this get some attention, please?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 12:10:42 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Sep 2011 10:10:42 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316167842.67.0.91767663835.issue6715@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

Nadeem, I started reviewing this path, but now stopped since the patch I reviewed isn't available anymore. Please let us know when the patch has a state where you don't plan to make more changes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 12:19:49 2011
From: report at bugs.python.org (Ricky Teng)
Date: Fri, 16 Sep 2011 10:19:49 +0000
Subject: [issue12990] launcher can't work on path including tradition chinese
	char
Message-ID: <1316168389.55.0.517137945943.issue12990@psf.upfronthosting.co.za>


Changes by Ricky Teng :


----------
assignee: ronaldoussoren
components: Macintosh
nosy: Ricky.Teng, ronaldoussoren
priority: normal
severity: normal
status: open
title: launcher can't work on path including tradition chinese char
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 12:27:52 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 16 Sep 2011 10:27:52 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316168872.27.0.758350715584.issue6715@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

Ah, sorry about that. It probably wasn't necessary to regenerate the
patch after I addressed the comments in each review. The patch should be
stable now; I don't plan to make any further changes for a while.

(At some point I'll want to add a few more tests, and get the module to
compile on Windows. But that can wait.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 12:33:26 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 16 Sep 2011 10:33:26 +0000
Subject: [issue12974] array module: deprecate '__int__' conversion support for
	array elements
In-Reply-To: <1315961295.78.0.425877150438.issue12974@psf.upfronthosting.co.za>
Message-ID: <1316169206.38.0.655856343477.issue12974@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I just discovered that struct packs pointers from objects with an
__index__() method. Is that intentional?

>>> import struct
>>> class IDX(object):
...     def __init__(self, value):
...         self.value = value
...     def __index__(self):
...          return self.value
... 
>>> struct.pack('P', IDX(9))
b'\t\x00\x00\x00\x00\x00\x00\x00'
>>>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 12:34:44 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 16 Sep 2011 10:34:44 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1316169284.14.0.998329004506.issue1172711@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

> I am OK with applying the fix for this issue first.

I also think this should be committed first.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 13:17:25 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 16 Sep 2011 11:17:25 +0000
Subject: [issue12876] Make Test Error : ImportError: No module named _sha256
In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za>
Message-ID: <1316171845.21.0.638280372978.issue12876@psf.upfronthosting.co.za>


Wong Wah Meng  added the comment:

I revert to this after I got my HP-UX ANSI-C compiler installed on my server (HP-UX 11.31 ia64). 

1.) Going back to SSL question, here is the software and version that is found on my server. I am not sure if this is the header only or the full file. However, since I am not using this module in my application, I am going to bypass correcting this error for time being:

  openssl -- A.00.09.08g.031 Secure Network Communications Protocol 
  fips_1_1_2 -- FIPS-OPENSSL-1.1.2.031 Secure Network Communications Protocol

2.) Ok I got my HP C compiler and the build outcome gives me more headaches. I am going to open a new thread of discussion just talk about the build options. Thanks guys for answering to this earlier. 

Regards,
Wah Meng

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 13:43:00 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 16 Sep 2011 11:43:00 +0000
Subject: [issue12991] Python 64-bit build on HP Itanium - Executable built
	successfully but modules failed with HP Compiler
Message-ID: <1316173380.25.0.744886006815.issue12991@psf.upfronthosting.co.za>


New submission from Wong Wah Meng :

Server Info: HP-UX B.11.31 Itanium ia64.
Evaluation copy is used however the license is being purchased, hopefully this are not these errors are not caused by evaluation copy.
 
# swlist -l product | grep Compiler
  ACXX                  C.06.26.EVAL   HP C/aC++ Compiler 
  C-ANSI-C              C.06.26.EVAL   HP C/aC++ Compiler 
  COMPLIBS              B.11.31        Compiler Support Libraries 


I encountered more failures in module build with my HP-UX ANSI C Compiler versus gcc. I wonder why. I need a Oracle plug-in later, i.e. cx_Oracle and the reason I do not want to ignore these errors now because I thought cx_Oracle will have to (or, better) be built using HP compiler, not gcc for support from Oracle. 

I read through the README file, I followed the instruction to set the required environment variables before the configure is run, and unset them before make is run, also edited Makefile to remove Optimization and the -Olimit 1500. However, it gives me a lot more modules that are failed to be built versus 2 when gcc is used. At the bottom of the mail we can see what failed to be built. 

I have summarized my inquiry as follow:-
1.) Despite following the instruction to edit the Makefile before make is run, I am surprise to see that the Makefile content is changed again when the executable is generated. The changed I edited is restored. Is this expected and did the compiler make use of the content that I edited when it did the build and link? 

$ diff Makefile Makefile_Original
61,62c61,62
< OPT=          -DNDEBUG -O
< BASECFLAGS=   +DD64 -Olimit 1500
---
> OPT=          -DNDEBUG
> BASECFLAGS=   +DD64
 
2.) A lot of failed module and I suspected it is due +DD64 nopt recognized by the compiler. Why the HP-UX compiler did not recognize the option? 

ld -b +DD64 -lxnet build/temp.hp-ux-B.11.31-ia64-2.7/home/r32813/Build/2.7.1/Python-2.7.1/Modules/mathmodule.o build/temp.hp-ux-B.11.31-ia64-2.7/home/r32813/Build/2.7.1/Python-2.7.1/Modules/_math.o -L/usr/local/lib -lm -o build/lib.hp-ux-B.11.31-ia64-2.7/math.so
ld: Unrecognized argument: +DD64
Fatal error.

3.) This is a general question, in the README file there isn't specific instruction on how to enable gcc for 64-bit build. Does gcc support 64-bit build and how to?

4.) These are warning message. I have seen a lot of them. Am I right I can ignore them? I don't see them when I use gcc though. 

        cc -Ae -c +DD64 -g -DNDEBUG  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
"Include/pyfpe.h", line 8: warning #3750-D: "\" followed by white space is not a line splice

Thanks in advance for your input. Here is the output of my make using HP C compiler. 
 
Python build finished, but the necessary bits to build these modules were not found:
_bsddb             _curses            _curses_panel   
_sqlite3           _ssl               _tkinter        
bsddb185           bz2                dl              
gdbm               imageop            linuxaudiodev   
ossaudiodev        readline           spwd            
sunaudiodev        zlib                               
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_bisect            _codecs_cn         _codecs_hk      
_codecs_iso2022    _codecs_jp         _codecs_kr      
_codecs_tw         _collections       _csv            
_ctypes            _ctypes_test       _elementtree    
_functools         _heapq             _hotshot        
_io                _json              _locale         
_lsprof            _md5               _multibytecodec 
_multiprocessing   _random            _sha            
_socket            _struct            _testcapi       
array              audioop            binascii        
cmath              cPickle            crypt           
cStringIO          datetime           dbm             
fcntl              future_builtins    grp             
itertools          math               mmap            
nis                operator           parser          
pyexpat            resource           select          
strop              syslog             termios         
time               unicodedata                        

running build_scripts

----------
components: Build
messages: 144123
nosy: wah meng
priority: normal
severity: normal
status: open
title: Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler
type: compile error
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 13:54:27 2011
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 16 Sep 2011 11:54:27 +0000
Subject: [issue12990] launcher can't work on path including tradition chinese
	char
Message-ID: <1316174067.93.0.0828890653583.issue12990@psf.upfronthosting.co.za>


New submission from Ronald Oussoren :

Could you please add some more information on how I can reproduce this issue?

----------
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 13:55:54 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Sep 2011 11:55:54 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1316174154.37.0.774506403577.issue1172711@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Agreed.  Commit first;  worry about __int__ and __index__ later.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 13:59:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Sep 2011 11:59:07 +0000
Subject: [issue12974] array module: deprecate '__int__' conversion support for
	array elements
In-Reply-To: <1315961295.78.0.425877150438.issue12974@psf.upfronthosting.co.za>
Message-ID: <1316174347.72.0.567410783453.issue12974@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Yes, that's intentional.  When use of __int__ was deprecated, a bug report popped up from someone who wanted to be able to have their own objects treated as integers for the purposes of struct.pack.  (I don't recall which issue;  Meador, do you remember?)  So we added use of __index__ at that point.

I think __index__ is the right interface for something to expose if it wants to be usable as an integer, and this usage is consistent with the original __index__ PEP.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 14:00:16 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Sep 2011 12:00:16 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1316174416.22.0.695095564279.issue7201@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

"won't fix" seems reasonable to me.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 14:00:59 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 16 Sep 2011 12:00:59 +0000
Subject: [issue7201] double Endian problem and more on arm
In-Reply-To: <1256428360.64.0.458398001505.issue7201@psf.upfronthosting.co.za>
Message-ID: <1316174459.61.0.653663906589.issue7201@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 14:23:22 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 16 Sep 2011 12:23:22 +0000
Subject: [issue12992] Python build finished,
	but the necessary bits to build these modules were not found: _tkinter
Message-ID: <1316175802.51.0.740552144626.issue12992@psf.upfronthosting.co.za>


New submission from Wong Wah Meng :

Hello there,

I am building python on HP-UX 11.31 (Itanium ia64). I would like to utilize the _tkinter module in my application however I failed to build it. I think this module requires additional tcl + tk source code placed into certain directory and the configure will do the build accordingly. Can someone let me know what files are needed and where should I place them in terms of directory structure, so that I can build python with that built-in module successfully? Thanks!

(PS: I am able to build tcl tk 8.5.9 successfully on the same box however I am not sure how to link that piece of work into python build)

----------
components: Tkinter
messages: 144128
nosy: wah meng
priority: normal
severity: normal
status: open
title: Python build finished, but the necessary bits to build these modules were not found: _tkinter
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 14:34:19 2011
From: report at bugs.python.org (Mayur & Angela Patel-Lam)
Date: Fri, 16 Sep 2011 12:34:19 +0000
Subject: [issue12993] prepared statements in sqlite3 module
Message-ID: <1316176459.71.0.201980894918.issue12993@psf.upfronthosting.co.za>


New submission from Mayur & Angela Patel-Lam :

The sqlite3 module is wonderful, but the one advantage that C/C++ coders have using that system is the ability to use precompiled/prepared SQL statements.  Some SQL databases like Postgresql allow you to precompile statements using special SQL statements (e.g. PREPARE), so there is no need to change the python DBI for those database systems.  But unfortunately, sqlite3 only offers a C/C++ function, which returns a handle to the prepared statement.  I have sought a way to call this from the python DBI, but I simply don't think it's exposed.

Since my application interleaves several SQL commands, depending on the results of the last iteration, I can't immediately use executemany() to obtain maximum performance on my code.  Precompiled statements offer me the best opportunity to optimize.  I can prepare the 2 or 3 most expensive queries in my loop and call them in whatever order I need.  There are some estimates that prepared statements can accelerate complex queries by an order of magnitude, as the parser and optimizers don't need to come into play for every call.

Would you consider an extension to the sqlite3 DBI to expose prepared statements?  Thanks.

----------
components: Library (Lib)
messages: 144129
nosy: Mayur.&.Angela.Patel-Lam
priority: normal
severity: normal
status: open
title: prepared statements in sqlite3 module
type: feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 14:36:38 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 16 Sep 2011 12:36:38 +0000
Subject: [issue12994] cx_Oracle failed to load in newly build python 2.7.1
Message-ID: <1316176598.1.0.658499058413.issue12994@psf.upfronthosting.co.za>


New submission from Wong Wah Meng :

Platform : HP-UX 11.31 on Itanium ia64. 
HP Compiler: 
# swlist -l product | grep Compiler
  ACXX                  C.06.26.EVAL   HP C/aC++ Compiler 
  C-ANSI-C              C.06.26.EVAL   HP C/aC++ Compiler 
  COMPLIBS              B.11.31        Compiler Support Libraries 

I downloaded cx_Oracle5.1 source code and run python setup.py build and able to build the module. However, when I import the module it just cannot load without giving any explicit indication what goes wrong. Does anyone knows why?

$ python setup.py build
running build
running build_ext
building 'cx_Oracle' extension
creating build
creating build/temp.hp-ux-B.11.31-ia64-2.7-11g
cc -Ae -Olimit 1500 -g -DNDEBUG -O +z -I/opt/oracle/product/11.1.0/rdbms/demo -I/opt/oracle/product/11.1.0/rdbms/public -I/home/r32813/Build/2.7.1/Python-2.7.1/Include -I/home/r32813/Build/2.7.1/Python-2.7.1/Lib/.. -c cx_Oracle.c -o build/temp.hp-ux-B.11.31-ia64-2.7-11g/cx_Oracle.o -DBUILD_VERSION=5.0
cc: warning 1913: `1500' does not exist or cannot be read
"/home/r32813/Build/2.7.1/Python-2.7.1/Include/pyfpe.h", line 8: warning #3750-D: 
          "\" followed by white space is not a line splice
      /                       Copyright (c) 1996.                           \ 
                                                                            ^

"NumberVar.c", line 306: warning #4232-D: conversion from "PyObject *" to a
          more strictly aligned type "PyFloatObject *" may cause misaligned
          access
      doubleValue = PyFloat_AS_DOUBLE(value);
                    ^

"NumberVar.c", line 579: warning #4232-D: conversion from "PyObject *" to a
          more strictly aligned type "PyFloatObject *" may cause misaligned
          access
      var->data[pos] = PyFloat_AS_DOUBLE(value);
                       ^

creating build/lib.hp-ux-B.11.31-ia64-2.7-11g
ld -b build/temp.hp-ux-B.11.31-ia64-2.7-11g/cx_Oracle.o -L/opt/oracle/product/11.1.0/lib32 -L/opt/oracle/product/11.1.0 -lclntsh -o build/lib.hp-ux-B.11.31-ia64-2.7-11g/cx_Oracle.so

$ ls -lrt build 
total 0
drwx------   2 r32813     users           96 Sep 16 20:33 temp.hp-ux-B.11.31-ia64-2.7-11g
drwx------   2 r32813     users           96 Sep 16 20:33 lib.hp-ux-B.11.31-ia64-2.7-11g
$ cp build/lib.hp-ux-B.11.31-ia64-2.7-11g/cx_Oracle.so $PYTHONPATH
$ python
iPython 2.7.1 (r271:86832, Sep 15 2011, 14:46:37) [C] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> import cx_Oracle
Traceback (most recent call last):
  File "", line 1, in 
ImportError: Failed to load /home/r32813/Build/2.7.1/Python-2.7.1/Lib/cx_Oracle.so
>>> 
$ env  | grep PYTHON
PYTHONPATH=/home/r32813/Build/2.7.1/Python-2.7.1/Lib
$

----------
components: Extension Modules
messages: 144130
nosy: wah meng
priority: normal
severity: normal
status: open
title: cx_Oracle failed to load in newly build python 2.7.1
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 15:00:05 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 16 Sep 2011 13:00:05 +0000
Subject: [issue12974] array module: deprecate '__int__' conversion support for
	array elements
In-Reply-To: <1316174347.72.0.567410783453.issue12974@psf.upfronthosting.co.za>
Message-ID: <20110916125702.GA17500@sleipnir.bytereef.org>


Stefan Krah  added the comment:

Mark Dickinson  wrote:
> Yes, that's intentional.  When use of __int__ was deprecated, a bug
> report popped up from someone who wanted to be able to have their own
> objects treated as integers for the purposes of struct.pack. 
> (I don't recall which issue;  Meador, do you remember?)
>  So we added use of __index__ at that point.

Yes, I think that's #1530559, and the bug report was about PyCUDA. I can
see why 'bBhHiIlLqQ' allow __index__(), since they previously allowed
__int__().

I specifically meant the 'P' format. As far as I can see, PyLong_AsVoidPtr()
never allowed __int__(), but now index objects can be packed as pointers.
It isn't a big deal, I just have to know for features/pep-3118.

To illustrate, this is python2.5.0; INT is an object with an __int__() method:

'\x07\x00\x00\x00\x00\x00\x00\x00'
>>> struct.pack('P', INT(7))
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/stefan/hg/r25/Lib/struct.py", line 63, in pack
    return o.pack(*args)
struct.error: cannot convert argument to long
>>>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 15:21:29 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 16 Sep 2011 13:21:29 +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: <1316179289.56.0.658097218759.issue12991@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I think you may want to ask these questions on the Python mailing list:

http://mail.python.org/mailman/listinfo/python-list


This is the Python bug-tracker, and it's not obvious to me that
any of your points is a bug in Python.

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 15:31:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Sep 2011 13:31:13 +0000
Subject: [issue12992] Python build finished,
	but the necessary bits to build these modules were not found: _tkinter
In-Reply-To: <1316175802.51.0.740552144626.issue12992@psf.upfronthosting.co.za>
Message-ID: <1316179873.63.0.770123879339.issue12992@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

The bug tracker is not the right place for this kind of questions (the fact that some modules are not built is not a bug).  You might want to try installing the tk-dev package and see if that solves the problem though.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 15:50:37 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 16 Sep 2011 13:50:37 +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: <1316181037.64.0.176152896149.issue12991@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

1) I cannot reproduce this.

2) ld is the linker and not the compiler.

3) and 4) Should definitely be asked on python-list.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 17:03:51 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 16 Sep 2011 15:03:51 +0000
Subject: [issue12974] array module: deprecate '__int__' conversion support for
	array elements
In-Reply-To: <20110916125702.GA17500@sleipnir.bytereef.org>
Message-ID: 


Meador Inge  added the comment:

> I specifically meant the 'P' format. As far as I can see, PyLong_AsVoidPtr()
> never allowed __int__(), but now index objects can be packed as pointers.
> It isn't a big deal, I just have to know for features/pep-3118.
>
> To illustrate, this is python2.5.0; INT is an object with an __int__() method:
>
> '\x07\x00\x00\x00\x00\x00\x00\x00'
>>>> struct.pack('P', INT(7))
> Traceback (most recent call last):
> ?File "", line 1, in 
> ?File "/home/stefan/hg/r25/Lib/struct.py", line 63, in pack
> ? ?return o.pack(*args)
> struct.error: cannot convert argument to long

Huh, that's interesting.  It doesn't allow 'unsigned long' packs either (2.6.7):

Python 2.6.7+ (unknown, Sep 16 2011, 09:53:25)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> class IDX(object):
...     def __init__(self, value):
...         self.value = value
...     def __int__(self):
...          return self.value
...
>>> for code in ['l', 'L', 'P']:
...    try:
...       struct.pack(code, IDX(9))
...    except Exception as e:
...       print "pack('%s'): %s" % (code, e)
...
'\t\x00\x00\x00'
pack('L'): unsupported operand type(s) for &: 'IDX' and 'long'
pack('P'): cannot convert argument to long

The behavior around '__int__' in previous versions seems somewhat accidental.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 18:04:17 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Sep 2011 16:04:17 +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: <1316189057.96.0.833518140268.issue12991@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

> I encountered more failures in module build with my 
> HP-UX ANSI C Compiler versus gcc. I wonder why.

That's really simple to answer. HP-UX is not well supported. You are pretty much on your own.

----------
nosy: +loewis

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 18:46:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 16:46:49 +0000
Subject: [issue12953] Function calls missing from profiler output
In-Reply-To: <1315607842.02.0.28762981022.issue12953@psf.upfronthosting.co.za>
Message-ID: <1316191609.07.0.850622182059.issue12953@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Thanks for the report, which I verified on 3.2.2, Win7. When reporting a bug, please give a minimal example of code showing the bug, and the buggy output. I presume you mean something like the following (slightly edited):

>>> profile.run('for i in range(10): len({})')
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.000    0.000 :0(exec)
       10    0.000    0.000    0.000    0.000 :0(len)
        1    0.016    0.016    0.016    0.016 :0(setprofile)
        1    0.000    0.000    0.000    0.000 :1()
        1    0.000    0.000    0.016    0.016 profile:0(for i in range(10): len({}))
        0    0.000             0.000          profile:0(profiler)

>>> profile.run('for i in range(10): range(1)')
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.000    0.000 :0(exec)
        1    0.000    0.000    0.000    0.000 :0(setprofile)
        1    0.000    0.000    0.000    0.000 :1()
        1    0.000    0.000    0.000    0.000 profile:0(for i in range(10): range(1))
        0    0.000             0.000          profile:0(profiler)

The one call to range(10) and in the second case, the 10 calls to range(1) are missing while in the first case, the 10 calls to len(()) are reported. This looks like a bug to me. As far as I know, len and range are equal status builtin functions. The only Limitations reported in the doc are about timing accuracy.

A minimal test for this would be to look for ":0(range)" in the output, to match the way ":0(len)" does now.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 18:56:05 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 16 Sep 2011 16:56:05 +0000
Subject: [issue12974] array module: deprecate '__int__' conversion support for
	array elements
In-Reply-To: 
Message-ID: <20110916165304.GA19605@sleipnir.bytereef.org>


Stefan Krah  added the comment:

Meador Inge  wrote:
> The behavior around '__int__' in previous versions seems somewhat accidental.

I think struct followed the functions in longobject.c, which is not
really consistent with respect to duck typing. See also #12965 or
http://bugs.python.org/issue1172711#msg48086.

But I think that the decision to accept __index__() for both signed
and unsigned integer formats is good for consistency.

For 'P' I'm not sure, but course it might be used in the wild by now.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 18:57:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Sep 2011 16:57:41 +0000
Subject: [issue12953] Function calls missing from profiler output
In-Reply-To: <1315607842.02.0.28762981022.issue12953@psf.upfronthosting.co.za>
Message-ID: <1316192261.38.0.518152331979.issue12953@psf.upfronthosting.co.za>


R. David Murray  added the comment:

I wonder if it has something to do with range returning a special type?  range and len are very different things under the hood.

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 19:01:47 2011
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Fri, 16 Sep 2011 17:01:47 +0000
Subject: [issue12953] Function calls missing from profiler output
In-Reply-To: <1315607842.02.0.28762981022.issue12953@psf.upfronthosting.co.za>
Message-ID: <1316192507.64.0.770397775898.issue12953@psf.upfronthosting.co.za>


Hagen F?rstenau  added the comment:

It happens for other C functions as well, e.g. itertools.permutations:

>>> profile.run('itertools.permutations(range(10), 3)')
         4 function calls in 0.000 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.000    0.000 :0(exec)
        1    0.000    0.000    0.000    0.000 :0(setprofile)
        1    0.000    0.000    0.000    0.000 :1()
        1    0.000    0.000    0.000    0.000 profile:0(itertools.permutations(range(10), 3))
        0    0.000             0.000          profile:0(profiler)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 19:23:33 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 17:23:33 +0000
Subject: [issue12955] urllib2.build_opener().open() is not friendly to "with
	... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1316193813.57.0.779404227637.issue12955@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

As I understand this, you are asking that 2.7 urllib2.build_opener().open(), which in 3.x is urllib.request.build_opener().open(), be upgraded to return an object that works as a context manager. Unless the docs say that this should already be the case, this is a feature request for 3.3.

I am unable to test whether this feature is already present (in 3.2.2). Your example line "with urllib2.build_opener().open() as:" has an obvious syntax error. When I correct that and adjust for 3.x

import urllib.request as ur
with ur.build_opener().open() as f:
    pass
#
TypeError: open() takes at least 2 arguments (1 given)

The doc for build_opener says it returns an OpenerDirector instance. help(ur.OpenerDirector.open) just says it needs a 'fullurl'. But when I add 'http:www.python.org' as an argument, I get
urllib.error.URLError: 
I do not know what else is needed.

Please copy and paste the ACTUAL (minimal) code you ran to get the AttributeError.

----------
components:  -Documentation, IO
nosy: +terry.reedy
stage:  -> test needed
type: resource usage -> feature request
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 19:42:35 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 16 Sep 2011 17:42:35 +0000
Subject: [issue12955] urllib2.build_opener().open() is not friendly to "with
	... as:"
In-Reply-To: <1316193813.57.0.779404227637.issue12955@psf.upfronthosting.co.za>
Message-ID: <20110916174225.GD1966@mathmagic>


Senthil Kumaran  added the comment:

Just as a quick guideline. If you are talking about context manager
support for urlopen, it is available and present in 3.x but not on
2.7. And I fear, it is late to make it available on 2.7, because it is
a feature.

In any case, as Terry requested, a simple snippet would help us
understand the problem and original poster's expectation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 19:50:14 2011
From: report at bugs.python.org (Vincent Vande Vyvre)
Date: Fri, 16 Sep 2011 17:50:14 +0000
Subject: [issue12995] Different behaviours with  between v3.1.2 and
	v3.2.2
Message-ID: <1316195414.51.0.601610361957.issue12995@psf.upfronthosting.co.za>


New submission from Vincent Vande Vyvre :

Hi,

Trying this code:

------------------------------

# -*- coding: utf-8 -*-

import os
import sys
import platform

print('\nPython version: ', sys.version.split()[0])
print(platform.platform())


paths = ['/home/vincent/image.jpg', '/home/vincent/?????.jpg']

for path in paths:
    print('\n', type(path))
    try:
        print(path)
    except UnicodeEncodeError as why:
        print('print > {0}'.format(why))
    try:
        if not os.path.exists(path):
            print('File not found!')
        else:
            print('File exists')
    except UnicodeEncodeError as why:
        print('os.path.exist > {0}'.format(why))
    try:
        stats = os.stat(path)
        print(stats.st_atime)
    except UnicodeEncodeError as why:
        print('os.stat > {0}'.format(why))
    try:
        f = open(path, 'b')
        f.close()
    except Exception as why:
        print('open > {0}'.format(why))

------------------------------------

on python 3.1.2:

------------------------------------
vincent at tiemoko:~/Python/oqapy/devel$ python3 test_string.py 

Python version:  3.1.2
Linux-2.6.32-33-generic-i686-with-Ubuntu-10.04-lucid

 
/home/vincent/image.jpg
File exists
1316179838.94
open > Must have exactly one of read/write/append mode

 
/home/vincent/?????.jpg
File exists
1316179838.81
open > Must have exactly one of read/write/append mode
vincent at tiemoko:~/Python/oqapy/devel$ 

------------------------------------------------

on python 3.2.2:

------------------------------------------------
[vincent at myhost ~]$ python test_string.py

Python version:  3.2.2
Linux-3.0-ARCH-x86_64-Pentium-R-_Dual-Core_CPU_T4500_ at _2.30GHz-with-glibc2.2.5

/home/vincent/image.jpg
File exists
1316187109.6772401
open > Must have exactly one of read/write/append mode and at most one plus

print > 'ascii' codec can't encode characters in position 14-18: ordinal not in range(128)
os.path.exist > 'ascii' codec can't encode characters in position 14-18: ordinal not in range(128)
os.stat > 'ascii' codec can't encode characters in position 14-18: ordinal not in range(128)
open > 'ascii' codec can't encode characters in position 14-18: ordinal not in range(128)
[vincent at myhost ~]$

-------------------------------------------------------------------


Any 'path = path.decode('utf-8')', 'encode(bhla)', 'sys.getfilesystemencoding()', 'magic_transform(abracadabra)'
don't change anythings.

Thanks for yours advice.

vince

----------
components: Unicode
messages: 144143
nosy: VinsS
priority: normal
severity: normal
status: open
title: Different behaviours with  between v3.1.2 and v3.2.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 20:02:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 18:02:24 +0000
Subject: [issue12953] Function calls missing from profiler output
In-Reply-To: <1315607842.02.0.28762981022.issue12953@psf.upfronthosting.co.za>
Message-ID: <1316196144.98.0.883116982779.issue12953@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Range and most of the itertools functions are exposed at the Python level as iterator classes. (But since C does not have classes, they must be C-level functions!) The int 'class' is also not profiled.

I think this is wrong behavior. Int and range used to be non-class functions, which means the output of profile must have once included them (in 2.7 for range). Classes *are* functions in the wider sense, as used in the title of the 'Builtin functions'. User callables can also switch implementations. A closure might be replaced by a class; a class might be replaced by a factory function.

One could argue that this is such a long time bug (probably) that it should be handled as a feature request. The docs are a bit vague as to what is profiled, except that 26.3.1. Introduction to the profilers
does refer to 'C-level functions'.

However, the more important issue, at present, is keeping profile and cProfile, which wraps lsprof, in sync.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 20:07:34 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 16 Sep 2011 18:07:34 +0000
Subject: [issue12995] Different behaviours with  between v3.1.2 and
	v3.2.2
In-Reply-To: <1316195414.51.0.601610361957.issue12995@psf.upfronthosting.co.za>
Message-ID: <1316196454.35.0.296727485777.issue12995@psf.upfronthosting.co.za>


Benjamin Peterson  added the comment:

This is because how the filesystem encoding is determined has changed. You probably need to explicity discover how non-ascii characters like those in '/home/vincent/?????.jpg' are encoded in your filesystem.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 20:15:26 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Fri, 16 Sep 2011 18:15:26 +0000
Subject: [issue12955] urllib2.build_opener().open() is not friendly to "with
	... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1316196926.85.0.549257838458.issue12955@psf.upfronthosting.co.za>


Valery Khamenya  added the comment:

Terry, Senthil, thanks, for replying to this ticket. OK, to the question:

1. @Terry, here is the full example as for CPython 2.7 I am talking about and the output:

#################

from urllib2 import Request, build_opener

request = Request('http://example.com')

with build_opener().open(request) as f:
    txt = f.read()
    print '%d characters fetched' % len(txt)
####################

Traceback (most recent call last):
  File "", line 1, in 
AttributeError: addinfourl instance has no attribute '__exit__'


2. @Senthil, regarding the statement being a feature. I assume, that to open a connection, to read from a connection and to close it -- are the fundamental functions for what urllib2 was in particular created for. I was looking in docs for some hints of "canonical" way of doing this using urllib2.opener. After I have failed to find any guidance in docs, I've created this ticket. That is, I assume that no new feature is needed, but just a documented 5-lines example about a typical way of doing the above operations, especially *closing* the connection.

regards,
Valery

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 20:21:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 18:21:46 +0000
Subject: [issue12961] unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316197306.14.0.634677715941.issue12961@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Feature requests only apply to 3.3.

To echo Mark: there are an indefinite number of combinatorial generators that could be added. The itertools module should only have a few of the most generally useful, especially in combination with other tools. An extensive combinatorics package would be a different project. (And I have done a bit of work in this direction.)

----------
nosy: +terry.reedy
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 20:40:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 16 Sep 2011 18:40:55 +0000
Subject: [issue12996] multiprocessing.Connection endianness issue
Message-ID: <1316198455.11.0.87432837805.issue12996@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali :

Since the rewrite in pure Python of multiprocessing.Connection (issue #11743), multiprocessing.Connection sends and receives the length of the data (used as header) in host byte order.
This will break if the connection's endpoints are on machine with different endianness.
Patch attached (it also removes an unnecessary computation of the length of the data being sent).

----------
components: Library (Lib)
files: multiprocessing_conn_endianness.diff
keywords: needs review, patch
messages: 144148
nosy: haypo, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: multiprocessing.Connection endianness issue
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23171/multiprocessing_conn_endianness.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 20:58:41 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 18:58:41 +0000
Subject: [issue12966] cookielib.LWPCookieJar breaks on cookie values with a
	newline
In-Reply-To: <1315854880.61.0.95908383563.issue12966@psf.upfronthosting.co.za>
Message-ID: <1316199521.48.0.302248653247.issue12966@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Some notes: In 3.x, cookielib is http.cookiejar. LWPCookieJar is a subclass of FileCookieJar. The module follows RFC 2109 and RFC 2965. RFC 6265 is labelled a 'PROPOSED STANDARD' that 'obsoletes' 2965, but its status is unclear to me. RFC 2965 says it has already been obsoleted. Of course, what matters in practice is what sites do. Cookielib was written to work with obsolete 2109 because that is what was mostly used at the time.

Paulie, please check what the older standards, that are the basis of cookielib, say about newlines in cookies. Also, please load the current 2.7 and 3.2 and test with 'non-compliant' sites.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:03:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 19:03:25 +0000
Subject: [issue12972] Color prompt + readline
In-Reply-To: <1315927772.69.0.871921956001.issue12972@psf.upfronthosting.co.za>
Message-ID: <1316199805.04.0.514798234663.issue12972@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

>From your version choice, you apparently are using 2.6, which is in security-fix only mode. Please test with the latest 2.7 and/or 3.2.

----------
nosy: +terry.reedy
stage:  -> test needed
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:05:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 19:05:57 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316199957.37.0.388251622222.issue12973@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
resolution: duplicate -> 
stage: committed/rejected -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:09:51 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 19:09:51 +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: <1316200191.78.0.759465016752.issue12979@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:10:10 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 19:10:10 +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: <1316200210.64.0.457606927846.issue12979@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
components: +Tkinter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:21:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 19:21:20 +0000
Subject: [issue12982] .pyo file cannot be imported
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1316200880.46.0.122159103886.issue12982@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Eric, you can initially give a doc patch as text in a message, though an actual diff in nicer and may get action sooner. I agree that something could be added. Perhaps the quote "It is possible...." should be followed with something like "However, one must use the python -O option to search for and import .pyo files, as well as for creating them. An alternative is to rename them to .pyc." Or make whatever suggestion you think is better.

Also, please test with 3.2 if you possible can.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, terry.reedy
type: compile error -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:45:47 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 16 Sep 2011 19:45:47 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1316202347.5.0.919174704002.issue9216@psf.upfronthosting.co.za>


Dave Malcolm  added the comment:

I've refreshed this patch against the latest version of the code in hg.

In an attempt to make it easier to review, I've split it up into four (so far) thematic patches, which apply in sequence.

----------
Added file: http://bugs.python.org/file23172/0001-Rework-_hashlib-caching-moving-per-hash-cached-data-.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:46:24 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 16 Sep 2011 19:46:24 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1316202384.49.0.883781071858.issue9216@psf.upfronthosting.co.za>


Changes by Dave Malcolm :


Added file: http://bugs.python.org/file23173/0002-Add-error-handling-to-initialization-of-_hashlib.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:46:39 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 16 Sep 2011 19:46:39 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1316202399.11.0.764900008366.issue9216@psf.upfronthosting.co.za>


Changes by Dave Malcolm :


Added file: http://bugs.python.org/file23174/0003-Add-optional-usedforsecurity-argument-in-various-pla.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:46:48 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 16 Sep 2011 19:46:48 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1316202408.79.0.766499660927.issue9216@psf.upfronthosting.co.za>


Changes by Dave Malcolm :


Added file: http://bugs.python.org/file23175/0004-_hashlib-Add-selftest-for-FIPS-mode-and-usedforsecur.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:48:02 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 16 Sep 2011 19:48:02 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1316202482.95.0.999272421552.issue9216@psf.upfronthosting.co.za>


Dave Malcolm  added the comment:

[and yes, I used git to generate the 4 patches; sorry ]

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 21:57:49 2011
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 16 Sep 2011 19:57:49 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1316203069.58.0.64753391567.issue9216@psf.upfronthosting.co.za>


Dave Malcolm  added the comment:

The cumulative effect of the above patches (to _hashlib) are equivalent to what I've applied downstream to python 2 in RHEL 6.0 and Fedora 17 onwards, and python 3 in Fedora 17 onwards.

In those environments I've additionally patched hashlib to only use _hashlib, rather than falling back on _md5 etc, since otherwise you get confusing error messages from hashlib.md5() when it defers to _md5 due to FIPS enforcement.  In my downstream builds we can be sure of building against OpenSSL, but this other part of the patch seems less appropriate for upstream python, given that upstream python tries to be flexible in terms of its dependencies.

Hope this makes sense.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 22:08:06 2011
From: report at bugs.python.org (Benny Siegert)
Date: Fri, 16 Sep 2011 20:08:06 +0000
Subject: [issue12976] add support for MirBSD platform
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316203686.77.0.971542696979.issue12976@psf.upfronthosting.co.za>


Benny Siegert  added the comment:

As requested, here is the full patch for MirBSD support. The diff was taken against version 2.7.2. It is really quite easy, you just need to handle MirBSD like OpenBSD. 

With this patch, I can successfully compile and run Python on MirBSD. Even though it is a rather exotic platform, I encourage you to take these changes, as they are quite minimal.

----------
components: +Build -Extension Modules
keywords: +patch
title: select module: only use EVFILT_TIMER if available (kqueue backend) -> add support for MirBSD platform
versions: +Python 2.7 -Python 2.6
Added file: http://bugs.python.org/file23176/python27-MirBSD.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 22:08:23 2011
From: report at bugs.python.org (Benny Siegert)
Date: Fri, 16 Sep 2011 20:08:23 +0000
Subject: [issue12976] add support for MirBSD platform
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316203703.63.0.329791684997.issue12976@psf.upfronthosting.co.za>


Changes by Benny Siegert :


Removed file: http://bugs.python.org/file23153/patch-az

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 22:32:59 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 20:32:59 +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: <1316205179.81.0.851873281265.issue12986@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

You could help this along by both running Lib.test.test_uuid with your patch applied and reporting that it passes.

Raymond, I added you because this is about changing random functions.

Side note: This code in test_uuid.test_uuid4()

        uuids = {}
        for u in [uuid.uuid4() for i in range(1000)]:
            uuids[u] = 1
        equal(len(uuids.keys()), 1000)

could be updated to use sets rather than a fake dict:

        uuids = set()
        for u in [uuid.uuid4() for i in range(1000)]:
            uuids.add(u)
        equal(len(uuids), 1000)

----------
nosy: +rhettinger, terry.reedy
versions: +Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 22:42:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 20:42:28 +0000
Subject: [issue12988] IDLE on Win7 crashes when saving to Documents Library
In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za>
Message-ID: <1316205748.9.0.00101633673802.issue12988@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

I got same with 3.2.2. I did it first from editor window and it only crashed that window, leaving the shell window ok until I tried it there also.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 22:43:51 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Sep 2011 20:43:51 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1316205831.53.0.703539347776.issue12967@psf.upfronthosting.co.za>


Ned Deily  added the comment:

That won't work in IDLE because IDLE replaces the standard sys.stdout file object with a special proxy object to capture stdout across its processes and the proxy object does not currently support all of the attributes of a io.TextTIOWrapper object, like errors.

>>> sys.stdout


If that is the only problem, perhaps this issue should be reassigned to IDLE to support errors and any other relevant new attributes.

----------
nosy: +ned.deily

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 22:53:19 2011
From: report at bugs.python.org (Matt Chaput)
Date: Fri, 16 Sep 2011 20:53:19 +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: <1316206399.36.0.750174832454.issue12986@psf.upfronthosting.co.za>


Matt Chaput  added the comment:

Passed all tests OK.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 22:54:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 20:54:46 +0000
Subject: [issue12988] IDLE on Win7 crashes when saving to Documents Library
In-Reply-To: <1316123106.02.0.189929579788.issue12988@psf.upfronthosting.co.za>
Message-ID: <1316206486.41.0.70326600117.issue12988@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

The view of MyDocuments in the save dialog is different from that of Windows Explorer. In particular, it shows a directory twice, the current version and an older version. Double clicking the current version, to see the contents, also crashed IDLE without saving. Win Explorer moves into that directory just fine.

Tried it again, and double click into dirs now works. Saving still crashes. But I still see two versions of the directory when accessing from IDLE (until I redeleted the older one). Saving still crashes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 23:00:01 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 21:00:01 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
	Windows
In-Reply-To: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>
Message-ID: <1316206801.85.0.404911882219.issue12989@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Barry, Benjamin, do you agree that this is a security issue as far as future 2.6 and 3.1 security fix releases are concerned?

----------
nosy: +barry, benjamin.peterson, terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 23:10:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Sep 2011 21:10:00 +0000
Subject: [issue12993] prepared statements in sqlite3 module
In-Reply-To: <1316176459.71.0.201980894918.issue12993@psf.upfronthosting.co.za>
Message-ID: <1316207400.62.0.736411654079.issue12993@psf.upfronthosting.co.za>


Changes by Ned Deily :


----------
nosy: +ghaering

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 23:15:01 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 16 Sep 2011 21:15:01 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1316207701.26.0.62836662317.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc  added the comment:

I'm a bit worried by the Windows version:

- liblzma can't be compiled by Visual Studio: too many C99 isms, mostly variables declared in the middle of a block.  It's doable for sure, but it's a lot of work.

- liblzma is normally compiled with mingw, but we have to be sure that is uses the correct MSCRT C runtime, and what about debug builds?

- All extension modules use static libraries: zlib, expat, sqlite.  But a gcc static library can't be used by Visual Studio.

- The way recommended by XZ is to use a precompiled liblzma.dll; Then it should be easy to build an extension module, but its would be the first time that we distribute an extension module which needs a non-system DLL.  Is it enough to copy it next to _lzma.pyd?  Is there some work to do in the installer?

Too many "but"s :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 23:18:15 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 21:18:15 +0000
Subject: [issue12994] cx_Oracle failed to load in newly build python 2.7.1
In-Reply-To: <1316176598.1.0.658499058413.issue12994@psf.upfronthosting.co.za>
Message-ID: <1316207895.07.0.184884030221.issue12994@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

This tracker is for issues (bugs and feature requests) involving CPython. Your problem appears to be with the 3rd-party extension. Please ask your question on its mailing list
https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
It will certainly have people with 2.7 experience and perhaps someone with HP-UX experience.

I am closing this issue for now. You can reopen if discussion on that list suggests that there is a bug with CPython or setup.py.

PS. an ImportError, or any other exception, is not a crash. A crash is when CPython quits working without saying why.

----------
nosy: +terry.reedy
resolution:  -> postponed
status: open -> closed
type: crash -> behavior
versions: +3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 16 23:54:09 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Sep 2011 21:54:09 +0000
Subject: [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1316210049.75.0.839091032042.issue12955@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

On 3.2.2, your example (adapted) produces
>>> 
2945 characters fetched

So, as Senthil said, the requested feature already exists. But it cannot be added to the 2.7 series; the Python 2.7 *language* is feature frozen. 2.7.z bug fixes serve to make the implementation better match the intended language.

Prior to the addition of with..., the standard way to close things was with explicit .close() or implicit closing when the function returned or the program exited. In the 3.2 docs, "20.5.21. Examples", there are several examples with
  f = 
  
  (closing ignored)
Where possible, these could and should be changed in 3.2+ docs to
  with  as f:
    
to promote the new idiom.  This had been done in other chapters. Perhaps there is also a need for 'X supports the context manager protocol' to be added here or there. But showing that in the examples would make the point.

I have changed the title of this issue to match.

----------
components: +Documentation -Library (Lib)
stage: test needed -> needs patch
title: urllib2.build_opener().open() is not friendly to "with ... as:" -> urllib.request example should use "with ... as:"
versions: +Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 00:54:19 2011
From: report at bugs.python.org (Mark Bucciarelli)
Date: Fri, 16 Sep 2011 22:54:19 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
Message-ID: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>


New submission from Mark Bucciarelli :

If I read http://bugs.python.org/issue10740#msg132470 correctly, the foreign_keys PRAGMA is a no-op b/c "The python sqlite module automatically commits open transactions when it encounters a DDL statement."

Entering as a separate issue as I'm not sure solving 10740 is required to solve this one.

----------
components: None
files: t.py
messages: 144166
nosy: Mark.Bucciarelli
priority: normal
severity: normal
status: open
title: sqlite3: PRAGMA foreign_keys = ON doesn't work
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23177/t.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 01:08:09 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Sep 2011 23:08:09 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1316214489.05.0.936982443671.issue12997@psf.upfronthosting.co.za>


Changes by Ned Deily :


----------
nosy: +ghaering

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 02:15:50 2011
From: report at bugs.python.org (Valery Khamenya)
Date: Sat, 17 Sep 2011 00:15:50 +0000
Subject: [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1316218550.52.0.34438870541.issue12955@psf.upfronthosting.co.za>


Valery Khamenya  added the comment:

Guys, in my item 2 the simplistic goal was stated clearly: open, read and close.

Do you confirm that this basic sequence is not supported by urllib2 under 2.7 ?

(I just requested for a tiny documentation update entry)

regards,
Valery

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 02:21:58 2011
From: report at bugs.python.org (John O'Connor)
Date: Sat, 17 Sep 2011 00:21:58 +0000
Subject: [issue12911] Expose a private accumulator C API
In-Reply-To: <1315311609.99.0.705451675521.issue12911@psf.upfronthosting.co.za>
Message-ID: <1316218918.75.0.314101321263.issue12911@psf.upfronthosting.co.za>


Changes by John O'Connor :


----------
nosy: +jcon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 02:49:41 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 17 Sep 2011 00:49:41 +0000
Subject: [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1316220581.05.0.615040089152.issue12955@psf.upfronthosting.co.za>


Senthil Kumaran  added the comment:

Valery, yes. I shall update 2.7 documentation with this known limitation and 3.x documentation with the example usage scenarios.

Thanks!

----------
assignee: docs at python -> orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 02:59:52 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Sep 2011 00:59:52 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1316221192.97.0.881362556236.issue12537@psf.upfronthosting.co.za>


R. David Murray  added the comment:

Unfortunately I don't think there is any way except going through each subclass to see what special attributes it creates.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 08:29:26 2011
From: report at bugs.python.org (M)
Date: Sat, 17 Sep 2011 06:29:26 +0000
Subject: [issue12998] Memory leak with CTypes Structure
Message-ID: <1316240966.68.0.395492985431.issue12998@psf.upfronthosting.co.za>


New submission from M :

When using Python 2.5.4 on Windows (and potentially other versions and platforms), usage of CTypes like the following cause a memory leak.  The memory leak can be verified with ProcessExplorer, as the memory Python takes up keeps increasing until eventually Python will get a MemoryError.
----
import ctypes
def hi():
    class c1(ctypes.Structure):
            _fields_=[('f1',ctypes.c_uint8)]
    class c2(ctypes.Structure):
            _fields_=[('g1',c1*2)]

while True:
    test=hi()
----

This is true even if the garbage collector is called explicitly:
----
import gc
import ctypes
def hi():
    class c1(ctypes.Structure):
            _fields_=[('f1',ctypes.c_uint8)]
    class c2(ctypes.Structure):
            _fields_=[('g1',c1*2)]

while True:
    test=hi()
    test2=gc.collect()
----

It is also true if "del" is called on the return value of the function.

In order to get the memory leak, it appears to be necessary to have two Structure classes, with one of them containing a "multiple" of the other one as a field.

In a code project where functions returning Structure classes similarly to this example are being used, MemoryError has been encountered.

See: http://stackoverflow.com/users/553702/user553702

----------
components: ctypes
messages: 144170
nosy: a01
priority: normal
severity: normal
status: open
title: Memory leak with CTypes Structure
type: resource usage

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 08:30:57 2011
From: report at bugs.python.org (M)
Date: Sat, 17 Sep 2011 06:30:57 +0000
Subject: [issue12998] Memory leak with CTypes Structure
In-Reply-To: <1316240966.68.0.395492985431.issue12998@psf.upfronthosting.co.za>
Message-ID: <1316241057.67.0.584203029156.issue12998@psf.upfronthosting.co.za>


M  added the comment:

Correction to the above link: See: http://stackoverflow.com/questions/7452625/python-ctypes-memory-leak-with-structure

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 08:41:24 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 17 Sep 2011 06:41:24 +0000
Subject: [issue12998] Memory leak with CTypes Structure
In-Reply-To: <1316240966.68.0.395492985431.issue12998@psf.upfronthosting.co.za>
Message-ID: <1316241684.37.0.144145711889.issue12998@psf.upfronthosting.co.za>


Alex Gaynor  added the comment:

This is caused by a cache which is kept of array's for different (Structure, length) pairs.

----------
nosy: +alex

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 08:42:43 2011
From: report at bugs.python.org (M)
Date: Sat, 17 Sep 2011 06:42:43 +0000
Subject: [issue12998] Memory leak with CTypes Structure
In-Reply-To: <1316240966.68.0.395492985431.issue12998@psf.upfronthosting.co.za>
Message-ID: <1316241763.64.0.562431220576.issue12998@psf.upfronthosting.co.za>


M  added the comment:

If it is a cache, shouldn't it be garbage-collected or limited in size? Why does it grow without bounds?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 08:51:50 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 17 Sep 2011 06:51:50 +0000
Subject: [issue12936] armv5tejl segfaults: sched_setaffinity() vs.
	pthread_setaffinity_np()
In-Reply-To: <1315475687.6.0.367377293571.issue12936@psf.upfronthosting.co.za>
Message-ID: <1316242310.59.0.555802989232.issue12936@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I cannot reproduce the crash on:

Linux debian-armel 2.6.32-5-versatile #1 Wed Jan 12 23:05:11 UTC 2011 armv5tejl GNU/Linux


Since the old (arm) port is deprecated, I'm closing this.

----------
resolution:  -> wont fix
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 09:17:25 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Sep 2011 07:17:25 +0000
Subject: [issue12999] _XOPEN_SOURCE usage on Solaris
Message-ID: <1316243845.31.0.573111003636.issue12999@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


----------
nosy: haypo, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: _XOPEN_SOURCE usage on Solaris
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 09:20:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Sep 2011 07:20:12 +0000
Subject: [issue12999] _XOPEN_SOURCE usage on Solaris
Message-ID: <1316244012.97.0.109004277803.issue12999@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali :

While testing issue #12981, I stumbled on a problem on OpenIndiana buildbot:
"""
test test_multiprocessing crashed -- Traceback (most recent call last):
  File "/export/home/buildbot/64bits/custom.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1133, in runtest_inner
    the_package = __import__(abstest, globals(), locals(), [])
  File "/export/home/buildbot/64bits/custom.cea-indiana-amd64/build/Lib/test/test_multiprocessing.py", line 38, in 
    from multiprocessing import util, reduction
  File "/export/home/buildbot/64bits/custom.cea-indiana-amd64/build/Lib/importlib/_bootstrap.py", line 437, in load_module
    return self._load_module(fullname)
  File "/export/home/buildbot/64bits/custom.cea-indiana-amd64/build/Lib/importlib/_bootstrap.py", line 141, in decorated
    return fxn(self, module, *args, **kwargs)
  File "/export/home/buildbot/64bits/custom.cea-indiana-amd64/build/Lib/importlib/_bootstrap.py", line 342, in _load_module
    exec(code_object, module.__dict__)
  File "/export/home/buildbot/64bits/custom.cea-indiana-amd64/build/Lib/multiprocessing/reduction.py", line 57, in 
    raise ImportError('pickling of connections not supported')
ImportError: pickling of connections not supported
"""

Which means that socket.CMSG_LEN isn't defined.
Now, you might wonder how this can work in the C version of multiprocessing.(sendfd|recvfd), which needs CMSG_LEN().
Here's how:
"""
#ifdef __sun
 /* The control message API is only available on Solaris      
    if XPG 4.2 or later is requested. */      
 #define _XOPEN_SOURCE 500     
 #endif
"""

And indeed:
http://fxr.watson.org/fxr/source/common/sys/socket.h?v=OPENSOLARIS#L478
"""
#if defined(_XPG4_2)
/*
 * The cmsg headers (and macros dealing with them) were made available as
 * part of UNIX95 and hence need to be protected with a _XPG4_2 define.
 */
"""

The problem is that socketmodule uses pyconfig.h defines, and _XOPEN_SOURCE isn't defined on Solaris:
http://hg.python.org/cpython/rev/7c947768b435

(it was added explicitely to Modules/_multiprocessing/multiprocessing.h for sendmsg by http://hg.python.org/cpython/rev/419901e65dd2).
So, _XOPEN_SOURCE is needed on Solaris to build socket_sendmsg and friends.
I'm not sure about the best way to proceed, since Martin certainly had good reasons to remove _XOPEN_SOURCE definition entirely on Solaris.
Should we define it only at the top of socketmodule?

----------
nosy: +loewis

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 09:22:45 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Sep 2011 07:22:45 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316244165.91.0.602351552812.issue12981@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> Did you try it on Linux, FreeBSD and/or Windows?

It works fine on Linux, FreeBSD, OS X and Windows, but not on Solaris: see issue #12999.

----------
dependencies: +_XOPEN_SOURCE usage on Solaris

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 09:51:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Sep 2011 07:51:34 +0000
Subject: [issue12976] add support for MirBSD platform
In-Reply-To: <1316203686.77.0.971542696979.issue12976@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

Hello Benny,

> As requested, here is the full patch for MirBSD support. The diff was taken against version 2.7.2. It is really quite easy, you just need to handle MirBSD like OpenBSD.
> With this patch, I can successfully compile and run Python on MirBSD. Even though it is a rather exotic platform, I encourage you to take these changes, as they are quite minimal.

Indeed, it's quite short and manageable, but see
http://bugs.python.org/issue11937, especially Martin's and Terry's
comments:
"""
Guido established a policy a few years ago that we should rather not
incorporate support for every minority platform for which people
contribute patches. While I'd personally agree that an Interix port
would certainly be "fun", pragmatically, I'm -1 on having the code in
the code basis, and propose to close this issue as "won't fix".

We would certainly be happy to link to gentoo prefix from the "other
ports" page on python.org.
"""

and

"""
Markus, I agree with Martin that this patch would go against current
policy and should be closed. Rather than close it myself, I will try
to persuade you to do so.
[...]
"""

This patch is much simpler and cleaner though (OTOH, it's so simple it
shouldn't be too much work for MirBSD folks to keep this patch in
sync).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 10:05:22 2011
From: report at bugs.python.org (Sebastian Wiesner)
Date: Sat, 17 Sep 2011 08:05:22 +0000
Subject: [issue12998] Memory leak with CTypes Structure
In-Reply-To: <1316240966.68.0.395492985431.issue12998@psf.upfronthosting.co.za>
Message-ID: <1316246722.08.0.339570695785.issue12998@psf.upfronthosting.co.za>


Sebastian Wiesner  added the comment:

Why should it?  After all, you're sort of abusing ctypes by repeatedly creating Struture types over and over again.  C structures that you might want to wrap with these types are fixed and known at the time of programming, so there is never a need to create the same Structure type twice.  Thus the set of Structure subclasses created during the live-time of a program is both, fixed and small, so there is no need to limit the cache size.

----------
nosy: +lunar

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 11:27:06 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 17 Sep 2011 09:27:06 +0000
Subject: [issue12998] Memory leak with CTypes Structure
In-Reply-To: <1316240966.68.0.395492985431.issue12998@psf.upfronthosting.co.za>
Message-ID: <1316251626.95.0.56400624399.issue12998@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

I can reproduce the leak with Python 2.5.4, but not with Python 2.6.5
or Python 3.2.

Python 2.5.4 is an ancient version. Please upgrade to Python 2.7
or Python 3.2. If the leak still exists, just respond to this issue
and it will be opened again automatically.

----------
nosy: +skrah
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 12:59:27 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sat, 17 Sep 2011 10:59:27 +0000
Subject: [issue11694] xdrlib raises ConversionError in inconsistent way
In-Reply-To: <1301224336.99.0.411299821684.issue11694@psf.upfronthosting.co.za>
Message-ID: <1316257167.46.0.277013238565.issue11694@psf.upfronthosting.co.za>


Filip Gruszczy?ski  added the comment:

Patch with tests.

----------
keywords: +patch
Added file: http://bugs.python.org/file23178/11694.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 13:28:29 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Sep 2011 11:28:29 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316244165.91.0.602351552812.issue12981@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

Here's a patch taking into account the fact that
multiprocessing.reduction might not be available and importing it can
raise an ImportError (which is already the case with the C
implementation, but multiprocessing.reduction tests have been added
recently to test_multiprocessing), e.g. if the OS doesn't support FD
passing.
With this patch, the pure Python version can be applied, and passes on
Linux, FreeBSD, OS X, Windows and OpenSolaris (except that it's not
available on OpenSolaris until issue #12999 gets fixed).
I also slightly modified the struct format used in the pure Python
version to make sure the length is sent as a a native int ("@i")
instead of a standardized int ("=i"), which might break if sizeof(int)
!= 4 (not sure there are many ILP64 architectures out there, but you
never know...).

----------
Added file: http://bugs.python.org/file23179/skip_reduction.diff
Added file: http://bugs.python.org/file23180/multiprocessing_fd-2.diff

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
diff -r c6d52971dd2a Lib/test/test_multiprocessing.py
--- a/Lib/test/test_multiprocessing.py	Thu Sep 15 18:18:51 2011 +0200
+++ b/Lib/test/test_multiprocessing.py	Sat Sep 17 10:54:10 2011 +0200
@@ -35,7 +35,13 @@
 import multiprocessing.heap
 import multiprocessing.pool
 
-from multiprocessing import util, reduction
+from multiprocessing import util
+
+try:
+    from multiprocessing import reduction
+    HAS_REDUCTION = True
+except ImportError:
+    HAS_REDUCTION = False
 
 try:
     from multiprocessing.sharedctypes import Value, copy
@@ -1631,6 +1637,7 @@
         os.write(fd, data)
         os.close(fd)
 
+    @unittest.skipUnless(HAS_REDUCTION, "test needs multiprocessing.reduction")
     def test_fd_transfer(self):
         if self.TYPE != 'processes':
             self.skipTest("only makes sense with processes")
@@ -1648,6 +1655,7 @@
         with open(test.support.TESTFN, "rb") as f:
             self.assertEqual(f.read(), b"foo")
 
+    @unittest.skipUnless(HAS_REDUCTION, "test needs multiprocessing.reduction")
     @unittest.skipIf(sys.platform == "win32",
                      "test semantics don't make sense on Windows")
     @unittest.skipIf(MAXFD <= 256,
@@ -1987,10 +1995,12 @@
             'multiprocessing', 'multiprocessing.connection',
             'multiprocessing.heap', 'multiprocessing.managers',
             'multiprocessing.pool', 'multiprocessing.process',
-            'multiprocessing.reduction',
             'multiprocessing.synchronize', 'multiprocessing.util'
             ]
 
+        if HAS_REDUCTION:
+            modules.append('multiprocessing.reduction')
+
         if c_int is not None:
             # This module requires _ctypes
             modules.append('multiprocessing.sharedctypes')
-------------- next part --------------
diff -r c6d52971dd2a Lib/multiprocessing/reduction.py
--- a/Lib/multiprocessing/reduction.py	Thu Sep 15 18:18:51 2011 +0200
+++ b/Lib/multiprocessing/reduction.py	Fri Sep 16 19:44:51 2011 +0200
@@ -39,6 +39,7 @@
 import sys
 import socket
 import threading
+import struct
 
 import _multiprocessing
 from multiprocessing import current_process
@@ -51,7 +52,8 @@
 #
 #
 
-if not(sys.platform == 'win32' or hasattr(_multiprocessing, 'recvfd')):
+if not(sys.platform == 'win32' or (hasattr(socket, 'CMSG_LEN') and
+                                   hasattr(socket, 'SCM_RIGHTS'))):
     raise ImportError('pickling of connections not supported')
 
 #
@@ -77,10 +79,23 @@
 
 else:
     def send_handle(conn, handle, destination_pid):
-        _multiprocessing.sendfd(conn.fileno(), handle)
+        with socket.fromfd(conn.fileno(), socket.AF_UNIX, socket.SOCK_STREAM) as s:
+            s.sendmsg([b'x'], [(socket.SOL_SOCKET, socket.SCM_RIGHTS,
+                                struct.pack("@i", handle))])
 
     def recv_handle(conn):
-        return _multiprocessing.recvfd(conn.fileno())
+        size = struct.calcsize("@i")
+        with socket.fromfd(conn.fileno(), socket.AF_UNIX, socket.SOCK_STREAM) as s:
+            msg, ancdata, flags, addr = s.recvmsg(1, socket.CMSG_SPACE(size))
+            try:
+                cmsg_level, cmsg_type, cmsg_data = ancdata[0]
+                if (cmsg_level == socket.SOL_SOCKET and
+                    cmsg_type == socket.SCM_RIGHTS):
+                    return struct.unpack("@i", cmsg_data[:size])[0]
+            except (ValueError, IndexError, struct.error):
+                pass
+            raise RuntimeError('Invalid data received')
+
 
 #
 # Support for a per-process server thread which caches pickled handles
diff -r c6d52971dd2a Modules/_multiprocessing/multiprocessing.c
--- a/Modules/_multiprocessing/multiprocessing.c	Thu Sep 15 18:18:51 2011 +0200
+++ b/Modules/_multiprocessing/multiprocessing.c	Fri Sep 16 19:44:51 2011 +0200
@@ -8,11 +8,6 @@
 
 #include "multiprocessing.h"
 
-#ifdef SCM_RIGHTS
-    #define HAVE_FD_TRANSFER 1
-#else
-    #define HAVE_FD_TRANSFER 0
-#endif
 
 PyObject *create_win32_namespace(void);
 
@@ -75,104 +70,7 @@
     return FALSE;
 }
 
-/*
- * Unix only
- */
-
-#else /* !MS_WINDOWS */
-
-#if HAVE_FD_TRANSFER
-
-/* Functions for transferring file descriptors between processes.
-   Reimplements some of the functionality of the fdcred
-   module at http://www.mca-ltd.com/resources/fdcred_1.tgz. */
-/* Based in http://resin.csoft.net/cgi-bin/man.cgi?section=3&topic=CMSG_DATA */
-
-static PyObject *
-multiprocessing_sendfd(PyObject *self, PyObject *args)
-{
-    int conn, fd, res;
-    struct iovec dummy_iov;
-    char dummy_char;
-    struct msghdr msg;
-    struct cmsghdr *cmsg;
-    union {
-        struct cmsghdr hdr;
-        unsigned char buf[CMSG_SPACE(sizeof(int))];
-    } cmsgbuf;
-
-    if (!PyArg_ParseTuple(args, "ii", &conn, &fd))
-        return NULL;
-
-    dummy_iov.iov_base = &dummy_char;
-    dummy_iov.iov_len = 1;
-
-    memset(&msg, 0, sizeof(msg));
-    msg.msg_control = &cmsgbuf.buf;
-    msg.msg_controllen = sizeof(cmsgbuf.buf);
-    msg.msg_iov = &dummy_iov;
-    msg.msg_iovlen = 1;
-
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_len = CMSG_LEN(sizeof(int));
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    * (int *) CMSG_DATA(cmsg) = fd;
-
-    Py_BEGIN_ALLOW_THREADS
-    res = sendmsg(conn, &msg, 0);
-    Py_END_ALLOW_THREADS
-
-    if (res < 0)
-        return PyErr_SetFromErrno(PyExc_OSError);
-    Py_RETURN_NONE;
-}
-
-static PyObject *
-multiprocessing_recvfd(PyObject *self, PyObject *args)
-{
-    int conn, fd, res;
-    char dummy_char;
-    struct iovec dummy_iov;
-    struct msghdr msg = {0};
-    struct cmsghdr *cmsg;
-    union {
-        struct cmsghdr hdr;
-        unsigned char buf[CMSG_SPACE(sizeof(int))];
-    } cmsgbuf;
-
-    if (!PyArg_ParseTuple(args, "i", &conn))
-        return NULL;
-
-    dummy_iov.iov_base = &dummy_char;
-    dummy_iov.iov_len = 1;
-
-    memset(&msg, 0, sizeof(msg));
-    msg.msg_control = &cmsgbuf.buf;
-    msg.msg_controllen = sizeof(cmsgbuf.buf);
-    msg.msg_iov = &dummy_iov;
-    msg.msg_iovlen = 1;
-
-    cmsg = CMSG_FIRSTHDR(&msg);
-    cmsg->cmsg_level = SOL_SOCKET;
-    cmsg->cmsg_type = SCM_RIGHTS;
-    cmsg->cmsg_len = CMSG_LEN(sizeof(int));
-    msg.msg_controllen = cmsg->cmsg_len;
-
-    Py_BEGIN_ALLOW_THREADS
-    res = recvmsg(conn, &msg, 0);
-    Py_END_ALLOW_THREADS
-
-    if (res < 0)
-        return PyErr_SetFromErrno(PyExc_OSError);
-
-    fd = * (int *) CMSG_DATA(cmsg);
-    return Py_BuildValue("i", fd);
-}
-
-#endif /* HAVE_FD_TRANSFER */
-
-#endif /* !MS_WINDOWS */
+#endif /* MS_WINDOWS */
 
 
 /*
@@ -201,16 +99,6 @@
     {"address_of_buffer", multiprocessing_address_of_buffer, METH_O,
      "address_of_buffer(obj) -> int\n"
      "Return address of obj assuming obj supports buffer inteface"},
-#if HAVE_FD_TRANSFER
-    {"sendfd", multiprocessing_sendfd, METH_VARARGS,
-     "sendfd(sockfd, fd) -> None\n"
-     "Send file descriptor given by fd over the unix domain socket\n"
-     "whose file decriptor is sockfd"},
-    {"recvfd", multiprocessing_recvfd, METH_VARARGS,
-     "recvfd(sockfd) -> fd\n"
-     "Receive a file descriptor over a unix domain socket\n"
-     "whose file decriptor is sockfd"},
-#endif
     {NULL}
 };
 
@@ -308,9 +196,6 @@
 #ifdef HAVE_SEM_TIMEDWAIT
     ADD_FLAG(HAVE_SEM_TIMEDWAIT);
 #endif
-#ifdef HAVE_FD_TRANSFER
-    ADD_FLAG(HAVE_FD_TRANSFER);
-#endif
 #ifdef HAVE_BROKEN_SEM_GETVALUE
     ADD_FLAG(HAVE_BROKEN_SEM_GETVALUE);
 #endif

From report at bugs.python.org  Sat Sep 17 13:28:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Sep 2011 11:28:51 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316258931.19.0.915090118223.issue12981@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


Removed file: http://bugs.python.org/file23166/multiprocessing_fd-1.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 14:06:15 2011
From: report at bugs.python.org (jorge.seifert)
Date: Sat, 17 Sep 2011 12:06:15 +0000
Subject: [issue13000] unhandled exception at  install
Message-ID: <1316261175.24.0.481643908897.issue13000@psf.upfronthosting.co.za>


New submission from jorge.seifert :

Unhandled exception just at when start to install on windows 2003

----------
components: Installation
messages: 144182
nosy: jorge.seifert
priority: normal
severity: normal
status: open
title: unhandled exception at  install
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 14:08:15 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Sep 2011 12:08:15 +0000
Subject: [issue13000] unhandled exception at  install
In-Reply-To: <1316261175.24.0.481643908897.issue13000@psf.upfronthosting.co.za>
Message-ID: <1316261295.96.0.453708165734.issue13000@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Can you please give ANY information on what exactly you were installing, and what the exception was? Otherwise this report is useless.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 15:01:44 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 17 Sep 2011 13:01:44 +0000
Subject: [issue12999] _XOPEN_SOURCE usage on Solaris
In-Reply-To: <1316244012.97.0.109004277803.issue12999@psf.upfronthosting.co.za>
Message-ID: <1316264504.5.0.945665765465.issue12999@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 15:03:50 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 17 Sep 2011 13:03:50 +0000
Subject: [issue12999] _XOPEN_SOURCE usage on Solaris
In-Reply-To: <1316244012.97.0.109004277803.issue12999@psf.upfronthosting.co.za>
Message-ID: <1316264630.58.0.592434438831.issue12999@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

See too http://bugs.python.org/issue6755#msg143798

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 15:04:58 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 17 Sep 2011 13:04:58 +0000
Subject: [issue12999] _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED usage on Solaris
In-Reply-To: <1316244012.97.0.109004277803.issue12999@psf.upfronthosting.co.za>
Message-ID: <1316264698.76.0.901369503668.issue12999@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
title: _XOPEN_SOURCE usage on Solaris -> _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED usage on Solaris

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 15:15:01 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 17 Sep 2011 13:15:01 +0000
Subject: [issue12999] _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED usage on Solaris
In-Reply-To: <1316244012.97.0.109004277803.issue12999@psf.upfronthosting.co.za>
Message-ID: <1316265301.12.0.0490401839712.issue12999@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

Some rational in issue1759169.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 16:14:33 2011
From: report at bugs.python.org (jorge.seifert)
Date: Sat, 17 Sep 2011 14:14:33 +0000
Subject: [issue13000] unhandled exception at  install
In-Reply-To: <1316261175.24.0.481643908897.issue13000@psf.upfronthosting.co.za>
Message-ID: <1316268873.25.0.769156064416.issue13000@psf.upfronthosting.co.za>


jorge.seifert  added the comment:

The message I get after it is:

undandled win32 exception occurred in msiexec [2376]

I am tryin to install on windows server 2003

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 16:27:55 2011
From: report at bugs.python.org (ben)
Date: Sat, 17 Sep 2011 14:27:55 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1316205831.53.0.703539347776.issue12967@psf.upfronthosting.co.za>
Message-ID: <1316269671.71650.YahooMailNeo@web45807.mail.sp1.yahoo.com>


ben  added the comment:

Hi Ned,
?
Not sure if I fully understand the IDLE issue, I'm still learning Python (abt. 6 months). Nevertheless I've installed the distributes through the command line.
?
if you want to reassign this issue to IDLE, please do so.
?
Best regards,
?
Ben Thelen
?
?

From: Ned Deily 
To: thelen_ben at yahoo.com
Sent: Saturday, 17 September 2011 4:43 AM
Subject: [issue12967] AttributeError distutils\log.py

Ned Deily  added the comment:

That won't work in IDLE because IDLE replaces the standard sys.stdout file object with a special proxy object to capture stdout across its processes and the proxy object does not currently support all of the attributes of a io.TextTIOWrapper object, like errors.



If that is the only problem, perhaps this issue should be reassigned to IDLE to support errors and any other relevant new attributes.

----------
nosy: +ned.deily

_______________________________________
Python tracker 

_______________________________________

----------
Added file: http://bugs.python.org/file23181/unnamed

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------

Hi Ned,


 


Not sure if I fully understand the IDLE issue, I'm still learning Python (abt. 6 months). Nevertheless I've installed the distributes through the command line.


 


if you want to reassign this issue to IDLE, please do so.


 


Best regards,


 


Ben Thelen


 


 









From: Ned Deily <report at bugs.python.org>
To: thelen_ben at yahoo.com
Sent: Saturday, 17 September 2011 4:43 AM
Subject: [issue12967] AttributeError distutils\log.py


Ned Deily <nad at acm.org> added the comment:

That won't work in IDLE because IDLE replaces the standard sys.stdout file object with a special proxy object to capture stdout across its processes
 and the proxy object does not currently support all of the attributes of a io.TextTIOWrapper object, like errors.

>>> sys.stdout
<idlelib.rpc.RPCProxy object at 0x1282b30>

If that is the only problem, perhaps this issue should be reassigned to IDLE to support errors and any other relevant new attributes.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12967>
_______________________________________




From report at bugs.python.org  Sat Sep 17 16:34:31 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 17 Sep 2011 14:34:31 +0000
Subject: [issue13001] test_socket.testRecvmsgTrunc failure on FreeBSD 7.2
	buildbot
Message-ID: <1316270071.04.0.179563462632.issue13001@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali :

http://www.python.org/dev/buildbot/all/builders/x86 FreeBSD 7.2 3.x/builds/2129/steps/test/logs/stdio

"""
======================================================================
FAIL: testRecvmsgTrunc (test.test_socket.RecvmsgUDPTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 1666, in testRecvmsgTrunc
    self.checkFlags(flags, eor=False)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 1354, in checkFlags
    self.assertEqual(flags & mask, checkset & mask)
AssertionError: 0 != 16

======================================================================
FAIL: testRecvmsgTrunc (test.test_socket.RecvmsgIntoUDPTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 1666, in testRecvmsgTrunc
    self.checkFlags(flags, eor=False)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_socket.py", line 1354, in checkFlags
    self.assertEqual(flags & mask, checkset & mask)
AssertionError: 0 != 16
"""

This fails because MSG_TRUNC isn't always set in msg_flags when receiving a truncated datagram with recvmsg().
It's a known kernel bug (http://svnweb.freebsd.org/base?view=revision&revision=211030), fixed in FreeBSD 8 (and the test indeed passes on the FreeBSD 8 buildbot).

The patch attached skips the test on FreeBSD < 8 (and introduces @support.requires_freebsd_version).

----------
components: Tests
files: freebsd_msgtrunc.diff
keywords: needs review, patch
messages: 144188
nosy: haypo, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: test_socket.testRecvmsgTrunc failure on FreeBSD 7.2 buildbot
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23182/freebsd_msgtrunc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 16:43:55 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 17 Sep 2011 14:43:55 +0000
Subject: [issue13002] peephole.c: unused parameter
Message-ID: <1316270635.94.0.378241205596.issue13002@psf.upfronthosting.co.za>


New submission from Stefan Krah :

peephole.c: CONST_STACK_TOP(x) has an unused parameter.

----------
components: Interpreter Core
files: peephole_unused_parameter.diff
keywords: patch
messages: 144189
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: peephole.c: unused parameter
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file23183/peephole_unused_parameter.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:08:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:08:03 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1316272083.85.0.766338088593.issue12967@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


Removed file: http://bugs.python.org/file23136/log.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:08:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:08:05 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1316272085.62.0.707439377098.issue12967@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


Removed file: http://bugs.python.org/file23170/unnamed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:08:06 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:08:06 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1316272086.71.0.633765501384.issue12967@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


Removed file: http://bugs.python.org/file23181/unnamed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:12:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:12:28 +0000
Subject: [issue12967] AttributeError distutils\log.py
In-Reply-To: <1315888690.96.0.966369051182.issue12967@psf.upfronthosting.co.za>
Message-ID: <1316272348.97.0.974513475879.issue12967@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> I'm not suggesting that python does not test the applications. just reporting
> what I experience.
I was joking :)  What I meant was: I can?t agree with the statement ?it could be raised on any other usage as sys.stdout does not have an 'error' attribute? because we have tests and users that use distutils without seeing this error.

> What I did, I opened the setup file (in IDLE) from the distribute 0.6.21 and run this.
setup.py is meant to be run from the command line only.  If you try to run it from IDLE, the behavior is undefined, so I?m inclined to close this bug as invalid.

(A note about this bug tracker: please do not send HTML email, it gets transformed into an unhelpful attachment, and also don?t include whole messages after your reply when you send email.  Thanks in advance!)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:16:47 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:16:47 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1316272607.71.0.640043152282.issue1222585@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Well, there?s no rush, Python 3.3b1 is not next week.

I?m willing to apply the patch to packaging and distutils2 (in a week or two when I?ve finished a massive cleanup and caught up with packaging), but I?d like tests for detect_language, and if possible tests for compiling C++ extensions/libs too.

----------
assignee: tarek -> eric.araujo
versions: +3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:20:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:20:20 +0000
Subject: [issue12765] test_packaging failure under Snow Leopard
In-Reply-To: <1313526816.31.0.254383704283.issue12765@psf.upfronthosting.co.za>
Message-ID: <1316272820.35.0.497181831972.issue12765@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

test_packaging now passes on the buildbot, thanks!  (The current failure is test_socket.)

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:23:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:23:46 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1316273026.29.0.463265963569.issue1170@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Andrew: Ezio means http://docs.python.org/2.7/library/unicodedata

> For the purposes of patching shlex
Sorry, but we are not talking about patching shlex.

> I just posted here because this page currently gets the top hit
> when searching for "shlex unicode".
It?s okay.  A recipe on ActiveState and a ?shlexu? module on PyPI would also be good things to have.

> If you think it's appropriate to repost my message for python version 3.4,
> let me know.
shlex supports Unicode in 3.x.  If there is a bug, can you please open another bug report?  This one is already too long, and I?d prefer to keep it focused on the need for a documentation patch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:25:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:25:32 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1316273132.12.0.0335784632369.issue12785@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:26:08 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:26:08 +0000
Subject: [issue12678] test_packaging and test_distutils failures under Windows
In-Reply-To: <1312246456.25.0.0786053132137.issue12678@psf.upfronthosting.co.za>
Message-ID: <1316273168.46.0.36274997682.issue12678@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Distutils and packaging tests now pass on the three builbots.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:31:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:31:04 +0000
Subject: [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1316273464.83.0.578857951709.issue12955@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

[Terry]
> But when I add 'http:www.python.org' as an argument, I get
> urllib.error.URLError: 

Your URI lacks a host (netloc, in RFC parlance) component:
>>> urllib.parse.urlparse('http:python.org')
ParseResult(scheme='http', netloc='', path='python.org', params='', query='', fragment='')

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:35:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:35:17 +0000
Subject: [issue12956] builds fail when installing to --prefix with space in
	path name
In-Reply-To: <1315757316.68.0.219297921497.issue12956@psf.upfronthosting.co.za>
Message-ID: <1316273717.54.0.744722114256.issue12956@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> While I'm sympathetic to supporting arbitrary path names, I'm not sure
> if it is worth the effort.

My sentiment too.  Supporting non-ASCII characters seems clearly important to me, as it?s a reasonable and common thing to run or install Python from a patch that may contain non-ASCII characters (a first name, ?downloads? in French, etc.); supporting spaces is less important.

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:37:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:37:59 +0000
Subject: [issue12964] Two improvements for the locale aliasing engine
In-Reply-To: <1315831287.41.0.402878841254.issue12964@psf.upfronthosting.co.za>
Message-ID: <1316273879.04.0.407003227761.issue12964@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
type: behavior -> feature request
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:39:45 2011
From: report at bugs.python.org (Mark Bucciarelli)
Date: Sat, 17 Sep 2011 15:39:45 +0000
Subject: [issue10740] sqlite3 module should allow DDL statements in
	transactions
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1316273985.96.0.599880048245.issue10740@psf.upfronthosting.co.za>


Mark Bucciarelli  added the comment:

Opened http://bugs.python.org/issue12997 in case there is a way to solve the foreign_key PRAGMA issue with a less disruptive fix.

----------
nosy: +Mark.Bucciarelli

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:45:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:45:10 +0000
Subject: [issue12982] .pyo file can't be imported unless -O is given
In-Reply-To: <1316032363.3.0.192750692303.issue12982@psf.upfronthosting.co.za>
Message-ID: <1316274310.81.0.274178050153.issue12982@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I would not suggest to rename a .pyo to .pyc, they have different promises (if I can even say that, as they?re implementation details).

----------
nosy: +eric.araujo
stage:  -> needs patch
title: .pyo file cannot be imported -> .pyo file can't be imported unless -O is given
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:48:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Sep 2011 15:48:21 +0000
Subject: [issue12961] unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316274501.06.0.760243623167.issue12961@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


Removed file: http://bugs.python.org/file23132/unnamed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:48:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Sep 2011 15:48:25 +0000
Subject: [issue12961] unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316274505.87.0.87322763125.issue12961@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


Removed file: http://bugs.python.org/file23134/unnamed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:49:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 17 Sep 2011 15:49:25 +0000
Subject: [issue12987] Demo/scripts/newslist.py has non-free licensing terms
In-Reply-To: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za>
Message-ID: <1316274565.98.0.232173828479.issue12987@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

It?s a problem for free software distribution, regardless of the commercial status, like the profiler used to be.  The Demo directory is gone in 3.2 and higher; I?m not sure any effort to fix this in 2.7 is worth it.

----------
nosy: +eric.araujo
title: Demo/scripts/newslist.py has non-commercial license clause -> Demo/scripts/newslist.py has non-free licensing terms

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:52:16 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 17 Sep 2011 15:52:16 +0000
Subject: [issue13002] peephole.c: unused parameter
In-Reply-To: <1316270635.94.0.378241205596.issue13002@psf.upfronthosting.co.za>
Message-ID: <1316274736.16.0.349917652407.issue13002@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Looks like it was checked in that way (http://hg.python.org/cpython/rev/14205d0fee45).  Patch looks good to me.

----------
nosy: +meadori

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 17:52:38 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Sep 2011 15:52:38 +0000
Subject: [issue12931] xmlrpclib confuses unicode and string
In-Reply-To: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>
Message-ID: <1316274758.13.0.922433204873.issue12931@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti
versions:  -Python 2.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:07:18 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Sep 2011 16:07:18 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1316275638.25.0.85946103111.issue1170@psf.upfronthosting.co.za>


R. David Murray  added the comment:

Ezio, I don't see any indication in this ticket that this bug was actually *fixed* in 3.x.  Unicode doesn't cause immediate errors in 3.x, but it isn't recognized as wordchars, etc.  Am I missing something?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:12:02 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Sep 2011 16:12:02 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1316275922.09.0.125504909241.issue1170@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

I haven't looked at the shlex code (yet), my comment was just about the idea of adding constants with chars that belong to different Unicode categories.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:14:16 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 17 Sep 2011 16:14:16 +0000
Subject: [issue11935] MMDF/MBOX mailbox need utime
In-Reply-To: <1303904377.39.0.820877441013.issue11935@psf.upfronthosting.co.za>
Message-ID: <1316276056.67.0.393077252512.issue11935@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso  added the comment:

Let me close this!
I've just recently removed the real patch from my postman's "next"
branch, because even that real implementation doesn't work reliable.
I.e., please forget msg135791.  It was true, but on the long run
mutt(1) sometimes sees all, sometimes only some (really nuts), but
most of the time it simply does not see just any box with new mail.
That is, that "plugged-in filesystem" is simply handled as a pendant.

Remarks: because that stdlib MBOX whispered
  "Where Are Tho{u}, Brother"
to me all the {time}, i've done my own, also just recently:

== postman:
  - test: 321 messages (5083760 bytes) [action=hunky-dory]
  = Dispatched 321 tickets to 1 box.
  [69853 refs] real 0m35.538s user 0m6.760s sys 0m0.904s
..
  = Dispatched 1963 tickets to 1 box.
  [93552 refs] real 0m38.860s user 0m8.697s sys 0m0.985s
== stdlib:
  [83010 refs] real 1m3.862s user 0m10.151s sys 0m7.500s
  [93217 refs] real 7m24.958s user 2m0.174s sys 1m35.163s

Was worth it.
Have a good time!

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:16:11 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 17 Sep 2011 16:16:11 +0000
Subject: [issue11686] Update of some email/ __all__ lists
In-Reply-To: <1301159741.4.0.853509960092.issue11686@psf.upfronthosting.co.za>
Message-ID: <1316276171.52.0.768220668154.issue11686@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso  added the comment:

Closing this...

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:19:07 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 17 Sep 2011 16:19:07 +0000
Subject: [issue11780] email.encoders are broken
In-Reply-To: <1302087898.67.0.0241600221025.issue11780@psf.upfronthosting.co.za>
Message-ID: <1316276347.79.0.861374027151.issue11780@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso  added the comment:

I think this is historic either?
As far as i remember you solved it as part of another issue...

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:26:56 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 17 Sep 2011 16:26:56 +0000
Subject: [issue11701] email.parser.BytesParser().parse() closes file argument
In-Reply-To: <1301315420.28.0.123524956156.issue11701@psf.upfronthosting.co.za>
Message-ID: <1316276816.4.0.729905437041.issue11701@psf.upfronthosting.co.za>


Steffen Daode Nurpmeso  added the comment:

Right, and that is considered to be a non-issue due to
that close() is allowed multiple times without causing harm.

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:28:12 2011
From: report at bugs.python.org (Steffen Daode Nurpmeso)
Date: Sat, 17 Sep 2011 16:28:12 +0000
Subject: [issue11466] getpass.getpass doesn't close tty file
In-Reply-To: <1299844492.32.0.259676792362.issue11466@psf.upfronthosting.co.za>
Message-ID: <1316276892.93.0.213469685031.issue11466@psf.upfronthosting.co.za>


Changes by Steffen Daode Nurpmeso :


----------
nosy:  -sdaoden

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:31:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Sep 2011 16:31:45 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1316277105.86.0.707608251229.issue12737@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

I think string methods (and other parts of the stdlib) assume NFC and leave normalization to NFC up to the user.  Before fixing str.title() we should take a more general decision about handling strings that use other normalization forms.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:35:03 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Sep 2011 16:35:03 +0000
Subject: [issue13000] unhandled exception at  install
In-Reply-To: <1316261175.24.0.481643908897.issue13000@psf.upfronthosting.co.za>
Message-ID: <1316277303.97.0.22222813431.issue13000@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

And which version, exactly?  Which file, downloaded from where?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:38:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Sep 2011 16:38:18 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1316277498.57.0.0177926747799.issue4153@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:47:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 17 Sep 2011 16:47:47 +0000
Subject: [issue12508] Codecs Anomaly
In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>
Message-ID: <1316278067.86.0.927795690805.issue12508@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +lemburg

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:55:20 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Sep 2011 16:55:20 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316278520.78.0.288104655231.issue12961@psf.upfronthosting.co.za>


Changes by Georg Brandl :


----------
title: unlabelled balls in boxes -> itertools: unlabelled balls in boxes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 18:55:44 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Sep 2011 16:55:44 +0000
Subject: [issue12987] Demo/scripts/newslist.py has non-free licensing terms
In-Reply-To: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za>
Message-ID: <1316278544.72.0.965599398889.issue12987@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

The only resonable fix to make would be removal from the distribution.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 19:41:25 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 17 Sep 2011 17:41:25 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316281285.5.0.926150319835.issue12943@psf.upfronthosting.co.za>


Meador Inge  added the comment:

v2 patch which addresses comments made by merwok via rietveld.

----------
Added file: http://bugs.python.org/file23184/issue12943-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 19:45:55 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Sep 2011 17:45:55 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316281555.29.0.0647160677841.issue12943@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Looks good to me. Did you get commit rights already?

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 19:47:15 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Sep 2011 17:47:15 +0000
Subject: [issue12960] threading.Condition is not a class
In-Reply-To: <1315748239.01.0.928739848932.issue12960@psf.upfronthosting.co.za>
Message-ID: <1316281635.56.0.127741775957.issue12960@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

I don't think this is important enough. It's now a class anyway in 3.3+.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 20:00:20 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 17 Sep 2011 18:00:20 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316282420.69.0.622638621994.issue12943@psf.upfronthosting.co.za>


Meador Inge  added the comment:

> Did you get commit rights already?

I have not.  I still need to submit a contributor agreement as well.  I
plan to fax that today.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 20:23:08 2011
From: report at bugs.python.org (LMO)
Date: Sat, 17 Sep 2011 18:23:08 +0000
Subject: [issue12956] builds fail when installing to --prefix with space in
	path name
In-Reply-To: <1316273717.54.0.744722114256.issue12956@psf.upfronthosting.co.za>
Message-ID: 


LMO  added the comment:

I don't see supporting spaces as being important, either.  Since the failure is not obviously related to the presence of spaces, I would like to see the limitation documented.

> 
> ?ric Araujo  added the comment:
> 
>> While I'm sympathetic to supporting arbitrary path names, I'm not sure
>> if it is worth the effort.
> 
> My sentiment too.  Supporting non-ASCII characters seems clearly important to me, as it?s a reasonable and common thing to run or install Python from a patch that may contain non-ASCII characters (a first name, ?downloads? in French, etc.); supporting spaces is less important.
> 
> ----------
> nosy: +eric.araujo
> 
> _______________________________________
> Python tracker 
> 
> _______________________________________

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 20:24:20 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Sep 2011 18:24:20 +0000
Subject: [issue12960] threading.Condition is not a class
In-Reply-To: <1315748239.01.0.928739848932.issue12960@psf.upfronthosting.co.za>
Message-ID: <1316283860.98.0.904188638948.issue12960@psf.upfronthosting.co.za>


Raymond Hettinger  added the comment:

I recommend just closing this.

----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 20:26:12 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Sep 2011 18:26:12 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316283972.5.0.290487764255.issue12961@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
priority: normal -> low

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 20:27:49 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 17 Sep 2011 18:27:49 +0000
Subject: [issue12977] socket.socket.setblocking does not raise exception if no
	data available
In-Reply-To: <1316007719.98.0.0164178020562.issue12977@psf.upfronthosting.co.za>
Message-ID: <1316284069.3.0.946588159446.issue12977@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

I think you're mistaking a closed connection with "no data available".

Small demo that this works as intended:

>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> s.connect(('localhost', 1234))
>>> s.recv(10)
^CTraceback (most recent call last):
  File "", line 1, in 
KeyboardInterrupt
>>> s.setblocking(False)
>>> s.recv(10)
Traceback (most recent call last):
  File "", line 1, in 
socket.error: [Errno 11] Resource temporarily unavailable

The corresponding server:

>>> x = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> x.bind(('', 1234))
>>> x.listen(1)
>>> x.accept()
(, ('127.0.0.1', 39146))

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 21:28:25 2011
From: report at bugs.python.org (Florian Loitsch)
Date: Sat, 17 Sep 2011 19:28:25 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1316287705.65.0.758619890428.issue12450@psf.upfronthosting.co.za>


Florian Loitsch  added the comment:

FYI: the double-conversion library at http://code.google.com/p/double-conversion already contains code for the fallback case. It would not be necessary to keep Python's existing code just for the 0.5%.
The library is now used by Firefox, Chrome, and Webkit, and should be well tested.
It's biggest deficiency (compared to Gay's dtoa.c) is its specialization to IEEE doubles. Floats or long doubles are not supported. If Python needs to support these types I recommend not to switch.

----------
nosy: +Florian.Loitsch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 22:03:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Sep 2011 20:03:03 +0000
Subject: [issue11686] Update of some email/ __all__ lists
In-Reply-To: <1301159741.4.0.853509960092.issue11686@psf.upfronthosting.co.za>
Message-ID: <1316289783.35.0.347354512397.issue11686@psf.upfronthosting.co.za>


R. David Murray  added the comment:

Why?  The bug hasn't been fixed yet.

----------
assignee:  -> r.david.murray
stage:  -> patch review
status: closed -> open
versions: +Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 22:06:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Sep 2011 20:06:07 +0000
Subject: [issue11780] email.encoders are broken
In-Reply-To: <1302087898.67.0.0241600221025.issue11780@psf.upfronthosting.co.za>
Message-ID: <1316289967.72.0.266908104522.issue11780@psf.upfronthosting.co.za>


R. David Murray  added the comment:

I may have, but I'd prefer to check before closing the issue.  (I'm deep in another project right now, but I'll review all these open bugs this fall some time).

----------
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 23:26:44 2011
From: report at bugs.python.org (poq)
Date: Sat, 17 Sep 2011 21:26:44 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1316294804.26.0.141305331113.issue12997@psf.upfronthosting.co.za>


poq  added the comment:

Works for me?

$ python2.7 t.py
Traceback (most recent call last):
  File "t.py", line 13, in 
    con.execute("insert into track (artist_id) values (1)")
sqlite3.IntegrityError: foreign key constraint failed
$ python3.2 t.py
Traceback (most recent call last):
  File "t.py", line 13, in 
    con.execute("insert into track (artist_id) values (1)")
sqlite3.IntegrityError: foreign key constraint failed

----------
nosy: +poq

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 17 23:47:26 2011
From: report at bugs.python.org (poq)
Date: Sat, 17 Sep 2011 21:47:26 +0000
Subject: [issue12993] prepared statements in sqlite3 module
In-Reply-To: <1316176459.71.0.201980894918.issue12993@psf.upfronthosting.co.za>
Message-ID: <1316296046.48.0.323470592892.issue12993@psf.upfronthosting.co.za>


poq  added the comment:

The sqlite3 module already uses prepared statements. Quoting from the documentation:

"The sqlite3 module internally uses a statement cache to avoid SQL parsing overhead. If you want to explicitly set the number of statements that are cached for the connection, you can set the cached_statements parameter. The currently implemented default is to cache 100 statements."

----------
nosy: +poq

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 01:17:36 2011
From: report at bugs.python.org (Mark Bucciarelli)
Date: Sat, 17 Sep 2011 23:17:36 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1316301456.5.0.286651424336.issue12997@psf.upfronthosting.co.za>


Mark Bucciarelli  added the comment:

huh.  is it already on in your sqlite  install?

$ sqlite3
SQLite version 3.7.7.1 2011-06-28 17:39:05
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma foreign_keys;
0
sqlite> 

is what i get (it's off).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 01:58:13 2011
From: report at bugs.python.org (jorge.seifert)
Date: Sat, 17 Sep 2011 23:58:13 +0000
Subject: [issue13000] unhandled exception at  install
In-Reply-To: <1316261175.24.0.481643908897.issue13000@psf.upfronthosting.co.za>
Message-ID: <1316303893.3.0.0249544027371.issue13000@psf.upfronthosting.co.za>


jorge.seifert  added the comment:

Version 2,7,2
file python 2.7.2.msi
downloaded from this website

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 02:10:45 2011
From: report at bugs.python.org (jorge.seifert)
Date: Sun, 18 Sep 2011 00:10:45 +0000
Subject: [issue13000] unhandled exception at  install
In-Reply-To: <1316261175.24.0.481643908897.issue13000@psf.upfronthosting.co.za>
Message-ID: <1316304645.49.0.658588971345.issue13000@psf.upfronthosting.co.za>


jorge.seifert  added the comment:

'msiexec.exe': Loaded 'C:\WINDOWS\system32\msiexec.exe', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\secur32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\user32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\msi.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\imm32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_05FDF087\comctl32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\Documents and Settings\All Users\Datos de programa\Real\RealPlayer\BrowserRecordPlugin\Chrome\Hook\rpchrome10browserrecordhelper.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_31a54e43\msvcr90.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\shell32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_31a54e43\msvcp90.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\msctf.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\Archivos de programa\ScanSoft\OmniPageSE4\OpHookSE4.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\version.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\apphelp.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\msctfime.ime', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\uxtheme.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\sfc.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\sfc_os.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\wintrust.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\crypt32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\msasn1.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\imagehlp.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\netapi32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\rsaenh.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\psapi.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\userenv.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\cryptnet.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\wldap32.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\sensapi.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\clbcatq.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\comres.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\xpsp2res.dll', Binary was not built with debug information.
'msiexec.exe': Loaded 'C:\WINDOWS\system32\mscoree.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\mscoreei.dll', Cannot find or open the PDB file
'msiexec.exe': Loaded 'C:\WINDOWS\system32\msihnd.dll', Cannot find or open the PDB file
Unhandled exception at 0x60d35efa in msiexec.exe: 0xC0000005: Access violation reading location 0x00000020.
First-chance exception at 0x60d35efa in msiexec.exe: 0xC0000005: Access violation reading location 0x00000020.
Unhandled exception at 0x60d35efa in msiexec.exe: 0xC0000005: Access violation reading location 0x00000020.
First-chance exception at 0x60d35efa in msiexec.exe: 0xC0000005: Access violation reading location 0x00000020.
The thread 'Win32 Thread' (0xa88) has exited with code 0 (0x0).
Unhandled exception at 0x60d35efa in msiexec.exe: 0xC0000005: Access violation reading location 0x00000020.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 04:57:01 2011
From: report at bugs.python.org (poq)
Date: Sun, 18 Sep 2011 02:57:01 +0000
Subject: [issue12997] sqlite3: PRAGMA foreign_keys = ON doesn't work
In-Reply-To: <1316213659.17.0.858548174329.issue12997@psf.upfronthosting.co.za>
Message-ID: <1316314621.94.0.409387806433.issue12997@psf.upfronthosting.co.za>


poq  added the comment:

Nope.

$ sqlite3
SQLite version 3.7.4
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma foreign_keys;
0
sqlite>

$ python
Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> c = sqlite3.connect(':memory:')
>>> list(c.execute('pragma foreign_keys'))
[(0,)]
>>> list(c.execute('pragma foreign_keys = on'))
[]
>>> list(c.execute('pragma foreign_keys'))
[(1,)]

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 05:30:26 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Sun, 18 Sep 2011 03:30:26 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316316626.0.0.791453543272.issue12961@psf.upfronthosting.co.za>


Phillip Feldman  added the comment:

"The itertools module should only have a few of the most generally useful, especially in combination with other tools."

Balls-in-boxes _is_ one of the most basic of the canonical combinatorial problems.  You can verify this by opening any text on combinatorics or combinatorial probability.

"An extensive combinatorics package would be a different project. (And I have done a bit of work in this direction.)"

It sounds as though your project is in its infancy, but I'd like to see what you've got if you are willing to share.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 06:34:48 2011
From: report at bugs.python.org (Damian)
Date: Sun, 18 Sep 2011 04:34:48 +0000
Subject: [issue12972] Color prompt + readline
In-Reply-To: <1315927772.69.0.871921956001.issue12972@psf.upfronthosting.co.za>
Message-ID: <1316320488.58.0.76143075653.issue12972@psf.upfronthosting.co.za>


Damian  added the comment:

Retested with Python 3.1.1 and this issue doesn't manifest. This can be resolved - sorry about the noise. :)

----------
nosy: +atagar

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 06:55:23 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 18 Sep 2011 04:55:23 +0000
Subject: [issue13003] Bug in equivalent code for itertools.izip_longest
Message-ID: <1316321723.69.0.619993124857.issue13003@psf.upfronthosting.co.za>


New submission from Eli Bendersky :

Regarding the sample code in: http://docs.python.org/library/itertools#itertools.izip_longest

If an IndexError is raised inside an iterator in the "equivalent" code
from the docs, the generator stops and the error is swallowed.

If an IndexError is raised inside an iterator in the
"izip_longest_next" code in CPython's "Modules/itertoolsmodule.c", the
generator stops and the error propagates.

---

Reported by Adam Forsyth on the docs mailing list. More details in this SO discussion: http://stackoverflow.com/questions/7392902/izip-longest-in-itertools-how-does-rasing-indexerror-inside-the-iterator-work

----------
assignee: docs at python
components: Documentation
messages: 144228
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: Bug in equivalent code for itertools.izip_longest
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 07:36:07 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Sep 2011 05:36:07 +0000
Subject: [issue13003] Bug in equivalent code for itertools.izip_longest
In-Reply-To: <1316321723.69.0.619993124857.issue13003@psf.upfronthosting.co.za>
Message-ID: <1316324167.14.0.443555040142.issue13003@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

I had forwarded this to Raymond, and he replied:

The itertools module code is correct.
The "equivalent" is only approximately correct 
I don't consider it to be a bug -- it is an implementation detail in an illustration.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 07:40:34 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Sep 2011 05:40:34 +0000
Subject: [issue13000] unhandled exception at  install
In-Reply-To: <1316261175.24.0.481643908897.issue13000@psf.upfronthosting.co.za>
Message-ID: <1316324434.12.0.139743097079.issue13000@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Thanks!

----------
assignee:  -> brian.curtin
nosy: +brian.curtin, loewis

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 07:50:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 18 Sep 2011 05:50:07 +0000
Subject: [issue13003] Bug in equivalent code for itertools.izip_longest
In-Reply-To: <1316321723.69.0.619993124857.issue13003@psf.upfronthosting.co.za>
Message-ID: <1316325007.82.0.00495382194177.issue13003@psf.upfronthosting.co.za>


Eli Bendersky  added the comment:

What about at least documenting it? Since a real user ran into this and reported it as a problem, I think it would make sense to make the discrepancy explicit.

Alternatively a generalized note can be added to the documentation of itertools stating that the "equivalent" code samples are only approximate and differ in small details from the real implementations.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 07:53:08 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 18 Sep 2011 05:53:08 +0000
Subject: [issue13003] Bug in equivalent code for itertools.izip_longest
In-Reply-To: <1316321723.69.0.619993124857.issue13003@psf.upfronthosting.co.za>
Message-ID: <1316325188.29.0.996824436822.issue13003@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Well, this is for Raymond to decide.

----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 10:45:53 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Sep 2011 08:45:53 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1316335553.34.0.251282744288.issue12737@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

Tom: it's intentional that .title() doesn't use traditional word break algorithms. In 2.x, "foo3bar".title() is "Foo3Bar", i.e. the 3 counts as a word end. So neither UTS#18 \w nor UAX#29 apply. So in UTS#18 terminology, .title() matches more closes \alpha+, despite UTS#18 saying that this shouldn't be used for word-breaking.

It's not clear to me how UTS#18 defines \alpha. On the one hand, they say that marks should be included, OTOH they refer to the Alphabetic derived category which doesn't include marks, except for the few that have been included in Other_Alphatetic.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 11:17:06 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 18 Sep 2011 09:17:06 +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: <1316337426.18.0.47922233893.issue10181@psf.upfronthosting.co.za>


Changes by Stefan Krah :


Added file: http://bugs.python.org/file23185/4492afe05a07.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 11:22:30 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 18 Sep 2011 09:22:30 +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: <1316337750.74.0.0991522641089.issue10181@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Revision 4492afe05a07 allows memoryview to handle objects with an
__index__() method. This is for compatibility with the struct module
(See also #8300).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 11:38:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Sep 2011 09:38:32 +0000
Subject: [issue12960] threading.Condition is not a class
In-Reply-To: <1315748239.01.0.928739848932.issue12960@psf.upfronthosting.co.za>
Message-ID: <1316338712.17.0.952340732497.issue12960@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 11:50:45 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Sep 2011 09:50:45 +0000
Subject: [issue12999] _XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED usage on Solaris
In-Reply-To: <1316244012.97.0.109004277803.issue12999@psf.upfronthosting.co.za>
Message-ID: <1316339445.69.0.832216020048.issue12999@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

Martin dropped _XOPEN_SOURCE in issue #1759169 (commit 7c947768b435).

--

FYI I changed configure(.in) to get _XOPEN_SOURCE to 700 on OpenBSD 5 to get recent C functions like fdopendir():

  # X/Open 7, incorporating POSIX.1-2008
  AC_DEFINE(_XOPEN_SOURCE, 700,
            Define to the level of X/Open that your system supports)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 11:56:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Sep 2011 09:56:53 +0000
Subject: [issue12996] multiprocessing.Connection endianness issue
In-Reply-To: <1316198455.11.0.87432837805.issue12996@psf.upfronthosting.co.za>
Message-ID: <1316339813.1.0.605581029272.issue12996@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

"Since the rewrite in pure Python of multiprocessing.Connection (issue #11743), multiprocessing.Connection sends and receives the length of the data (used as header) in host byte order."

I don't think so, the C code uses also the host endian. This issue is a feature request.

I don't know if anyone uses multiprocessing on different hosts (because it doesn't work currently).

If you would like to support using multiprocessing on different hosts, it should be documented in multiprocessing doc.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 12:00:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Sep 2011 10:00:53 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316340053.82.0.0896743748417.issue12981@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

"It works fine on Linux, FreeBSD, OS X and Windows, but not on Solaris: see issue #12999."

Oh, thank for testing before committing :) It's hard to debug multiprocessing.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 12:10:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Sep 2011 10:10:27 +0000
Subject: [issue13001] test_socket.testRecvmsgTrunc failure on FreeBSD 7.2
	buildbot
In-Reply-To: <1316270071.04.0.179563462632.issue13001@psf.upfronthosting.co.za>
Message-ID: <1316340627.52.0.056452746704.issue13001@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

@requires_freebsd_version should be factorized with @requires_linux_version.

Can we workaround FreeBSD (< 8) bug in C/Python? Or should we remove the function on FreeBSD < 8?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 13:02:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Sep 2011 11:02:28 +0000
Subject: [issue12996] multiprocessing.Connection endianness issue
In-Reply-To: <1316339813.1.0.605581029272.issue12996@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

> "Since the rewrite in pure Python of multiprocessing.Connection (issue #11743), multiprocessing.Connection sends and receives the length of the data (used as header) in host byte order."
>
> I don't think so, the C code uses also the host endian. This issue is a feature request.
>

No.
http://hg.python.org/cpython/file/5deecc04b7a2/Modules/_multiprocessing/socket_connection.c
In conn_send_string():
"""
     /* The "header" of the message is a 32 bit unsigned number (in
        network order) which specifies the length of the "body".  If
        the message is shorter than about 16kb then it is quicker to
        combine the "header" and the "body" of the message and send
        them at once. */
[...]
         *(UINT32*)message = htonl((UINT32)length);
"""

in conn_recv_string():
"""
     ulength = ntohl(ulength);
"""

> I don't know if anyone uses multiprocessing on different hosts (because it doesn't work currently).
>
> If you would like to support using multiprocessing on different hosts, it should be documented in multiprocessing doc.

It does work, it's even documented ;-)

http://docs.python.org/dev/library/multiprocessing.html#multiprocessing-managers
"""
A manager object returned by Manager() controls a server process which
holds Python objects and allows other processes to manipulate them
using proxies.
[...]
Server process managers are more flexible than using shared memory
objects because they can be made to support arbitrary object types.
Also, a single manager can be shared by processes on different
computers over a network. They are, however, slower than using shared
memory.
"""

Managers use multiprocessing.connection to serialize data and send
them over a socket:
http://hg.python.org/cpython/file/5deecc04b7a2/Lib/multiprocessing/managers.py
"""
#
# Mapping from serializer name to Listener and Client types
#
listener_client = {
     'pickle' : (connection.Listener, connection.Client),
     'xmlrpclib' : (connection.XmlListener, connection.XmlClient)
     }
"""

Yeah, Python's awesome :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 13:05:55 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Sep 2011 11:05:55 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316340053.82.0.0896743748417.issue12981@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

> "It works fine on Linux, FreeBSD, OS X and Windows, but not on Solaris: see issue #12999."
>
> Oh, thank for testing before committing :) It's hard to debug multiprocessing.

Yes. Especially when you stumble upon a kernel/libc bug 25% of the time...

So, what should I do?
Apply the test catching the multiprocessing.connection ImportError to
test_multiprocessing (which is necessary even with the current C
version)?

And then apply the pure Python version, or wait until the OpenIndiana
case gets fixed?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 13:35:06 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Sep 2011 11:35:06 +0000
Subject: [issue12958] test_socket failures on Mac OS X
In-Reply-To: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>
Message-ID: <1316345706.69.0.994945026618.issue12958@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

OK, I've now looked into *why* the socket tests are throwing errors in tearDown, and it has to do with the way the threaded client/server tests in test_socket are set up.

Specifically, ThreadableTest uses tearDown to reraise any exception raised in the client thread, and these are therefore outside the scope of the "expectedFailure" suppression in unittest.

Now that I've tracked this down, it would be fairly straightforward to fix this specifically within test_socket.ThreadableTest by appropriately adjusting the definition of ThreadableTest.clientRun to discard exceptions encountered in tests flagged as expected failures.

However, I'm wondering if that's the right thing to do. Perhaps it would make more sense to change unittest itself so that "expectedFailure" also suppresses tearDown errors. It doesn't seem all that unusual for a known failing test to also cause problems for the tearDown code.

Added Michael to the nosy list to ask for his advice/opinion. In the meantime, I'll work on a patch that adjusts ThreadableTest directly.

----------
assignee:  -> ncoghlan
nosy: +michael.foord

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 14:27:18 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Sep 2011 12:27:18 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1316348838.02.0.985571504231.issue1294232@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

Looking at Daniel's updated patch is still on my to-do list, but I won't object if anyone else wants to take this forward (it will be at least a few weeks before I get to it).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 16:11:00 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 18 Sep 2011 14:11:00 +0000
Subject: [issue12938] html.escape docstring does not mention single quotes (')
In-Reply-To: <1315508448.5.0.992592094222.issue12938@psf.upfronthosting.co.za>
Message-ID: <1316355060.06.0.555512043784.issue12938@psf.upfronthosting.co.za>


Senthil Kumaran  added the comment:

This is fixed in all revisions.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 16:58:32 2011
From: report at bugs.python.org (Debao Zhang)
Date: Sun, 18 Sep 2011 14:58:32 +0000
Subject: [issue11320] Can't call Py_SetPath() on pointer returned by
	Py_GetPath()
In-Reply-To: <1298644323.49.0.991957845562.issue11320@psf.upfronthosting.co.za>
Message-ID: <1316357912.44.0.729526450771.issue11320@psf.upfronthosting.co.za>


Debao Zhang  added the comment:

Hello everyone,

I have found the reason for the problem.

>From the manual http://docs.python.org/py3k/c-api/init.html#Py_SetPath , 
we can see that:

After we call Py_SetPath,both sys.prefix and sys.exec_prefix will be empty.

However, sys.prefix will be used in the sysconfig.py to generate the makefile' s name, and the empty sys.prefix will cause the wrong path: lib/python3.2/config-3.2m/Makefile

sysconfig.py imported by site.py, and site.py used in the Py_InitializeEx.

So ...

----------
nosy: +dbzhang800

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 19:10:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 18 Sep 2011 17:10:26 +0000
Subject: [issue12972] Color prompt + readline
In-Reply-To: <1315927772.69.0.871921956001.issue12972@psf.upfronthosting.co.za>
Message-ID: <1316365826.62.0.961770978437.issue12972@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Since 2.7 was released after 3.1, I will assumed any bugfix was applied there also until someone determines otherwise. Thanks for checking.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 19:16:03 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 18 Sep 2011 17:16:03 +0000
Subject: [issue12450] Use the Grisu algorithms to convert floats to strings
In-Reply-To: <1309421957.37.0.89091198831.issue12450@psf.upfronthosting.co.za>
Message-ID: <1316366163.68.0.361934308665.issue12450@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> It's biggest deficiency (compared to Gay's dtoa.c) is its specialization > to IEEE doubles.

We're only using the portion of Gay's code (with some significant modifications at this point) that applies to the IEEE 754 binary64 format, so I don't think this is a concern.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 19:41:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 18 Sep 2011 17:41:13 +0000
Subject: [issue13004] pprint: add option to truncate seqeunces
Message-ID: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>


New submission from Terry J. Reedy :

>From python-ideas thread "truncate sequences in pretty-print ?"
On Sat, Sep 17, 2011 at 9:59 PM, Steven Samuel Cole
> i use pprint quite a bit during development to give me quick insight
> into what is going on inside my application.
> however, when there's any sequences involved, the output becomes less
> useful the longer these sequences are - i often find myself scrolling
> around (or even searching) in the terminal window, trying to find the
> bit of output i am interested in.
>
> imo, it would be great if pprint had a parameter 'max_len' or so that
> reduces output of every sequence to a maximum and inserts something
> like '...' to indicate truncation, e.g.
> {'my key': ['my list item 01',
>            'my list item 02',
>            'my list item 03',
>            'my list item 04',
>            'my list item 05',
>            'my list item 06',
>            'my list item 07',
>            'my list item 08',
>            '...',
>            'my list item 10',]}
>
> somewhat comparable to the '...' already printed when a structure is
> more deeply nested than you want to know right now.

On 9/18/2011 10:59 AM, Guido van Rossum wrote:
Agreed, this would be a useful feature. I've reimplemented something
like pprint a few times and always had to implement this truncation
feature. If you or someone can contribute a patch that would be much
appreciated!

----------
components: Library (Lib)
messages: 144247
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: pprint: add option to truncate seqeunces
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 19:42:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Sep 2011 17:42:01 +0000
Subject: [issue13004] pprint: add option to truncate seqeunces
In-Reply-To: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>
Message-ID: <1316367721.7.0.0926111747319.issue13004@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 20:15:55 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 18 Sep 2011 18:15:55 +0000
Subject: [issue12958] test_socket failures on Mac OS X
In-Reply-To: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>
Message-ID: <1316369755.47.0.30625873856.issue12958@psf.upfronthosting.co.za>


Michael Foord  added the comment:

See issue 10548. There is some resistance to expectedFailure masking errors in setUp/tearDown as these aren't the place where you would normally expect the expected failure...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 20:26:11 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Sep 2011 18:26:11 +0000
Subject: [issue13000] unhandled exception at  install
In-Reply-To: <1316261175.24.0.481643908897.issue13000@psf.upfronthosting.co.za>
Message-ID: <1316370371.89.0.663400796185.issue13000@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

Can you please run

msiexec /i python2.7.2.msi /l*v python.log

and compress and attach the resulting python.log?

I'm skeptical though that we will be able to do anything about this issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 21:14:54 2011
From: report at bugs.python.org (Benny Siegert)
Date: Sun, 18 Sep 2011 19:14:54 +0000
Subject: [issue12976] add support for MirBSD platform
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316373294.08.0.226480642024.issue12976@psf.upfronthosting.co.za>


Benny Siegert  added the comment:

I agree that the patch is quite small. I am regularly building new Python versions (using pkgsrc) so I can maintain the patch for future releases.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 21:24:55 2011
From: report at bugs.python.org (Luciano Ramalho)
Date: Sun, 18 Sep 2011 19:24:55 +0000
Subject: [issue13005] operator module docs include repeat
Message-ID: <1316373895.0.0.0510419466495.issue13005@psf.upfronthosting.co.za>


New submission from Luciano Ramalho :

The operator module documentation for versions 3.2 and 3.3 includes the repeat function in a table "9.3.1. Mapping Operators to Functions" [1], but fails to mention that the repeat function is deprecated and mul should be used instead, as described in the 2.7 version of the operator module docs [2].

The main entry for the repeat function was removed in the 3.2 and 3.3 docs, only the mention in the table remains [1].

[1] http://docs.python.org/py3k/library/operator#mapping-operators-to-functions
[2] http://docs.python.org/library/operator#operator.__repeat__

----------
assignee: docs at python
components: Documentation
messages: 144251
nosy: docs at python, luciano
priority: normal
severity: normal
status: open
title: operator module docs include repeat
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 21:26:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 18 Sep 2011 19:26:12 +0000
Subject: [issue13005] operator module docs include repeat
In-Reply-To: <1316373895.0.0.0510419466495.issue13005@psf.upfronthosting.co.za>
Message-ID: <1316373972.12.0.124072534695.issue13005@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti, sandro.tosi
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 21:54:11 2011
From: report at bugs.python.org (David Watson)
Date: Sun, 18 Sep 2011 19:54:11 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316375651.72.0.838199389071.issue12981@psf.upfronthosting.co.za>


David Watson  added the comment:

I had a look at this patch, and the FD passing looked OK, except
that calculating the buffer size with CMSG_SPACE() may allow more
than one file descriptor to be received, with the extra one going
unnoticed - it should use CMSG_LEN() instead (the existing C
implementation has the same problem, I see).

CMSG_SPACE() exists to allow calculating the space required to
hold multiple control messages, so it essentially gives the
offset for the next cmsghdr struct such that any alignment
requirements are satisfied.

64-bit systems will probably want to ensure that all CMSG_DATA()
payloads are aligned on 8-byte boundaries, and so have
CMSG_SPACE(4) == CMSG_SPACE(8) == CMSG_LEN(8) (the Linux headers,
for instance, align to sizeof(size_t)).  So with a 32-bit int, a
buffer size of CMSG_SPACE(sizeof(int)) would allow *two* file
descriptors to be received.  CMSG_LEN() omits the padding, thus
allowing only one.

I'm not familiar with how the FD-passing facility is used in
multiprocessing, but this seems as if it could be an avenue for
DoS attacks that exhaust the number of file descriptors allowed
for the receiving process.

----------
nosy: +baikie

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 21:58:24 2011
From: report at bugs.python.org (David Watson)
Date: Sun, 18 Sep 2011 19:58:24 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1316375904.34.0.92456835692.issue8623@psf.upfronthosting.co.za>


David Watson  added the comment:

For reference, the warnings are partially explained here:

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-825

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Warning-Options.html#index-Wstrict_002daliasing-337

I get these warnings with GCC (Ubuntu/Linaro 4.4.4-14ubuntu5)
4.4.5 [i386], plus an additional one from the new recvmsg() code.
I haven't tried GCC 4.5 or later, but as the docs imply, the
warnings will not appear in debugging builds.

I take it GCC is referring to C99 section 6.5, paragraphs 6 and 7
here, but I'm not sure exactly how much these are intended to
prohibit with regard to the (mis)use of unions, or how strictly
GCC actually enforces them.

The attached socket-aliasing-sas2sa.diff is enough to get rid of
the warnings with GCC 4.4.4 - it adds add a "struct sockaddr"
member to the sock_addr_t union type, changes the SAS2SA() macro
to take the address of this member instead of using a cast, and
modifies socket_gethostbyaddr() and socket_gethostbyname_ex() to
use SAS2SA() (sock_recvmsg_guts() already uses it).

Changing SAS2SA() also gets rid of most of the additional
warnings produced by the "aggressive" warning setting
-Wstrict-aliasing=2.  However, the gethostby* functions still
point to the union object with a pointer variable not matching
the type actually stored in it, which the GCC docs warn against.

To be more conservative, socket-aliasing-union-3.2.diff applies
on top to get rid of these pointers, and instead directly access
the union for each use other than providing a pointer argument to
a function.  socket-aliasing-union-recvmsg-3.3.diff does the same
for 3.3, and makes the complained-about line in
sock_recvmsg_guts() access the union directly as well.

One other consideration here is that the different sockaddr_*
struct types used are likely to come under the "common initial
sequence" rule for unions (C99 6.5.2.3, paragraph 5, or section
A8.3 of K&R 2nd ed.), which might make some more questionable
uses valid.  That said, technically POSIX appears to require only
that the s*_family members of the various sockaddr struct types
have the same offset and type, not that they form part of a
common initial sequence (s*_family need not be the first
structure member - the BSDs for instance place it second,
although it can still be part of a common initial sequence).

----------
keywords: +patch
nosy: +baikie
versions: +Python 3.3
Added file: http://bugs.python.org/file23186/socket-aliasing-sas2sa.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 21:58:46 2011
From: report at bugs.python.org (David Watson)
Date: Sun, 18 Sep 2011 19:58:46 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1316375926.88.0.923509686294.issue8623@psf.upfronthosting.co.za>


Changes by David Watson :


Added file: http://bugs.python.org/file23187/socket-aliasing-union-3.2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 21:58:58 2011
From: report at bugs.python.org (David Watson)
Date: Sun, 18 Sep 2011 19:58:58 +0000
Subject: [issue8623] Aliasing warnings in socketmodule.c
In-Reply-To: <1273067856.13.0.617035378143.issue8623@psf.upfronthosting.co.za>
Message-ID: <1316375938.43.0.701145379099.issue8623@psf.upfronthosting.co.za>


Changes by David Watson :


Added file: http://bugs.python.org/file23188/socket-aliasing-union-3.3.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 22:00:21 2011
From: report at bugs.python.org (David Watson)
Date: Sun, 18 Sep 2011 20:00:21 +0000
Subject: [issue13001] test_socket.testRecvmsgTrunc failure on FreeBSD 7.2
	buildbot
In-Reply-To: <1316270071.04.0.179563462632.issue13001@psf.upfronthosting.co.za>
Message-ID: <1316376021.54.0.500573784109.issue13001@psf.upfronthosting.co.za>


Changes by David Watson :


----------
nosy: +baikie

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 22:59:19 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 18 Sep 2011 20:59:19 +0000
Subject: [issue12976] add support for MirBSD platform
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316379559.76.0.566700160273.issue12976@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

Ok, closing this as "won't fix", them.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 23:11:40 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Sep 2011 21:11:40 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316380300.83.0.142812104939.issue12981@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

> I had a look at this patch, and the FD passing looked OK, except
> that calculating the buffer size with CMSG_SPACE() may allow more
> than one file descriptor to be received, with the extra one going
> unnoticed - it should use CMSG_LEN() instead

Thanks for catching this.
Here's an updated patch.

> (the existing C implementation has the same problem, I see).

I just checked, and the C version uses CMSG_SPACE() as the buffer size, but passes CMSG_LEN() to cmsg->cmsg_len and msg.msg_controllen. Or am I missing something?

----------
Added file: http://bugs.python.org/file23189/multiprocessing_fd-3.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 18 23:12:02 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 18 Sep 2011 21:12:02 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316380322.36.0.646353373464.issue12981@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


Removed file: http://bugs.python.org/file23180/multiprocessing_fd-2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 00:45:30 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sun, 18 Sep 2011 22:45:30 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <4E690F86.60500@udel.edu>
Message-ID: <12256.1316385915@chthon>


Tom Christiansen  added the comment:

"Terry J. Reedy"  wrote
   on Thu, 08 Sep 2011 18:56:11 -0000: 

>On 9/8/2011 4:32 AM, Ezio Melotti wrote:

>> So to summarize a bit, there are different possible level of strictness:
>>    1) all the possible encodable values, including the ones>10FFFF;
>>    2) values in range 0..10FFFF;
>>    3) values in range 0..10FFFF except surrogates (aka scalar values);
>>    4) values in range 0..10FFFF except surrogates and noncharacters;

>> and this is what is currently available in Python:
>>    1) not available, probably it will never be;
>>    2) available through the 'surrogatepass' error handler;
>>    3) default behavior (i.e. with the 'strict' error handler);
>>    4) currently not available.

>> Now, assume that we don't care about option 1 and want to implement the missing option 4 (which I'm still not 100% sure about).  The possible options are:
>>    * add a new codec (actually one for each UTF encoding);
>>    * add a new error handler that explicitly disallows noncharacters;
>>    * change the meaning of 'strict' to match option 4;

> If 'strict' meant option 4, then 'scalarpass' could mean option 3. 
> 'surrogatepass' would then mean 'pass surragates also, in addition to 
> non-char scalers'.

I'm pretty sure that anything that claims to be UTF-{8,16,32} needs  
to reject both surrogates *and* noncharacters. Here's something from the
published Unicode Standard's p.24 about noncharacter code points:

    ? Noncharacter code points are reserved for internal use, such as for 
      sentinel values. They should never be interchanged. They do, however,
      have well-formed representations in Unicode encoding forms and survive
      conversions between encoding forms. This allows sentinel values to be
      preserved internally across Unicode encoding forms, even though they are
      not designed to be used in open interchange.

And here from the Unicode Standard's chapter on Conformance, section 3.2, p. 59:

    C2 A process shall not interpret a noncharacter code point as an 
       abstract character.

        ? The noncharacter code points may be used internally, such as for 
          sentinel values or delimiters, but should not be exchanged publicly.

I'd have to check the fine print, but I am pretty sure that "shall not" 
is an imperative form.  We have understand that to read that a comforming
process *must*not* do that.  It's because of that wording that in Perl,
using either of {en,de}code() with any of the "UTF-{8,16,32}" encodings,
including the LE/BE versions as appropriate, it will not produce nor accept
a noncharacter code point like FDD0 or FFFE.

Do you think we may perhaps have misread that conformance clause?

Using Perl's special, loose-fitting "utf8" encoding, you can get it do
noncharacter code points and even surrogates, but you have to suppress
certain things to make that happen quietly.  You can only do this with
"utf8", not any of the UTF-16 or UTF-32 flavors.  There we give them no 
choice, so you must be strict.  I agree this is not fully orthogonal.

Note that this is the normal thing that people do:

    binmode(STDOUT, ":utf8");

which is the *loose* version.  The strict one is "utf8-strict" or "UTF-8":

    open(my $fh, "< :encoding(UTF-8)", $pathname)

So it is a bit too easy to get the loose one.  We felt we had to do this
because we were already using the loose definition (and allowing up to
chr(2**32) etc) when the Unicode Consortium made clear what sorts of
things must not be accepted, or perhaps, before we made ourselves clear
on this.  This will have been back in 2003, when I wasn't paying very
close attention.

I think that just like Perl, Python has a legacy of the original loose
definition.  So some way to accommodate that legacy while still allowing
for a comformant application should be devised.  My concern with Python
is that people tend to make they own manual calls to encode/decode a lot
more often than they do in Perl.  That people that if you only catch it
on a stream encoding, you'll miss it, because they will use binary I/O
and miss the check.

--tom

    Below I show a bit of how this works in Perl.  Currently the builtin
    utf8 encoding is controlled somewhat differently from how the Encode
    module's encode/decode functions are.  Yes, this is not my idea of good.

    This shows that noncharacters and surrogates do not survive the
    encoding/decoding process for UTF-16:

        % perl -CS -MEncode -wle 'print decode("UTF-16", encode("UTF-16", chr(0xFDD0)))' | uniquote -v
        \N{REPLACEMENT CHARACTER}
        % perl -CS -MEncode -wle 'print decode("UTF-16", encode("UTF-16", chr(0xFFFE)))' | uniquote -v
        \N{REPLACEMENT CHARACTER}
        % perl -CS -MEncode -wle 'print decode("UTF-16", encode("UTF-16", chr(0xD800)))' | uniquote -v
        UTF-16 surrogate U+D800 in subroutine entry at /usr/local/lib/perl5/5.14.0/darwin-2level/Encode.pm line 158.

    If you pass a third argument to encode/decode, you can tell it what to
    do on error; an argument of 1 raises an exception.  Not supplying a
    third argument gets the "default" behavior, which varies by encoding.
    (The careful programmer is apt to want to pass in an appropropriate
     bit mask of things like DIE_ON_ERR, WARN_ON_ERR, RETURN_ON_ERR,
     LEAVE_SRC, PERLQQ, HTMLCREF, or XMLCREF.)

    With "utf8" vs "UTF-8" using encode(), the default behavior is to swap in 
    the Unicode replacement character for things that don't map to the given 
    encoding, as you saw above with UTF-16:

        % perl -C0 -MEncode -wle 'print encode("utf8", chr(0xFDD0))' | uniquote -v
        \N{U+FDD0}
        % perl -C0 -MEncode -wle 'print encode("UTF-8", chr(0xFDD0))' | uniquote -v
        \N{REPLACEMENT CHARACTER}

        % perl -C0 -MEncode= -wle 'print encode("utf8", chr(0xD800))' | uniquote -v
        \N{U+D800}
        % perl -C0 -MEncode= -wle 'print encode("UTF-8", chr(0xFDD0))' | uniquote -v
        \N{REPLACEMENT CHARACTER}

        % perl -C0 -MEncode=:all -wle 'print encode("utf8", chr(0x100_0000))' | uniquote -v
        \N{U+1000000}
        % perl -C0 -MEncode=:all -wle 'print encode("UTF-8", chr(0x100_0000))' | uniquote -v
        \N{REPLACEMENT CHARACTER}

    With the builtin "utf8" encoding, which does *not* go through the
    Encode module, you instead control all this through lexical
    warnings/exceptions categories.   By default, you get a warning if
    you try to use noncharacter, surrogate, or nonunicode code points
    even on a loose utf8 stream (which is what -CS gets you):

        % perl -CS -le 'print chr for 0xFDD0, 0xD800, 0x100_0000' | uniquote
        Unicode non-character U+FDD0 is illegal for open interchange at -e line 1.
        Unicode surrogate U+D800 is illegal in UTF-8 at -e line 1.
        Code point 0x1000000 is not Unicode, may not be portable at -e line 1.
        \N{U+FDD0}
        \N{U+D800}
        \N{U+1000000}

    Notice I didn't ask for warnings there, but I still got them.  This
    promotes all utf8 warnings into exceptions, thus dying on the first one
    it finds:

        % perl -CS -Mwarnings=FATAL,utf8 -le 'print chr for 0xFDD0, 0xD800, 0x100_0000' | uniquote
        Unicode non-character U+FDD0 is illegal for open interchange at -e line 1.

    You can control these separately.  For example, these all die of an
    exception:

        % perl -CS -Mwarnings=FATAL,utf8 -wle 'print chr(0xFDD0)'   
        Unicode non-character U+FDD0 is illegal for open interchange at -e line 1.
        % perl -CS -Mwarnings=FATAL,utf8 -wle 'print chr(0xD800)'   
        Unicode surrogate U+D800 is illegal in UTF-8 at -e line 1.
        % perl -CS -Mwarnings=FATAL,utf8 -wle 'print chr(0x100_0000)' 
        Code point 0x1000000 is not Unicode, may not be portable at -e line 1.

    While these do not:

        % perl -CS -Mwarnings=FATAL,utf8 -wle 'no warnings "nonchar";     print chr(0xFDD0)'     | uniquote
        \N{U+FDD0}
        % perl -CS -Mwarnings=FATAL,utf8 -wle 'no warnings "surrogate";   print chr(0xD800)'     | uniquote
        \N{U+D800}
        % perl -CS -Mwarnings=FATAL,utf8 -wle 'no warnings "non_unicode"; print chr(0x100_0000)' | uniquote
        \N{U+1000000}

        % perl -CS -Mwarnings=FATAL,utf8 -wle 'no warnings qw(nonchar surrogate non_unicode);
                        print chr for 0xFDD0, 0xD800, 0x100_0000' | uniquote
        \N{U+FDD0}
        \N{U+D800}
        \N{U+1000000}

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 00:49:14 2011
From: report at bugs.python.org (Meador Inge)
Date: Sun, 18 Sep 2011 22:49:14 +0000
Subject: [issue1294232] Error in metaclass search order
Message-ID: <1316386154.67.0.150832338173.issue1294232@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
nosy: +meador.inge
stage: test needed -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 01:15:52 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Sep 2011 23:15:52 +0000
Subject: [issue12958] test_socket failures on Mac OS X
In-Reply-To: <1315719643.71.0.858357749479.issue12958@psf.upfronthosting.co.za>
Message-ID: <1316387752.63.0.804740706348.issue12958@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

OK, I'll just deal with the problem directly in test_socket then.

It looks like my latest attempt (suppressing unittest._ExpectedFailure in test_socket.ThreadableTest.clientRun) did the trick, so I'll push the updated tests some time this evening:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%202%20custom/builds/44/steps/test/logs/stdio

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 01:35:00 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Sep 2011 23:35:00 +0000
Subject: [issue10548] Error in setUp not reported as expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1316388900.51.0.0427929293823.issue10548@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

As another data point, this question came up again in the context of issue #12958.

The new test_socket.ThreadableTest uses tearDown() to pick up and reraise any exception that occurred in the client thread. This meant that my initial attempts at flagging some expected failures (due to Mac OS X limitations) didn't work - the client half of the failure was thrown in tearDown() and reported as an error.

While I've determined how to avoid that problem in the test_socket case, the general question of whether or not we consider it legitimate to put common assertions in setUp() and tearDown(), or expect that test code explicitly cope with tearDown() failures that occur due to expected test failures still needs to be addressed.

To my mind, bugs in my test infrastructure are going to get flushed out by tests that I'm neither skipping nor marking as expected failures. If I have a test that is known to fail in a way that invalidates the standard tearDown procedure for the test infrastructure, having to special case that situation in the tearDown code seems to go against the spirit of offering the "expectedFailure" decorator in the first place.

I don't think the same reasoning holds for setUp though - there's no way for a failing test to reach back and force setUp to fail, so any errors raised there are always going to be infrastructure errors.

----------
nosy: +ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 01:37:23 2011
From: report at bugs.python.org (Michael Foord)
Date: Sun, 18 Sep 2011 23:37:23 +0000
Subject: [issue10548] Error in setUp not reported as expectedFailure (unittest)
In-Reply-To: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>
Message-ID: <1316389043.25.0.465199682387.issue10548@psf.upfronthosting.co.za>


Michael Foord  added the comment:

I think Twisted uses the tearDown to fail tests as well. As we have two use cases perhaps we should allow expectedFailure to work with failues in tearDown? (And if we do that it should cover setUp as well for symmetry or it becomes a morass of special cases.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 03:23:35 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Sep 2011 01:23:35 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1316395415.93.0.0472611881591.issue12729@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

My long-ago memory is that 'should not' is slightly looser  in w3c parlance than 'must not'. However, it is a moot point if we decide to follow the 'should' in 3.3 for the default 'strict' mode, which both Ezio and I think we 'should' ;-). Our 'errors' parameter makes it easy to request something else, but it has to be explicit.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 06:32:46 2011
From: report at bugs.python.org (Stephen Vavasis)
Date: Mon, 19 Sep 2011 04:32:46 +0000
Subject: [issue13006] bug in core python variable binding
Message-ID: <1316406766.78.0.388912606851.issue13006@psf.upfronthosting.co.za>


New submission from Stephen Vavasis :

There seems to be a serious bug in how python 2.7.2 binds variables to values.  In the attached function buildfunclist, you see that there is a variable called 'funclist' that is initialized to [], and then is modified only with 'append' calls.  This means that once append is called 46 times, one expects that funclist[45] is defined and will not change?  And yet funclist[45] changes several times as more data items are appended.  The same bug is present in 3.2.2.  My operating system is Windows 7 64-bit on a Lenovo Thinkpad T410.  I'm guessing that there is a problem with python's lazy copying-- it is a bit too lazy and failing to make copies when lists are changed.

To exhibit this bug, proceed as follows:

import pickle
h = open('combined_oplists_pickle','r')
combined_oplists = pickle.Unpickler(h).load()
import pybugreport
funclist,funcdist = pybugreport.buildfunclist(combined_oplists)

and then you will see funclist[45] printed out on two successive iterations.  It has changed as a result of an append operation, which should not happen.  (It's 6th entry is longer.)

Here is the output:

funclist[45] = [0, 22973, '$FUNC', 'splitBoxInterior', [['InArg', [[['', 'ActiveBoxVectorI', '::', 'iterator', ''], ['thisboxdata_p', '']], [['', 'FaceIndex', ''], ['faceind', '']]]], ['InOutArg', [[['', 'ActiveBoxVectorI', ''], ['interiorOrbitNextLev', '']]]], ['RefGlobal', [[['', 'MIndex', ''], ['guiActiveBoxCount', '']]]], ['Workspace', [[['', 'QMGVector', '<', '', 'BoxCreationData', '', '> ', ''], ['boxCreationVec', '']]]]], [], [[0, 23017], [0, 23048], [0, 23068], [0, 23069]], [[0, 23001]]]
funclist[45] = [0, 22973, '$FUNC', 'splitBoxInterior', [['InArg', [[['', 'ActiveBoxVectorI', '::', 'iterator', ''], ['thisboxdata_p', '']], [['', 'FaceIndex', ''], ['faceind', '']]]], ['InOutArg', [[['', 'ActiveBoxVectorI', ''], ['interiorOrbitNextLev', '']]]], ['RefGlobal', [[['', 'MIndex', ''], ['guiActiveBoxCount', '']]]], ['Workspace', [[['', 'QMGVector', '<', '', 'BoxCreationData', '', '> ', ''], ['boxCreationVec', '']]]]], [[0, 23115], [0, 23116], [0, 23117], [0, 23118], [0, 23119], [0, 23120], [0, 23121], [0, 23122], [0, 23123], [0, 23124], [0, 23125], [0, 23126], [0, 23127], [0, 23128], [0, 23129], [0, 23130], [0, 23131], [0, 23132], [0, 23133], [0, 23134], [0, 23135], [0, 23136], [0, 23139], [0, 23140], [0, 23141], [0, 23142], [0, 23143], [0, 23144], [0, 23145], [0, 23146]], [[0, 23017], [0, 23048], [0, 23068], [0, 23069], [0, 23137], [0, 23138], [0, 23147], [0, 23148], [0, 23149], [0, 23161]], [[0, 23001]]]

----------
components: Interpreter Core
files: pybugreport.zip
messages: 144261
nosy: vavasis
priority: normal
severity: normal
status: open
title: bug in core python variable binding
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23190/pybugreport.zip

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 08:24:22 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 19 Sep 2011 06:24:22 +0000
Subject: [issue13006] bug in core python variable binding
In-Reply-To: <1316406766.78.0.388912606851.issue13006@psf.upfronthosting.co.za>
Message-ID: <1316413462.19.0.541030796368.issue13006@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc  added the comment:

This is a bug in the script; the code is similar to the following::

  >>> funclist = []
  >>> global_list = []
  >>> funclist.append(global_list)
  >>> global_list.append(1)
  >>> funclist.append(global_list)
  >>> print funclist
  [[1], [1]]

i.e the same object is added twice to "funclist", any modification to the first item is a modification to the second. See also http://www.python.org/doc//current/faq/programming.html#how-do-i-create-a-multidimensional-list
In your script, it's certainly happens because there are multiple nested blocks ('{' '}') in the same function ('$FUNC'), so global_list is still the *same* list.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 08:32:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Sep 2011 06:32:07 +0000
Subject: [issue12517] Large file support on Windows: sizeof(off_t) is 32 bits
In-Reply-To: <1310079250.24.0.0290880980981.issue12517@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset dc16b6ab8e71 by Ross Lagerwall in branch 'default':
Issue #12517: Silence warning on windows buildbots (from 7fd80c61ddaa).
http://hg.python.org/cpython/rev/dc16b6ab8e71

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 11:22:42 2011
From: report at bugs.python.org (Steven Samuel Cole)
Date: Mon, 19 Sep 2011 09:22:42 +0000
Subject: [issue13004] pprint: add option to truncate sequences
In-Reply-To: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>
Message-ID: <1316424162.59.0.969344599065.issue13004@psf.upfronthosting.co.za>


Changes by Steven Samuel Cole :


----------
nosy: +ssc
title: pprint: add option to truncate seqeunces -> pprint: add option to truncate sequences

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 12:26:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Sep 2011 10:26:47 +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 a4e4facad164 by Nick Coghlan in branch 'default':
Close issue 12958 by flagging expected failures in test_socket on Mac OS X
http://hg.python.org/cpython/rev/a4e4facad164

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 12:31:28 2011
From: report at bugs.python.org (David Lam)
Date: Mon, 19 Sep 2011 10:31:28 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1316428288.33.0.675113027007.issue12537@psf.upfronthosting.co.za>


David Lam  added the comment:

This patch deletes the leftover special attributes. 

Thanks for guiding me through my confusion and/or cluelessness!

----------
keywords: +patch
Added file: http://bugs.python.org/file23191/12537.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 12:35:02 2011
From: report at bugs.python.org (David Lam)
Date: Mon, 19 Sep 2011 10:35:02 +0000
Subject: [issue12537] mailbox's _become_message is very fragile
In-Reply-To: <1310409075.46.0.992802544026.issue12537@psf.upfronthosting.co.za>
Message-ID: <1316428502.56.0.100284225987.issue12537@psf.upfronthosting.co.za>


Changes by David Lam :


Added file: http://bugs.python.org/file23192/12537.find.attribute.differences.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 13:11:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Sep 2011 11:11:48 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1316430708.68.0.615761602121.issue12729@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

We could also look at what other languages do and/or ask to the Unicode consortium [0].

[0]: http://www.unicode.org/consortium/distlist.html

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 14:49:09 2011
From: report at bugs.python.org (intgr)
Date: Mon, 19 Sep 2011 12:49:09 +0000
Subject: [issue11357] Add support for PEP 381 Mirror Authenticity
In-Reply-To: <1298948795.56.0.864012658533.issue11357@psf.upfronthosting.co.za>
Message-ID: <1316436549.94.0.615089949954.issue11357@psf.upfronthosting.co.za>


Changes by intgr :


----------
nosy: +intgr

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 15:14:47 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Sep 2011 13:14:47 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316438087.03.0.0652753464233.issue12961@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> Balls-in-boxes _is_ one of the most basic of the canonical combinatorial problems.

Agreed.  But in its basic form, this is covered by itertools.combinations, isn't it?  It may be worth a doc recipe showing how to use itertools.combinations for this (especially since the naive implementation---e.g., the one I posted on comp.lang.python, doesn't get boundary cases right).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 15:31:07 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 19 Sep 2011 13:31:07 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316439067.19.0.883356678293.issue12943@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Updated patch fixing some issues pointed out by Ezio on Rietveld.

----------
Added file: http://bugs.python.org/file23193/issue12943-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 15:33:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 13:33:17 +0000
Subject: =?utf-8?q?=5Bissue10946=5D_bdist_doesn=E2=80=99t_pass_--skip-build_on_to_?=
	=?utf-8?q?subcommands?=
In-Reply-To: <1295451169.68.0.9980803941.issue10946@psf.upfronthosting.co.za>
Message-ID: <1316439197.86.0.875717364224.issue10946@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Fixed in distutils2 in 95172b1c5498.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 15:34:02 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 13:34:02 +0000
Subject: [issue8933] Invalid detection of metadata version
In-Reply-To: <1275927761.19.0.897367518837.issue8933@psf.upfronthosting.co.za>
Message-ID: <1316439242.88.0.415012654943.issue8933@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Fixed in distutils2 in b9ca25b3254e.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 15:34:59 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 13:34:59 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1316439299.44.0.147905527906.issue9561@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I backported your last change to distutils2 as f5a74b1f9473.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 15:35:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 13:35:27 +0000
Subject: [issue12785] list_distinfo_file is wrong
In-Reply-To: <1313769411.65.0.340469000727.issue12785@psf.upfronthosting.co.za>
Message-ID: <1316439327.3.0.0756561165345.issue12785@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Backported to distutils2 as 5e49c9bc43eb.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 15:41:04 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 19 Sep 2011 13:41:04 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316439664.34.0.544715724.issue12961@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

And using combinations_with_replacement, it's even a one-liner:

>>> balls_in_boxes = lambda n, k: (tuple(map(c.count, range(k))) for c in combinations_with_replacement(range(k), n))
>>> for item in balls_in_boxes(5,3): print(item)
... 
(5, 0, 0)
(4, 1, 0)
(4, 0, 1)
(3, 2, 0)
(3, 1, 1)
(3, 0, 2)
(2, 3, 0)
(2, 2, 1)
(2, 1, 2)
(2, 0, 3)
(1, 4, 0)
(1, 3, 1)
(1, 2, 2)
(1, 1, 3)
(1, 0, 4)
(0, 5, 0)
(0, 4, 1)
(0, 3, 2)
(0, 2, 3)
(0, 1, 4)
(0, 0, 5)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 15:51:25 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 13:51:25 +0000
Subject: [issue12987] Demo/scripts/newslist.py has non-free licensing terms
In-Reply-To: <1316106376.14.0.821549088904.issue12987@psf.upfronthosting.co.za>
Message-ID: <1316440285.46.0.580218644037.issue12987@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I don?t see any problem with removing it from the 2.7 branch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:04:29 2011
From: report at bugs.python.org (Marc Sibson)
Date: Mon, 19 Sep 2011 14:04:29 +0000
Subject: [issue4256] argparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1316441069.72.0.307087248307.issue4256@psf.upfronthosting.co.za>


Changes by Marc Sibson :


----------
nosy: +marcs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:04:31 2011
From: report at bugs.python.org (Marc Sibson)
Date: Mon, 19 Sep 2011 14:04:31 +0000
Subject: [issue11176] give more meaningful argument names in argparse
	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1316441071.79.0.431391640779.issue11176@psf.upfronthosting.co.za>


Changes by Marc Sibson :


----------
nosy: +marcs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:04:50 2011
From: report at bugs.python.org (Marc Sibson)
Date: Mon, 19 Sep 2011 14:04:50 +0000
Subject: [issue12933] Update or remove claims that distutils requires external
	programs
In-Reply-To: <1315411614.16.0.0292960363033.issue12933@psf.upfronthosting.co.za>
Message-ID: <1316441090.16.0.610043527974.issue12933@psf.upfronthosting.co.za>


Changes by Marc Sibson :


----------
nosy: +marcs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:05:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 14:05:01 +0000
Subject: [issue11037] State of PEP 382 or How does distutils2 handle
	namespaces?
In-Reply-To: <1296210890.87.0.618097241127.issue11037@psf.upfronthosting.co.za>
Message-ID: <1316441101.68.0.401429161556.issue11037@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

As a question about a proposed PEP which is not accepted and has a competitor (see python-threads about PEP 402), this is not really a bug report.  Closing.

----------
assignee: tarek -> eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
title: State of PEP 382 or How does distutils2 handle	namespaces? -> State of PEP 382 or How does distutils2 handle namespaces?

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:10:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Sep 2011 14:10:51 +0000
Subject: [issue12314] regrtest checks (os.environ, sys.path,
	etc.) are hard to use
In-Reply-To: <1307722749.85.0.48203387339.issue12314@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 9c61f46ea6b4 by ?ric Araujo in branch 'default':
Make regrtest look at internal dicts in sysconfig.
http://hg.python.org/cpython/rev/9c61f46ea6b4

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:18:10 2011
From: report at bugs.python.org (Marien Zwart)
Date: Mon, 19 Sep 2011 14:18:10 +0000
Subject: [issue13007] gdbm 1.9 has new magic that whichdb does not recognize
Message-ID: <1316441889.97.0.558871663517.issue13007@psf.upfronthosting.co.za>


New submission from Marien Zwart :

dbm.whichdb (python 3) and whichdb.whichdb (python 2) only check for "magic == 0x13579ace" to recognize gdbm databases. The recently released gdbm 1.9 series adds 0x13579acd (for "32bit") and 0x13579acf (for "64bit") magics (see src/gdbmconst.h in the gdbm-1.9 or gdbm-1.9.1 source tree). Python's gdbm linked to gdbm 1.9 creates databases with the new magic, which causes the whichdb tests to fail. To reproduce this just build python against the new libgdbm and run test/test_dbm.py.

whichdb should probably just check for the two new magic numbers too. This will cause it to recognize the new gdbm databases even if python's gdbm extension is linked to an older version of gdbm that cannot open them, but that is probably less likely to cause problems than the current behavior, where a database created by python's gdbm is not recognized as such.

(I've left the "Versions" field untouched as I do not know which versions of python this should be backported to, but it affects all of them.)

----------
components: Library (Lib)
messages: 144277
nosy: marienz
priority: normal
severity: normal
status: open
title: gdbm 1.9 has new magic that whichdb does not recognize
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:21:24 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 19 Sep 2011 14:21:24 +0000
Subject: [issue13008] syntax error when pasting valid snippet into console
	without empty string after the function def
Message-ID: <1316442084.93.0.49113454288.issue13008@psf.upfronthosting.co.za>


New submission from anatoly techtonik :

This is self-explanative. Function definitions are identical. Syntax error caused by the absence of empty line after the function definition.

Python 2.7.1 (r271:86832, Apr 12 2011, 16:16:18) 
[GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os

>>> def get_size(start_path = '.'):
...     total_size = 0
...     for dirpath, dirnames, filenames in os.walk(start_path):
...         for f in filenames:
...             fp = os.path.join(dirpath, f)
...             total_size += os.path.getsize(fp)
...     return total_size
... 
>>> print get_size()
1595969238
>>> def get_size(start_path = '.'):
...     total_size = 0
...     for dirpath, dirnames, filenames in os.walk(start_path):
...         for f in filenames:
...             fp = os.path.join(dirpath, f)
...             total_size += os.path.getsize(fp)
...     return total_size
... print get_size()
  File "", line 8
    print get_size()
        ^
SyntaxError: invalid syntax

----------
messages: 144278
nosy: techtonik
priority: normal
severity: normal
status: open
title: syntax error when pasting valid snippet into console without empty string after the function def
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:23:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 14:23:07 +0000
Subject: [issue8591] update mkpkg to latest coding standards
In-Reply-To: <1272727331.63.0.427295643421.issue8591@psf.upfronthosting.co.za>
Message-ID: <1316442187.33.0.892818129989.issue8591@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> Changing ?if s in 'yn'? to ?if s in ('y', 'n')? is not really an
> improvement. It?s not more readable to always use tuples or frozensets
> for membership testing; str has __contains__ for a reason :)

Let me eat my words: using ?in 'yn'? matches '' and 'yn', which we don?t want.  Changed in 10fd0d0895a1.

----------
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:28:23 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 19 Sep 2011 14:28:23 +0000
Subject: [issue13007] gdbm 1.9 has new magic that whichdb does not recognize
In-Reply-To: <1316441889.97.0.558871663517.issue13007@psf.upfronthosting.co.za>
Message-ID: <1316442503.12.0.366099245345.issue13007@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
assignee:  -> jcea
nosy: +jcea
versions: +Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:29:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 14:29:23 +0000
Subject: [issue13008] syntax error when pasting valid snippet into console
	without empty string after the function def
In-Reply-To: <1316442084.93.0.49113454288.issue13008@psf.upfronthosting.co.za>
Message-ID: <1316442563.88.0.160037993122.issue13008@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

If you point out the reST files with examples that don?t work when copy-pasted, we can fix them.  Changing the behavior of the interpreter itself is probably not possible.

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:37:22 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 19 Sep 2011 14:37:22 +0000
Subject: [issue13007] gdbm 1.9 has new magic that whichdb does not recognize
In-Reply-To: <1316441889.97.0.558871663517.issue13007@psf.upfronthosting.co.za>
Message-ID: <1316443042.62.0.740755326986.issue13007@psf.upfronthosting.co.za>


Jes?s Cea Avi?n  added the comment:

I have a question... What about the endianness of the data?. For instance, if an Intel machine (little endian) creates a GDBM file, can it a) be recognized as such in Sparc (big endian)? b) Can be open and used in Sparc?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:42:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 14:42:10 +0000
Subject: [issue8891] shutil: sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1316443330.29.0.244189384183.issue8891@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
components: +Library (Lib) -Distutils2
stage: test needed -> needs patch
title: sort files before archiving for consistency -> shutil: sort files before archiving for consistency
versions: +Python 3.3 -3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:53:42 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 19 Sep 2011 14:53:42 +0000
Subject: [issue13008] syntax error when pasting valid snippet into console
	without empty string after the function def
In-Reply-To: <1316442084.93.0.49113454288.issue13008@psf.upfronthosting.co.za>
Message-ID: <1316444022.15.0.541572263318.issue13008@psf.upfronthosting.co.za>


anatoly techtonik  added the comment:

If changing behavior of console is not possible now, schedule it for python4.

http://stackoverflow.com/questions/1392413/calculating-a-directory-size-using-python/1392549#1392549

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 16:58:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 14:58:36 +0000
Subject: [issue11913] sdist refuses README.rst
In-Reply-To: <1303613322.81.0.629577121535.issue11913@psf.upfronthosting.co.za>
Message-ID: <1316444316.99.0.438615732994.issue11913@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> When I upload modules to PyPI, distutils is clucking about a missing
> README, even though PyPI accepts README.rst, and I am providing that.
PyPI doesn?t do anything with README, it displays the value of long_description.

> warning: sdist: standard file not found: should have one of README, README.txt
Is it a problem to name your reST file README.txt?


In packaging/distutils2, the recommended idiom looks like this (in setup.cfg):

    [metadata]
    description-file = README.whatever

sdist will include that file.  You can also write the description in the setup.cfg directly and have your README file included with the extra_files field.


This can?t be changed in distutils and works differently without warning in distutils2; closing.

----------
assignee: tarek -> eric.araujo
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:00:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 15:00:07 +0000
Subject: [issue12145] distutils2 should support README.rst
In-Reply-To: <1306033855.22.0.0348885298579.issue12145@psf.upfronthosting.co.za>
Message-ID: <1316444407.56.0.868625864261.issue12145@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Closing as duplicate.

----------
assignee: tarek -> eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> sdist refuses README.rst

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:04:56 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 19 Sep 2011 15:04:56 +0000
Subject: [issue13007] gdbm 1.9 has new magic that whichdb does not recognize
In-Reply-To: <1316441889.97.0.558871663517.issue13007@psf.upfronthosting.co.za>
Message-ID: <1316444696.22.0.0533510372217.issue13007@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis :


----------
nosy: +Arfrever

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:08:13 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 15:08:13 +0000
Subject: [issue13009] Remove documentation in distutils2 repo
Message-ID: <1316444893.0.0.327846688186.issue13009@psf.upfronthosting.co.za>


New submission from ?ric Araujo :

The docs for packaging now live at docs.python.org.  Maintaining separate documentation for the distutils2 backport would take much time for little benefit.  Tarek agreed that we could just delete them, so I will remove them, add a file to mention their new location and update the PyPI and packages.python.org pages.  I?m opening this report to let people know, I don?t need a patch.

----------
assignee: eric.araujo
components: Distutils2
messages: 144285
nosy: alexis, eric.araujo
priority: normal
severity: normal
status: open
title: Remove documentation in distutils2 repo
versions: 3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:08:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 15:08:33 +0000
Subject: [issue13009] Remove documentation in distutils2 repo
In-Reply-To: <1316444893.0.0.327846688186.issue13009@psf.upfronthosting.co.za>
Message-ID: <1316444913.8.0.384009748257.issue13009@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

(Replying to myself to avoid this showing up in the weekly report as unanswered)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:12:28 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 19 Sep 2011 15:12:28 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1316430708.68.0.615761602121.issue12729@psf.upfronthosting.co.za>
Message-ID: <8549.1316445140@chthon>


Tom Christiansen  added the comment:

Ezio Melotti  wrote
   on Mon, 19 Sep 2011 11:11:48 -0000: 

> We could also look at what other languages do and/or ask to the
> Unicode consortium.

I will look at what Java does a bit later on this morning, which is the
only other commonly used language besides C that I feel even reasonably
competent at.  I seem to recall that Java changed its default behavior on
certain Unicode decoding issues from warnings to exceptions between one
release and the next, but can't remember any details.

As the Perl Foundation is a member of the Unicode Consortium and I am on
the mailing list, I suppose I could just ask them.  I feel a bit timid
though because the last thing I brought up there was based on a subtle
misunderstanding of mine regarding the IDC and Pattern_Syntax properties.
I hate looking dumb twice in row. :)

--tom

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:13:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Sep 2011 15:13:32 +0000
Subject: [issue13007] gdbm 1.9 has new magic that whichdb does not recognize
In-Reply-To: <1316441889.97.0.558871663517.issue13007@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 14cafb8d1480 by Jesus Cea in branch '2.7':
Close #13007: whichdb should recognize gdbm 1.9 magic numbers
http://hg.python.org/cpython/rev/14cafb8d1480

New changeset 7a41855b6196 by Jesus Cea in branch '3.2':
Close #13007: whichdb should recognize gdbm 1.9 magic numbers
http://hg.python.org/cpython/rev/7a41855b6196

New changeset b194af345cb5 by Jesus Cea in branch 'default':
Close #13007: whichdb should recognize gdbm 1.9 magic numbers
http://hg.python.org/cpython/rev/b194af345cb5

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:28:35 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 19 Sep 2011 15:28:35 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due
	to	narrow/wide bug
In-Reply-To: <12256.1316385915@chthon>
Message-ID: <4E775F94.7010901@egenix.com>


Marc-Andre Lemburg  added the comment:

Tom Christiansen wrote:
> 
> I'm pretty sure that anything that claims to be UTF-{8,16,32} needs  
> to reject both surrogates *and* noncharacters. Here's something from the
> published Unicode Standard's p.24 about noncharacter code points:
> 
>     ? Noncharacter code points are reserved for internal use, such as for 
>       sentinel values. They should never be interchanged. They do, however,
>       have well-formed representations in Unicode encoding forms and survive
>       conversions between encoding forms. This allows sentinel values to be
>       preserved internally across Unicode encoding forms, even though they are
>       not designed to be used in open interchange.
> 
> And here from the Unicode Standard's chapter on Conformance, section 3.2, p. 59:
> 
>     C2 A process shall not interpret a noncharacter code point as an 
>        abstract character.
> 
>         ? The noncharacter code points may be used internally, such as for 
>           sentinel values or delimiters, but should not be exchanged publicly.

You have to remember that Python is used to build applications. It's
up to the applications to conform to Unicode or not and the
application also defines what "exchange" means in the above context.

Python itself needs to be able to deal with assigned non-character
code points as well as unassigned code points or code points that
are part of special ranges such as the surrogate ranges.

I'm +1 on not allowing e.g. lone surrogates in UTF-8 data, because
we have a way to optionally allow these via an error handler,
but -1 on making changes that cause full range round-trip safety
of the UTF encodings to be lost without a way to turn the functionality
back on.

----------
title: Python lib re cannot handle Unicode properly due to narrow/wide bug -> Python lib re cannot handle Unicode properly due to	narrow/wide bug

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:38:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Sep 2011 15:38:19 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 07efe83795b0 by Mark Dickinson in branch '2.7':
Issue #12973: Fix int.__pow__ overflow checks that invoked undefined behaviour, thereby producing incorrect results on Clang.
http://hg.python.org/cpython/rev/07efe83795b0

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:44:15 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 15:44:15 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1316447055.93.0.0344427253452.issue12930@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Follow the ?review? link for some comments.

Do you have a test file that I could use to reproduce the bug and make sure it?s fixed?

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:55:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 15:55:35 +0000
Subject: [issue12585] distutils dereferences symlinks for zip but not for
	bztar/gztar target
In-Reply-To: <1311084837.3.0.496870465183.issue12585@psf.upfronthosting.co.za>
Message-ID: <1316447735.66.0.945124078808.issue12585@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

>> So, do you think adding a warning about symlink
>> handling issues in the docs would be enough?
> Given the constraints, yes, it would be good to have that warning in
> the docs.

Okay.  Adding the easy keyword to lure contributors.

> Even better would be a runtime hint like

I?m not a fan of the idea.  You have to keep warnings few if you want people to heed them.

>> For distutils2 however, compatibility concerns do not apply yet,
>> so we?re free to fix and document symlink handling.

Thinking again about that, I wonder if there is something to fix at all; tar is a smart container format whereas zip is simpler, so I would not be surprised if the 
source of the difference is just that zip cannot contain links.

----------
components: +Documentation
keywords: +easy
versions: +3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:58:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 15:58:24 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1316447904.61.0.94877870389.issue12344@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

I?d like to commit this; do you need help to address the review I did, or do you want me to take over if you don?t have the time?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 17:59:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 15:59:55 +0000
Subject: [issue793069] Add --remove-source option
Message-ID: <1316447995.97.0.0946464697153.issue793069@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
assignee: tarek -> eric.araujo
resolution: accepted -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 18:09:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 16:09:16 +0000
Subject: [issue12395] packaging remove fails under Windows
In-Reply-To: <1308915670.23.0.449812169984.issue12395@psf.upfronthosting.co.za>
Message-ID: <1316448556.28.0.362461855695.issue12395@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

If I?m not mistaken, 2b9a0a091566 fixed this.

----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> packaging: fix database to stop skipping uninstall tests on win32

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 18:15:15 2011
From: report at bugs.python.org (Florian Berger)
Date: Mon, 19 Sep 2011 16:15:15 +0000
Subject: [issue12585] distutils dereferences symlinks for zip but not for
	bztar/gztar target
In-Reply-To: <1311084837.3.0.496870465183.issue12585@psf.upfronthosting.co.za>
Message-ID: <1316448915.36.0.926530328531.issue12585@psf.upfronthosting.co.za>


Florian Berger  added the comment:

> Okay.  Adding the easy keyword to lure contributors.

Thanks.

> I wonder if there is something to fix at all; tar is a smart container
> format whereas zip is simpler, so I would not be surprised if the
> source of the difference is just that zip cannot contain links.

In my mind, that is no excuse for inconsistent behaviour on part of the wrapper. If the *user* (i.e. package creator) had any choice of storing symlinks "as is" or the file linked, I would agree; but there is no option, no parameter, in fact not even a hint at the behaviour. On the contrary, the *wrapper* (i.e. distutils) does have a choice of derefering symlinks in a tar file or not.

So, from my point of view: surprises == bad, options/parameters == good, transparent consitency == best.

P.S. "Explicit is better than implicit" may also apply here. ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 18:16:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 19 Sep 2011 16:16:34 +0000
Subject: [issue12393] Packaging should provide support for extensible
	categories
In-Reply-To: <1308905605.65.0.75321405353.issue12393@psf.upfronthosting.co.za>
Message-ID: <1316448994.69.0.339436428206.issue12393@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> Basic support for categories now added to install_data:
Can you add tests?

> I couldn't see a packaging.util function for matching lines of type
> "key = value",
If there are many places that could benefit from such a function, we can add it.

----------
assignee: tarek -> eric.araujo
versions: +3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 18:20:32 2011
From: report at bugs.python.org (Thomas Holmes)
Date: Mon, 19 Sep 2011 16:20:32 +0000
Subject: [issue12344] Add **kwargs to get_reinitialized_command
In-Reply-To: <1308190105.67.0.431736719114.issue12344@psf.upfronthosting.co.za>
Message-ID: <1316449232.04.0.431827635416.issue12344@psf.upfronthosting.co.za>


Thomas Holmes  added the comment:

I got a bit distracted and I think had some questions on the review. I will go back over the state of this patch and get some feedback to you tonight or tomorrow evening.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 18:38:18 2011
From: report at bugs.python.org (Steven Samuel Cole)
Date: Mon, 19 Sep 2011 16:38:18 +0000
Subject: [issue13010] devguide doc: ./python.exe on OS X
Message-ID: <1316450298.9.0.0678816170988.issue13010@psf.upfronthosting.co.za>


New submission from Steven Samuel Cole :

it says in the last paragraph of the chapter at http://docs.python.org/devguide/setup.html#unix:

[...] ./python.exe on OS X [...]

.exe seems to indicate that should probably be './python.exe on Windows'

----------
assignee: docs at python
components: Documentation
messages: 144298
nosy: docs at python, ssc
priority: normal
severity: normal
status: open
title: devguide doc: ./python.exe on OS X

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 18:40:06 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Sep 2011 16:40:06 +0000
Subject: [issue13010] devguide doc: ./python.exe on OS X
In-Reply-To: <1316450298.9.0.0678816170988.issue13010@psf.upfronthosting.co.za>
Message-ID: <1316450406.79.0.996064803561.issue13010@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

I believe it's ./python.exe on OS X.  I'm not sure about Windows, maybe it's just python.exe there.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 18:44:22 2011
From: report at bugs.python.org (Steven Samuel Cole)
Date: Mon, 19 Sep 2011 16:44:22 +0000
Subject: [issue13010] devguide doc: ./python.exe on OS X
In-Reply-To: <1316450298.9.0.0678816170988.issue13010@psf.upfronthosting.co.za>
Message-ID: <1316450662.78.0.663027085403.issue13010@psf.upfronthosting.co.za>


Steven Samuel Cole  added the comment:

i've gone through the process of checking out and building python as described in the devguide; it seems the python executable is indeed called python.exe under mac osx. i find this confusing.

a comment on the reason for this unusual suffix would be great, but an added "(sic!)" would already indicate this is not an erroneous mixup of OS names (as i initially assumed).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 18:44:57 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Sep 2011 16:44:57 +0000
Subject: [issue13010] devguide doc: ./python.exe on OS X
In-Reply-To: <1316450298.9.0.0678816170988.issue13010@psf.upfronthosting.co.za>
Message-ID: <1316450697.56.0.803934385359.issue13010@psf.upfronthosting.co.za>


R. David Murray  added the comment:

It is python.exe on OS/X, which I've always found most odd.  The reason is that the OS/X filesystem is case insensitive by default, and there is a directory named 'Python'.

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 19:37:13 2011
From: report at bugs.python.org (Steven Samuel Cole)
Date: Mon, 19 Sep 2011 17:37:13 +0000
Subject: [issue13010] devguide doc: ./python.exe on OS X
In-Reply-To: <1316450298.9.0.0678816170988.issue13010@psf.upfronthosting.co.za>
Message-ID: <1316453833.43.0.828185550098.issue13010@psf.upfronthosting.co.za>


Steven Samuel Cole  added the comment:

from my observations, david is correct, but this is not limited to os x. i have checked out and rebuilt python twice on a linux system (kubuntu 10.10 i386 virtual machine):

1. in a 'conventional' setup using a local (i.e. guest) harddrive formatted with a case-sensitive file system such as ext4, the built executable is called 'python' as one would expect.

2. in my setup mounting the source code folder from a cifs/samba share provided by the host, the executable is called 'python.exe': samba is not case sensitive.

once you know about case sensitivity and python / Python, the sentence in the docs makes absolute sense. before that, it looks like someone has mixed up os names.

suggestion for a rephrase: instead of

"Once CPython is done building you will then have a working build that can be run in-place; ./python on most machines (and what is used in all examples), ./python.exe on OS X (when on a case-insensitive filesystem, which is the default)."

"Once CPython is done building you will then have a working build that can be run in-place; ./python on most machines (and what is used in all examples), ./python.exe wherever a case-insensitive filesystem is used (e.g. the OS X default setting)."

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 19:45:30 2011
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Mon, 19 Sep 2011 17:45:30 +0000
Subject: [issue12944] setup.py upload to pypi needs to work with specified
	files
In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>
Message-ID: <1316454330.9.0.161988132681.issue12944@psf.upfronthosting.co.za>


Glyph Lefkowitz  added the comment:

This has been a serious annoyance in the Twisted and pyOpenSSL release processes; it effectively prevents us from timely uploads of win32 binaries of any kind.

----------
nosy: +glyph

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 19:45:53 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 19 Sep 2011 17:45:53 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
	Windows
In-Reply-To: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>
Message-ID: <1316454353.97.0.87264612658.issue12989@psf.upfronthosting.co.za>


Guido van Rossum  added the comment:

I'm not Barry or Benjamin, but having followed the thread on psrt at python.org, this certainly looks like a security issue to me. As a second pair of eyes, I recommend MvL, who builds our Windows installers.

----------
nosy: +gvanrossum, loewis

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 19:50:37 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 19 Sep 2011 17:50:37 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
	Windows
In-Reply-To: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>
Message-ID: <1316454637.05.0.552540095504.issue12989@psf.upfronthosting.co.za>


Benjamin Peterson  added the comment:

Approved for 3.1 as far as I'm concerned.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 20:20:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Sep 2011 18:20:37 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 99b808c94834 by Mark Dickinson in branch '3.2':
Issue #12973: Fix undefined-behaviour-inducing overflow check in list_repeat.
http://hg.python.org/cpython/rev/99b808c94834

New changeset 2dbd5870de0b by Mark Dickinson in branch 'default':
Merge issue #12973 list_repeat fix.
http://hg.python.org/cpython/rev/2dbd5870de0b

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 20:22:07 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 19 Sep 2011 18:22:07 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <4E775F94.7010901@egenix.com>
Message-ID: <6574.1316456511@chthon>


Tom Christiansen  added the comment:

No good news on the Java front.  They do all kinds of things wrong.  
For example, they allow intermixed CESU-8 and UTF-8 in a real UTF-8 
input stream, which is illegal.  There's more they do wrong, including 
in their documentation, but I won't bore you with their errors.

I'm going to seek clarification on some matters here.

--tom

----------
title: Python lib re cannot handle Unicode properly due to	narrow/wide bug -> Python lib re cannot handle Unicode properly due to narrow/wide bug

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 20:24:39 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Sep 2011 18:24:39 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset f8280cf63d9e by Mark Dickinson in branch '2.7':
Backport issue #12973 list_repeat fix from 3.x.
http://hg.python.org/cpython/rev/f8280cf63d9e

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 21:30:18 2011
From: report at bugs.python.org (David Watson)
Date: Mon, 19 Sep 2011 19:30:18 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316380300.83.0.142812104939.issue12981@psf.upfronthosting.co.za>
Message-ID: <20110919193016.GA5038@dbwatson.ukfsn.org>


David Watson  added the comment:

On Sun 18 Sep 2011, Charles-Fran?ois Natali wrote:
> > I had a look at this patch, and the FD passing looked OK, except
> > that calculating the buffer size with CMSG_SPACE() may allow more
> > than one file descriptor to be received, with the extra one going
> > unnoticed - it should use CMSG_LEN() instead
> 
> > (the existing C implementation has the same problem, I see).
> 
> I just checked, and the C version uses CMSG_SPACE() as the buffer size, but passes CMSG_LEN() to cmsg->cmsg_len and msg.msg_controllen. Or am I missing something?

Ah, no, you're right - that's fine.  Sorry for the false alarm.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 22:08:24 2011
From: report at bugs.python.org (Benny Siegert)
Date: Mon, 19 Sep 2011 20:08:24 +0000
Subject: [issue12976] add support for MirBSD platform
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316462904.03.0.187064200902.issue12976@psf.upfronthosting.co.za>


Benny Siegert  added the comment:

Hmm, I thought I was making an argument _for_ applying the patch. As I see it, these are benefits of merging the patch:

1. Being able to compile an unmodified upstream Python on MirBSD.
2. The patches in pkgsrc become smaller.
3. Future Python versions contain the support out of the box.

The only downside is having to add a few lines to configure and selectmodule.c ...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 22:32:59 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 19 Sep 2011 20:32:59 +0000
Subject: [issue13004] pprint: add option to truncate sequences
In-Reply-To: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>
Message-ID: <1316464379.91.0.0235587182868.issue13004@psf.upfronthosting.co.za>


Changes by Santoso Wijaya :


----------
nosy: +santa4nt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 19 23:36:55 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Sep 2011 21:36:55 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
	Windows
In-Reply-To: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>
Message-ID: <1316468215.53.0.21764125906.issue12989@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Brian, you marked this 'patch review', bypassing 'test needed'. Should this have any visible effect at the Python level that can be tested?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 00:41:38 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Mon, 19 Sep 2011 22:41:38 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1316430708.68.0.615761602121.issue12729@psf.upfronthosting.co.za>
Message-ID: <26725.1316472090@chthon>


Tom Christiansen  added the comment:

It appears that I'm right about surrogates, but wrong about
noncharacters.  I'm seeking a clarification there.

--tom

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 01:02:02 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Mon, 19 Sep 2011 23:02:02 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1316473322.98.0.770000683454.issue12930@psf.upfronthosting.co.za>


Changes by Caio Rom?o :


Removed file: http://bugs.python.org/file23146/caioromao-fix-12930-v3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 01:03:57 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Mon, 19 Sep 2011 23:03:57 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1316473437.66.0.456782803293.issue12930@psf.upfronthosting.co.za>


Caio Rom?o  added the comment:

New patch version ack-ing ?ric's suggestion.

Note: I'm now confused as to whether I should add my name to the ACKS file or not, heh. This patch doesn't include the change.

----------
Added file: http://bugs.python.org/file23194/caioromao-fix-12930-v4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 01:17:16 2011
From: report at bugs.python.org (=?utf-8?q?Caio_Rom=C3=A3o?=)
Date: Mon, 19 Sep 2011 23:17:16 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1316474236.15.0.600522529024.issue12930@psf.upfronthosting.co.za>


Caio Rom?o  added the comment:

Attaching files for testing in a gzipped tarball:

 - testfile-original.py: file to be reindented with reindent.py
 - testfile-issue.py: resulting file after using the current Tools/scripts/reindent.py
 - testfile-expected.py: expected output file; the result after applying the patch in this thread

----------
Added file: http://bugs.python.org/file23195/bug12930-testfiles.tgz

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 03:44:51 2011
From: report at bugs.python.org (Malcolm Purvis)
Date: Tue, 20 Sep 2011 01:44:51 +0000
Subject: [issue13011] Frozen programs require the original build directory in
	order to run.
Message-ID: <1316483091.36.0.96391936283.issue13011@psf.upfronthosting.co.za>


New submission from Malcolm Purvis :

In Python 2.7.2, Linux executables built with freeze.py will only run on the machine that contains the original build directory.  This defeats the purpose of having frozen programs.  This problem did not exist in Python 2.5.

The following steps reproduce the problem:

1) Build a copy of python:

$ tar -xf Python-2.7.2.tar.bz2
$ cd Python-2.7.2
$ ./configure --prefix=`pwd`/install
$ make
$ make install

2) In another directory, build a frozen program:

$ echo 'print "Hello World"' >hello.py
$ ~/src/Python-2.7.2/python ~/src/Python-2.7.2/Tools/freeze/freeze.py hello.py
$ make
$  ./hello 
Hello World

Copy the binary to another machine:

$ $ ./hello 
Traceback (most recent call last):
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 563, in 
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 545, in main
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 278, in addusersitepackages
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 253, in getusersitepackages
  File "/home/malcolmp/src/Python-2.7.2/Lib/site.py", line 243, in getuserbase
  File "/home/malcolmp/src/Python-2.7.2/Lib/sysconfig.py", line 520, in get_config_var
  File "/home/malcolmp/src/Python-2.7.2/Lib/sysconfig.py", line 419, in get_config_vars
  File "/home/malcolmp/src/Python-2.7.2/Lib/sysconfig.py", line 287, in _init_posix
IOError: invalid Python installation: unable to open /home/malcolmp/src/Python-2.7.2/install/lib/python2.7/config/Makefile (No such file or directory)

----------
components: Demos and Tools
messages: 144315
nosy: malcolmp
priority: normal
severity: normal
status: open
title: Frozen programs require the original build directory in order to run.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 05:17:46 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Sep 2011 03:17:46 +0000
Subject: [issue13004] pprint: add option to truncate sequences
In-Reply-To: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>
Message-ID: <1316488666.96.0.393245480102.issue13004@psf.upfronthosting.co.za>


Raymond Hettinger  added the comment:

This needs to be part of the overall effort to build a better pprint.  See http://bugs.python.org/issue7434

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 05:34:02 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 20 Sep 2011 03:34:02 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316489642.57.0.216812368121.issue12943@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Updated patch which adds and documents a '-h,--help' option.  This option
was suggested during code review.

----------
Added file: http://bugs.python.org/file23196/issue12943-4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 05:35:50 2011
From: report at bugs.python.org (Santoso Wijaya)
Date: Tue, 20 Sep 2011 03:35:50 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1316489750.37.0.287848246981.issue7434@psf.upfronthosting.co.za>


Changes by Santoso Wijaya :


----------
nosy: +santa4nt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 06:32:36 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 20 Sep 2011 04:32:36 +0000
Subject: [issue12976] add support for MirBSD platform
In-Reply-To: <1316001439.23.0.212484245122.issue12976@psf.upfronthosting.co.za>
Message-ID: <1316493156.82.0.822580438695.issue12976@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

You said "I can maintain the patch for future releases". This sounds like a reasonable solution: you keep maintaining the patch; if you want python.org to link to your patch, we can certainly arrange that. By the "no minority platforms" policy, MirBSD is just too small to be officially supported.

Technically, I recommend to maintain the patch in a Mercurial clone, perhaps hosted on bitbucket. Then you do a merge every time python.org makes a release, and everybody can fetch the code base at any point easily.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 07:43:22 2011
From: report at bugs.python.org (anand jeyahar)
Date: Tue, 20 Sep 2011 05:43:22 +0000
Subject: [issue13004] pprint: add option to truncate sequences
In-Reply-To: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>
Message-ID: <1316497402.13.0.704365577278.issue13004@psf.upfronthosting.co.za>


anand jeyahar  added the comment:

Umm... Excuse me but how is this max_length parameter different from the (existing)depth parameter? 
pformat(object,depth=3) seems to do the same thing.

----------
nosy: +anandjeyahar

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 09:32:39 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Tue, 20 Sep 2011 07:32:39 +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: <1316503959.58.0.566150309513.issue12991@psf.upfronthosting.co.za>


Wong Wah Meng  added the comment:

I think there is something that is not working here at least for the instructions in build README file about setting up 4 environment variables required for HP Itanium 64-bit build using HP compilers. 
                CC=cc
                CXX=aCC
                BASECFLAGS="+DD64"
                LDFLAGS="+DD64 -lxnet"
When above 4 environment variables are set, the configure script will pick them up and build the Makefile that passes in LDFLAGS into the linker. The linker doesn't seem to recognize +DD64 on HP-UX. 

ld -b +DD64 -lxnet build/temp.hp-ux-B.11.31-ia64-2.7/home/r32813/Build/2.7.1/Python-2.7.1/Modules/mathmodule.o build/temp.hp-ux-B.11.31-ia64-2.7/home/r32813/Build/2.7.1/Python-2.7.1/Modules/_math.o -L/usr/local/lib -lm -o build/lib.hp-ux-B.11.31-ia64-2.7/math.so
ld: Unrecognized argument: +DD64
Fatal error.

I did a workaround by only setting "CC=cc +DD64" and "CXX=aCC" and did not set the other 2 environment variables, and able to build python 64-bit without the failed modules that were due to invalid flag passed into the linker. So I am re-opening the issue here to see if this is something we can amend in the instruction of README file for HP 64-bit build using HP Compiler.

----------
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 09:51:05 2011
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 20 Sep 2011 07:51:05 +0000
Subject: [issue12930] reindent.py inserts spaces in multiline literals
In-Reply-To: <1315405777.71.0.767109553281.issue12930@psf.upfronthosting.co.za>
Message-ID: <1316505065.65.0.0761861738195.issue12930@psf.upfronthosting.co.za>


Dima Tisnek  added the comment:

Thanks Caio, your test case covers my issue; seeing these spelt out got me thinking, there are perhaps 3~4 different cases:

def f0():
  s = """select
some sql
from
somewhere;
-- cannot be reindented"""

def f1():
  """ Multiline 
  text docstring
  should be reindented """

def f2():
  """ should example be reindented inside docstring?
  if f2():
    print "great"
  """

def f3():
  """ # should doctest be reindented inside docstring?
  >>> if f3():
  ...   print "yes"
  ... else:
  ...   print "no"
  ...
  no
  """

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 10:33:57 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Sep 2011 08:33:57 +0000
Subject: [issue13004] pprint: add option to truncate sequences
In-Reply-To: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>
Message-ID: <1316507637.96.0.997366767448.issue13004@psf.upfronthosting.co.za>


Changes by Nick Coghlan :


----------
dependencies: +general pprint rewrite

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 10:40:04 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Sep 2011 08:40:04 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316508004.97.0.140474589345.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan :


Removed file: http://bugs.python.org/file22616/pep380-missing-docs.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 11:26:49 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Sep 2011 09:26:49 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1316510809.47.0.390756315491.issue11816@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

Attached patch should now be complete, including the documentation for the new keyword-only 'file' parameter on various dis module functions.

----------
Added file: http://bugs.python.org/file23197/issue11816_get_opinfo_branch_20110920.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 12:21:04 2011
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 20 Sep 2011 10:21:04 +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: <1316514064.59.0.831298544458.issue12991@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

The README looks outdated. This isn't surprising, since probably no one
here has access to the HP compiler.

If you want to improve it, please try this:

make distclean
./configure CC=cc CFLAGS="+DD64"
make test



I don't think the linker should be invoked as 'ld'. Several sites
suggest that the HP compiler can be used a the linker front end
(in the same manner as gcc).

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/ad/r0007656.htm

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 12:27:18 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Sep 2011 10:27:18 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316514438.19.0.920806936908.issue11682@psf.upfronthosting.co.za>


Changes by Nick Coghlan :


Added file: http://bugs.python.org/file22616/pep380-missing-docs.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 12:32:01 2011
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Tue, 20 Sep 2011 10:32:01 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1316514721.53.0.123954984663.issue5178@psf.upfronthosting.co.za>


Changes by Ugra D?niel :


----------
nosy: +daniel.ugra

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 12:44:34 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Tue, 20 Sep 2011 10:44:34 +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: <1316515474.52.0.699890277513.issue12991@psf.upfronthosting.co.za>


Wong Wah Meng  added the comment:

Thanks! I am gonna try this out again. 

Actually I noticed this when you mentioned about using cc as the linker front end. 

I followed instruction in the README file, after I edited Makefile to remove the -O Limit 1500 line, and after python executable is built, the Makefile is overwritten (maybe re-generated by the compiler) again and my changes of -O and -Limit 1500 is added back. However that doesn't create big damage like the +DD64 to the linker (ld). 

I see. Since I have got HP Compiler, I will provide some updates here once I have a newer finding. I have submitted my question of "Why ld doesn't recognize +DD64" flag to HP and they are checking for me. The progress over there is slow. 

Thanks for your reply!

Regards,
Wah Meng

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 14:29:30 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 20 Sep 2011 12:29:30 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316521770.85.0.386296695265.issue11682@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

I have updated the bitbucket repo with changes to address most of Benjamin's review comments.

A few points of note:
- I agree in principle with the idea of splitting Yield and YieldFrom into distinct AST nodes, but I'd prefer to focus on getting the current implementation into the main repo first
- in cleaning up the handling of missing send/close/throw attributes on subiterators I discovered that the PyObject_CallMethod* APIs were discarding exception information and coercing everything to a terse AttributeError. The branch now changes them to allow the error reported by the underlying call to PyObject_GetAttr to pass through unmodified.
- the generator close() method treats an AttributeError as expected when looking for a close() method on the subiterator, but uses WriteUnraisable to deal with anything else.
- I share Benjamin's suspicion that some of the INCREF/DECREF pairs in genobject.c aren't actually necessary, but I don't think it's worth messing with them at this stage.

I haven't looked at Zbyszek's proposed doc changes at this point - the pull request has a lot of irrelevant line wrapping changes in it, so it makes it hard to review.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 15:44:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Sep 2011 13:44:07 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
Message-ID: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>


New submission from Mark Dickinson :

The docstring of str.splitlines says:

splitlines(...)
    S.splitlines([keepends]) -> list of strings
    
    Return a list of the lines in S, breaking at line boundaries.
    Line breaks are not included in the resulting list unless keepends
    is given and true.

Currently the optional argument can only be specified positionally.  What do people think about also allowing this argument to be specified by keyword?  (And applying the same change to bytes.splitlines.)

The main motivation here is readability:  in

   long_string.splitlines(keepends=True)

it's fairly clear what the boolean argument is doing.  But in

   long_string.splitlines(True)

it's much less clear.  (This came up during a Python training class that I was running recently.)  I'm not advocating making the argument keyword-only;  just allowing those who want to specify it by keyword to do so.

There are many other str methods that don't accept keyword arguments, but it's only this one where I think readability would really benefit.

----------
components: Interpreter Core
messages: 144326
nosy: mark.dickinson
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow keyword argument in str.splitlines()
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 15:50:41 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Sep 2011 13:50:41 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316526641.04.0.4469896387.issue13012@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> (And applying the same change to bytes.splitlines.)

Oh, and bytearray.splitlines, too.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 15:51:47 2011
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 20 Sep 2011 13:51:47 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316526707.34.0.912986408779.issue13012@psf.upfronthosting.co.za>


Alex Gaynor  added the comment:

Personally, I regard every C function which, for obscure internal details, doesn't take keyword arguments as a sad bug, which should of course be fixed :)

----------
nosy: +alex

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 15:57:03 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 20 Sep 2011 13:57:03 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316527023.77.0.497348439443.issue13012@psf.upfronthosting.co.za>


Meador Inge  added the comment:

+1; the keyword arg version is much more readable.

----------
nosy: +meador.inge

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 15:58:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Sep 2011 13:58:21 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316527101.47.0.438852892542.issue13012@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:02:44 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 20 Sep 2011 14:02:44 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1316527364.09.0.487745603555.issue11816@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:08:20 2011
From: report at bugs.python.org (Meador Inge)
Date: Tue, 20 Sep 2011 14:08:20 +0000
Subject: [issue13008] syntax error when pasting valid snippet into console
	without empty string after the function def
In-Reply-To: <1316442084.93.0.49113454288.issue13008@psf.upfronthosting.co.za>
Message-ID: <1316527700.43.0.691296901921.issue13008@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
nosy: +meador.inge

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:48:11 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:48:11 +0000
Subject: [issue13013] Resource is not released before returning from the
	functiion
Message-ID: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>


New submission from Suman Saha :

Something that is allocated using PyTuple_Pack is not freed on one error path.

----------
files: python_patch1
messages: 144330
nosy: Suman.Saha
priority: normal
severity: normal
status: open
title: Resource is not released before returning from the functiion
type: resource usage
Added file: http://bugs.python.org/file23198/python_patch1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:51:15 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:51:15 +0000
Subject: [issue13014] Resource is not released before returning from the
	functiion
Message-ID: <1316530275.76.0.31607583855.issue13014@psf.upfronthosting.co.za>


New submission from Suman Saha :

Something that is allocated using PyList_New is not freed on one error path.

----------
files: python_patch2
messages: 144331
nosy: Suman.Saha
priority: normal
severity: normal
status: open
title: Resource is not released before returning from the functiion
type: resource usage
Added file: http://bugs.python.org/file23199/python_patch2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:53:26 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:53:26 +0000
Subject: [issue13015] Resource is not released before returning from the
	functiion
Message-ID: <1316530406.22.0.00922720094034.issue13015@psf.upfronthosting.co.za>


New submission from Suman Saha :

Something that is allocated using PyDict_Type.tp_repr is not freed on one error path.

----------
files: python_patch3
messages: 144332
nosy: Suman.Saha
priority: normal
severity: normal
status: open
title: Resource is not released before returning from the functiion
type: resource usage
Added file: http://bugs.python.org/file23200/python_patch3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:54:34 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:54:34 +0000
Subject: [issue13016] Resource is not released before returning from the
	functiion
Message-ID: <1316530474.09.0.885561459136.issue13016@psf.upfronthosting.co.za>


New submission from Suman Saha :

Something that is allocated using PySequence_Fast is not freed on one error path.

----------
files: python_patch4
messages: 144333
nosy: Suman.Saha
priority: normal
severity: normal
status: open
title: Resource is not released before returning from the functiion
type: resource usage
Added file: http://bugs.python.org/file23201/python_patch4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:55:21 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:55:21 +0000
Subject: [issue13017] Resource is not released before returning from the
	functiion
Message-ID: <1316530520.98.0.265221985232.issue13017@psf.upfronthosting.co.za>


New submission from Suman Saha :

Something that is allocated using conv_content_model is not freed on one error path.

----------
files: python_patch5
messages: 144334
nosy: Suman.Saha
priority: normal
severity: normal
status: open
title: Resource is not released before returning from the functiion
type: resource usage
Added file: http://bugs.python.org/file23202/python_patch5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:56:04 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:56:04 +0000
Subject: [issue13018] Resource is not released before returning from the
	functiion
Message-ID: <1316530564.57.0.408350668852.issue13018@psf.upfronthosting.co.za>


New submission from Suman Saha :

Something that is allocated using PyObject_CallObjec is not freed on one
or more error paths.

----------
files: python_patch6
messages: 144335
nosy: Suman.Saha
priority: normal
severity: normal
status: open
title: Resource is not released before returning from the functiion
type: resource usage
Added file: http://bugs.python.org/file23203/python_patch6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:56:51 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:56:51 +0000
Subject: [issue13019] Resource is not released before returning from the
	functiion
Message-ID: <1316530611.41.0.519397979389.issue13019@psf.upfronthosting.co.za>


New submission from Suman Saha :

1. Something that is allocated using PyObject_GetIter is not freed on one error path.
2. Something that is allocated using PyByteArray_FromStringAndSize is not freed on one error path

----------
files: python_patch7
messages: 144336
nosy: Suman.Saha
priority: normal
severity: normal
status: open
title: Resource is not released before returning from the functiion
type: resource usage
Added file: http://bugs.python.org/file23204/python_patch7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:57:35 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:57:35 +0000
Subject: [issue13020] Resource is not released before returning from the
	functiion
Message-ID: <1316530655.8.0.189777030615.issue13020@psf.upfronthosting.co.za>


New submission from Suman Saha :

Something that is allocated using PySequence_Fast is not freed on one error path.

----------
files: python_patch8
messages: 144337
nosy: Suman.Saha
priority: normal
severity: normal
status: open
title: Resource is not released before returning from the functiion
type: resource usage
Added file: http://bugs.python.org/file23205/python_patch8

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 16:58:13 2011
From: report at bugs.python.org (Suman Saha)
Date: Tue, 20 Sep 2011 14:58:13 +0000
Subject: [issue13021] Resource is not released before returning from the
	functiion
Message-ID: <1316530693.5.0.703564325805.issue13021@psf.upfronthosting.co.za>


New submission from Suman Saha :

Something that is allocated using PyUnicode_DecodeFSDefault is not freed on one error path.

----------
files: python_patch9
messages: 144338
nosy: Suman.Saha
priority: normal
severity: normal
status: open
title: Resource is not released before returning from the functiion
type: resource usage
Added file: http://bugs.python.org/file23206/python_patch9

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 17:06:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Sep 2011 15:06:21 +0000
Subject: [issue13021] Resource is not released before returning from the
	functiion
In-Reply-To: <1316530693.5.0.703564325805.issue13021@psf.upfronthosting.co.za>
Message-ID: <1316531181.54.0.364215198875.issue13021@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +haypo
stage:  -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 17:07:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Sep 2011 15:07:21 +0000
Subject: [issue13021] Resource is not released before returning from the
	functiion
In-Reply-To: <1316530693.5.0.703564325805.issue13021@psf.upfronthosting.co.za>
Message-ID: <1316531241.59.0.674909557782.issue13021@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
stage: patch review -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 17:09:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Sep 2011 15:09:54 +0000
Subject: [issue13020] Resource is not released before returning from the
	functiion
In-Reply-To: <1316530655.8.0.189777030615.issue13020@psf.upfronthosting.co.za>
Message-ID: <1316531394.96.0.285752414574.issue13020@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Hi, thanks for the report(s) and the patch(es)!
I think it would be better to have a test that shows the refleak for each of the patches that you submitted.
Just out of curiosity, how did you find these?

----------
nosy: +ezio.melotti
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 17:11:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 20 Sep 2011 15:11:39 +0000
Subject: [issue13008] syntax error when pasting valid snippet into console
	without empty string after the function def
In-Reply-To: <1316442084.93.0.49113454288.issue13008@psf.upfronthosting.co.za>
Message-ID: <1316531499.56.0.893215071035.issue13008@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti
versions:  -Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 18:35:27 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Sep 2011 16:35:27 +0000
Subject: [issue13021] Resource is not released before returning from the
	functiion
In-Reply-To: <1316530693.5.0.703564325805.issue13021@psf.upfronthosting.co.za>
Message-ID: <1316536527.42.0.305400893901.issue13021@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

It's not me, it's Barry! (PEP 3147: 7b69e630d237)

----------
nosy: +barry

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 18:40:28 2011
From: report at bugs.python.org (Mayur & Angela Patel-Lam)
Date: Tue, 20 Sep 2011 16:40:28 +0000
Subject: [issue12993] prepared statements in sqlite3 module
In-Reply-To: <1316296046.48.0.323470592892.issue12993@psf.upfronthosting.co.za>
Message-ID: 


Mayur & Angela Patel-Lam  added the comment:

Okay, I missed that in the documentation.  I was looking for a handle to a
prepared statement.  I suppose it's hashing on the text of the SQL statement
to determine equivalence?

I'm willing to retract the request.  I need to restructure my code a little
bit to take advantage of this feature.

On Sat, Sep 17, 2011 at 5:47 PM, poq  wrote:

>
> poq  added the comment:
>
> The sqlite3 module already uses prepared statements. Quoting from the
> documentation:
>
> "The sqlite3 module internally uses a statement cache to avoid SQL parsing
> overhead. If you want to explicitly set the number of statements that are
> cached for the connection, you can set the cached_statements parameter. The
> currently implemented default is to cache 100 statements."
>
> ----------
> nosy: +poq
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
Added file: http://bugs.python.org/file23207/unnamed

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
Okay, I missed that in the documentation.?? I was looking for a handle to a prepared statement.?? I suppose it's hashing on the text of the SQL statement to determine equivalence?

I'm willing to retract the request.?? I need to restructure my code a little bit to take advantage of this feature.




On Sat, Sep 17, 2011 at 5:47 PM, poq <report at bugs.python.org> wrote:



poq <poq at gmx.com> added the comment:



The sqlite3 module already uses prepared statements. Quoting from the documentation:



"The sqlite3 module internally uses a statement cache to avoid SQL parsing overhead. If you want to explicitly set the number of statements that are cached for the connection, you can set the cached_statements parameter. The currently implemented default is to cache 100 statements."




----------

nosy: +poq




_______________________________________

Python tracker <report at bugs.python.org>

<http://bugs.python.org/issue12993>

_______________________________________





From report at bugs.python.org  Tue Sep 20 19:25:54 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Sep 2011 17:25:54 +0000
Subject: [issue12996] multiprocessing.Connection endianness issue
In-Reply-To: <1316198455.11.0.87432837805.issue12996@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 9c1c81d24e23 by Charles-Fran?ois Natali in branch 'default':
Issue #12996: multiprocessing.connection: transmit the header in network byte
http://hg.python.org/cpython/rev/9c1c81d24e23

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 19:56:45 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Sep 2011 17:56:45 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316541405.79.0.999034167974.issue13012@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file23208/issue13012.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 19:56:59 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Sep 2011 17:56:59 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316541419.02.0.254033948206.issue13012@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 20:06:29 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 20 Sep 2011 18:06:29 +0000
Subject: [issue13021] Resource is not released before returning from the
	functiion
In-Reply-To: <1316530693.5.0.703564325805.issue13021@psf.upfronthosting.co.za>
Message-ID: <1316541989.86.0.437327399836.issue13021@psf.upfronthosting.co.za>


Barry A. Warsaw  added the comment:

Suman, good eye, confirmed!  Thanks for the patch, I'll commit this to 3.2 and 3.3.

----------
assignee:  -> barry

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 20:27:21 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 20 Sep 2011 18:27:21 +0000
Subject: [issue12996] multiprocessing.Connection endianness issue
In-Reply-To: <1316198455.11.0.87432837805.issue12996@psf.upfronthosting.co.za>
Message-ID: <1316543241.81.0.0214284342214.issue12996@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 20:34:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Sep 2011 18:34:57 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 1d91a3ba5c87 by Charles-Fran?ois Natali in branch 'default':
Issue #12981: test_multiprocessing: catch ImportError when importing
http://hg.python.org/cpython/rev/1d91a3ba5c87

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 20:37:20 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 20 Sep 2011 18:37:20 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <20110919193016.GA5038@dbwatson.ukfsn.org>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

I committed the patch to catch the ImportError in test_multiprocessing.
I'll commit the other patch (pure Python version) in a couple days.

> Ah, no, you're right - that's fine.  Sorry for the false alarm.

No problem. As they say, "better safe than sorry".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 20:41:22 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Sep 2011 18:41:22 +0000
Subject: [issue13013] Resource is not released before returning from the
	functiion
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1316544082.2.0.483294800498.issue13013@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
components: +ctypes

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 20:43:39 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 20 Sep 2011 18:43:39 +0000
Subject: [issue13021] Resource is not released before returning from the
	function
In-Reply-To: <1316530693.5.0.703564325805.issue13021@psf.upfronthosting.co.za>
Message-ID: <1316544219.44.0.603635105155.issue13021@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw :


----------
title: Resource is not released before returning from the functiion -> Resource is not released before returning from the function

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 20:46:55 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Tue, 20 Sep 2011 18:46:55 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316544415.57.0.192685703593.issue12961@psf.upfronthosting.co.za>


Phillip Feldman  added the comment:

Mark: I disagree with your claim that "in its basic form, this is covered by itertools.combinations".  If you open the attached text on elementary combinatorics and go to page 11, you will see a table that lays out six of the eight most basic types of occupancy problem.  Note that only two of the six are handled by itertools.combinations.

----------
Added file: http://bugs.python.org/file23209/math-408-notes-b.pdf

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 20:58:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Sep 2011 18:58:42 +0000
Subject: [issue13021] Resource is not released before returning from the
	function
In-Reply-To: <1316530693.5.0.703564325805.issue13021@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 7a48e98915f2 by Barry Warsaw in branch '3.2':
- Issue #13021: Missing decref on an error path.  Thanks to Suman Saha for
http://hg.python.org/cpython/rev/7a48e98915f2

New changeset ad0804d3dbd0 by Barry Warsaw in branch 'default':
- Issue #13021: Missing decref on an error path.  Thanks to Suman Saha for
http://hg.python.org/cpython/rev/ad0804d3dbd0

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 21:01:25 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 20 Sep 2011 19:01:25 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316545285.04.0.372048782823.issue12961@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> Mark: I disagree ...

Okay, I misunderstood.  I thought you were still talking about the unlabelled balls in labelled boxes problem, which is an isomorphic problem to that solved by combinations_with_replacement.

It looks as though you're now widening the scope of your proposal.  Please could you give clear descriptions of exactly what functionality you're proposing to add?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 21:17:43 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 20 Sep 2011 19:17:43 +0000
Subject: [issue13021] Resource is not released before returning from the
	function
In-Reply-To: <1316530693.5.0.703564325805.issue13021@psf.upfronthosting.co.za>
Message-ID: <1316546263.56.0.582796016628.issue13021@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 21:42:35 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 19:42:35 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316547755.82.0.0047895817184.issue11682@psf.upfronthosting.co.za>


Zbyszek Szmek  added the comment:

Here are the un-reflowed documentation changes, as a patch this time. I've split the changes in two:
0001 is the real documentation change
0002 is the link fixes [optional].

----------
Added file: http://bugs.python.org/file23210/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 21:43:09 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 19:43:09 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316547789.46.0.197529625896.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


Added file: http://bugs.python.org/file23211/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 21:49:23 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 19:49:23 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316548163.33.0.902308452684.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


Removed file: http://bugs.python.org/file23210/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 21:49:33 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 19:49:33 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316548173.65.0.0454974872056.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


Removed file: http://bugs.python.org/file23211/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 21:50:10 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 19:50:10 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316548210.81.0.327584289312.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


Added file: http://bugs.python.org/file23212/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 21:50:47 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 19:50:47 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316548247.49.0.592312004716.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


Added file: http://bugs.python.org/file23213/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 23:00:49 2011
From: report at bugs.python.org (David Watson)
Date: Tue, 20 Sep 2011 21:00:49 +0000
Subject: [issue13022] _multiprocessing.recvfd() doesn't check that file
	descriptor was actually received
Message-ID: <1316552449.49.0.318949569142.issue13022@psf.upfronthosting.co.za>


New submission from David Watson :

The function _multiprocessing.recvfd() calls recvmsg() and
expects to receive a file descriptor in an SCM_RIGHTS control
message, but doesn't check that such a control message is
actually present.  So if the sender sends data without an
accompanying file descriptor, recvfd() will the return the
integer value of the uninitialized CMSG_DATA() buffer.

The attached recvfd-check.diff checks for a complete control
message of the correct type, and raises RuntimeError if it isn't
there.  This matches the behaviour of the proposed pure-Python
implementation at issue #12981.

The patch includes a test case, but like the other recently-added
tests for the function, it isn't guarded against
multiprocessing.reduction being unavailable.  Issue #12981 has a
patch "skip_reduction.diff" (already in 3.3) to fix this, and I'm
attaching recvfd-skip-reduction-fix.diff to apply on top of it
and guard the new test case as well.

----------
components: Extension Modules
files: recvfd-check.diff
keywords: patch
messages: 144351
nosy: baikie
priority: normal
severity: normal
status: open
title: _multiprocessing.recvfd() doesn't check that file descriptor was actually received
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23214/recvfd-check.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 23:01:05 2011
From: report at bugs.python.org (David Watson)
Date: Tue, 20 Sep 2011 21:01:05 +0000
Subject: [issue13022] _multiprocessing.recvfd() doesn't check that file
	descriptor was actually received
In-Reply-To: <1316552449.49.0.318949569142.issue13022@psf.upfronthosting.co.za>
Message-ID: <1316552465.67.0.774640127784.issue13022@psf.upfronthosting.co.za>


Changes by David Watson :


Added file: http://bugs.python.org/file23215/recvfd-skip-reduction-fix.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 23:02:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Sep 2011 21:02:00 +0000
Subject: [issue13022] _multiprocessing.recvfd() doesn't check that file
	descriptor was actually received
In-Reply-To: <1316552449.49.0.318949569142.issue13022@psf.upfronthosting.co.za>
Message-ID: <1316552520.58.0.591346078178.issue13022@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +neologix

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 20 23:04:08 2011
From: report at bugs.python.org (David Watson)
Date: Tue, 20 Sep 2011 21:04:08 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: 
Message-ID: <20110920210408.GA31542@dbwatson.ukfsn.org>


David Watson  added the comment:

On Tue 20 Sep 2011, Charles-Fran?ois Natali wrote:

> I committed the patch to catch the ImportError in test_multiprocessing.

This should go in all branches, I think - see issue #13022.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 00:03:46 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 22:03:46 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316556226.83.0.0897198785062.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


Removed file: http://bugs.python.org/file23212/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 00:03:55 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 22:03:55 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316556235.63.0.535620560451.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


Removed file: http://bugs.python.org/file23213/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 00:05:36 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 22:05:36 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316556336.3.0.953581404363.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


Added file: http://bugs.python.org/file23216/0001.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 00:05:53 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Tue, 20 Sep 2011 22:05:53 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316556353.83.0.720507524585.issue11682@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


Added file: http://bugs.python.org/file23217/0002.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 00:11:11 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Tue, 20 Sep 2011 22:11:11 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1316556671.63.0.822649101079.issue12806@psf.upfronthosting.co.za>


Denilson Figueiredo de S?  added the comment:

I was about to suggest this feature. I had the exact same need: a formatter that preserves newlines (and maybe whitespace), but that also automatically wraps the lines.

In other words, the behavior would be similar to CSS property white-space: pre-wrap;

----------
nosy: +denilsonsa

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 00:28:27 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Tue, 20 Sep 2011 22:28:27 +0000
Subject: [issue13023] argparse should allow displaying argument default values
	in addition to setting a formatter class
Message-ID: <1316557707.22.0.0719652961871.issue13023@psf.upfronthosting.co.za>


New submission from Denilson Figueiredo de S? :

In my script, I wanted two things at the same time:
1. Setting a formatter class so that the epilog would have the line breaks preserved.
2. Telling argparse to automatically display default values for all arguments.

Currently, both things are handled by the same configuration parameter: formatter_class
This means we can either pass argparse.RawDescriptionHelpFormatter or argparse.ArgumentDefaultsHelpFormatter, but not both.

I did a hackish workaround by subclassing both formatters, and passing my (empty) subclass to ArgumentParser. It works for now, but it might break on future versions.

The ideal solution, however, would have a native support for both features, or at least explicitly allowing subclassing.
Maybe ArgumentDefaultsHelpFormatter could be transformed into a simple boolean parameter passed to ArgumentParser object (and maybe also passed to add_argument() method), instead of being a formatter class.

----------
components: Library (Lib)
messages: 144354
nosy: denilsonsa
priority: normal
severity: normal
status: open
title: argparse should allow displaying argument default values in addition to setting a formatter class
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 00:43:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 20 Sep 2011 22:43:05 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316558585.11.0.854483056703.issue12961@psf.upfronthosting.co.za>


Raymond Hettinger  added the comment:

Any additions would need to be motivated by real world problems.  The issue is that adding more generators makes the module harder to learn and remember, so tools are not usually added "for the sake of completeness".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 01:02:09 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Sep 2011 23:02:09 +0000
Subject: [issue13024] cgitb uses stdout encoding
Message-ID: <1316559729.08.0.724028142076.issue13024@psf.upfronthosting.co.za>


New submission from STINNER Victor :

cgitb module writes its output to sys.stdout by default and so encode its HTML document into stdout encoding, whereas it doesn't specify the HTML encoding.

Moreover it uses stdout error handler. If the locale encoding is ASCII whereas a filename in the traceback contains a non-ASCII character, it fails to encode the non-ASCII characters. Another error handler should be used, xmlcharrefreplace is a good candidate.

To reproduce this issue, use the following script with ASCII locale encoding and a non-ASCII character in name of the current directory:
---
import cgitb
cgitb.enable()
raise ValueError("Hello World")
---

Attached patch uses a workaround similar to the one used in Log._log() from distutils.logging.

----------
components: Library (Lib)
files: cgitb.patch
keywords: patch
messages: 144356
nosy: haypo
priority: normal
severity: normal
status: open
title: cgitb uses stdout encoding
versions: Python 3.3
Added file: http://bugs.python.org/file23218/cgitb.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 01:07:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Sep 2011 23:07:07 +0000
Subject: [issue13025] mimetypes should read the rule file using UTF-8,
	not the locale encoding
Message-ID: <1316560027.85.0.800562759244.issue13025@psf.upfronthosting.co.za>


New submission from STINNER Victor :

On Debian and Ubuntu, /etc/mime.types file is pure ASCII, but on Fedora 15 it contains a non-ASCII character, ? (U+00B3), in the line:
"application/vnd.geocube+xml                     g3 g?"

And the file is encoded in UTF-8.

That's why Python should read this file from UTF-8 instead of the locale encoding, because the locale encoding can be ASCII. Attached patch implements this idead.

I think that it is a bug and so it should also be fixed in Python 3.2.

(Python 2.7 reads the file in binary mode, it doesn't care of the encoding.)

----------
files: mimetypes_encoding.patch
keywords: patch
messages: 144357
nosy: haypo, sandro.tosi, terry.reedy
priority: normal
severity: normal
status: open
title: mimetypes should read the rule file using UTF-8, not the locale encoding
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23219/mimetypes_encoding.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 01:07:16 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Sep 2011 23:07:16 +0000
Subject: [issue13025] mimetypes should read the rule file using UTF-8,
	not the locale encoding
In-Reply-To: <1316560027.85.0.800562759244.issue13025@psf.upfronthosting.co.za>
Message-ID: <1316560036.9.0.819813315534.issue13025@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
components: +Library (Lib), Unicode

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 01:08:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Sep 2011 23:08:04 +0000
Subject: [issue13024] cgitb uses stdout encoding
In-Reply-To: <1316559729.08.0.724028142076.issue13024@psf.upfronthosting.co.za>
Message-ID: <1316560084.25.0.466312582272.issue13024@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
components: +Unicode
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 02:14:59 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 21 Sep 2011 00:14:59 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316564099.0.0.89883484481.issue13012@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

LGTM

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 03:04:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Sep 2011 01:04:07 +0000
Subject: [issue1172711] long long support for array module
Message-ID: 


Roundup Robot  added the comment:

New changeset 15659e0e2b2e by Meador Inge in branch 'default':
Issue #1172711: Add 'long long' support to the array module.
http://hg.python.org/cpython/rev/15659e0e2b2e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 03:06:14 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 21 Sep 2011 01:06:14 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1316567174.93.0.712403751255.issue1172711@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 03:20:09 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Sep 2011 01:20:09 +0000
Subject: [issue1172711] long long support for array module
Message-ID: 


Roundup Robot  added the comment:

New changeset 3c56e546dc60 by Victor Stinner in branch 'default':
Issue #1172711: Update What's New in Python 3.3 document for the struct module
http://hg.python.org/cpython/rev/3c56e546dc60

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 03:32:41 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 21 Sep 2011 01:32:41 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316568761.57.0.252832525827.issue13012@psf.upfronthosting.co.za>


Meador Inge  added the comment:

Patch looks good.  I noticed a change in the conventional type for 
'keepends' from 'int' to 'bool'.  Several unit tests were updated to 
match this change.  Perhaps other call sites should be updated too?  A 
little greping shows:

$ grep -Rl 'splitlines(0)' * --include='*.py'
Doc/tools/docutils/writers/newlatex2e/__init__.py
$ grep -Rl 'splitlines(1)' * --include='*.py'
Doc/tools/sphinx/pycode/pgen2/tokenize.py
Doc/tools/docutils/readers/python/moduleparser.py
Lib/test/test_tokenize.py
Lib/difflib.py
Lib/lib2to3/pgen2/tokenize.py
Lib/codecs.py

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 03:43:41 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 21 Sep 2011 01:43:41 +0000
Subject: [issue13022] _multiprocessing.recvfd() doesn't check that file
	descriptor was actually received
In-Reply-To: <1316552449.49.0.318949569142.issue13022@psf.upfronthosting.co.za>
Message-ID: <1316569421.24.0.494959586565.issue13022@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n :


----------
assignee:  -> jcea
nosy: +jcea

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 03:56:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Sep 2011 01:56:11 +0000
Subject: [issue13022] _multiprocessing.recvfd() doesn't check that file
	descriptor was actually received
In-Reply-To: <1316552449.49.0.318949569142.issue13022@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 21e7a55cb943 by Jesus Cea in branch '2.7':
Close #13022: _multiprocessing.recvfd() doesn't check that file descriptor was actually received
http://hg.python.org/cpython/rev/21e7a55cb943

New changeset 447770470d00 by Jesus Cea in branch '3.2':
Close #13022: _multiprocessing.recvfd() doesn't check that file descriptor was actually received
http://hg.python.org/cpython/rev/447770470d00

New changeset 74434cff2c90 by Jesus Cea in branch 'default':
Close #13022: _multiprocessing.recvfd() doesn't check that file descriptor was actually received
http://hg.python.org/cpython/rev/74434cff2c90

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 04:38:23 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 21 Sep 2011 02:38:23 +0000
Subject: [issue13013] Resource is not released before returning from the
	functiion
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1316572703.32.0.85368722683.issue13013@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I'll take this one.

Suman, thanks for finding this.  It will help in the future if you don't
open a ton of bugs with the *exact* same title.  They are harder to 
filter and keep track of that way.

----------
assignee:  -> meador.inge
nosy: +meador.inge
stage:  -> test needed
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 04:49:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Sep 2011 02:49:28 +0000
Subject: [issue1172711] long long support for array module
Message-ID: 


Roundup Robot  added the comment:

New changeset 672b63aff0f4 by Meador Inge in branch 'default':
Issue #1172711: Update What's New in Python 3.3 document for the array module.
http://hg.python.org/cpython/rev/672b63aff0f4

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 05:49:56 2011
From: report at bugs.python.org (Steven Samuel Cole)
Date: Wed, 21 Sep 2011 03:49:56 +0000
Subject: [issue13004] pprint: add option to truncate sequences
In-Reply-To: <1316367673.59.0.101028933355.issue13004@psf.upfronthosting.co.za>
Message-ID: <1316576996.38.0.988041919325.issue13004@psf.upfronthosting.co.za>


Steven Samuel Cole  added the comment:

@anand: as the names say, the depth parameter limits the depth of display while the length parameter limits the length.

for example, with a data structure of a list of lists of lists and a depth of 2, only the first two levels would be shown, the third list at the 'bottom' would be replaced by '...'

on the other hand, in a list with 10 entries and a length parameter of 5, only 5 list entries would be displayed.

@Raymond: agreed. i have squeezed max_len into the existing code and ported that back to 2.6 for my current project; while it works, it is a bad hack. i would much more prefer bundling efforts into an extensible pprint rewrite.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 05:51:48 2011
From: report at bugs.python.org (Steven Samuel Cole)
Date: Wed, 21 Sep 2011 03:51:48 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1316577108.09.0.485713239471.issue7434@psf.upfronthosting.co.za>


Changes by Steven Samuel Cole :


----------
nosy: +ssc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 06:33:39 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Wed, 21 Sep 2011 04:33:39 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316579619.11.0.0171072730392.issue12961@psf.upfronthosting.co.za>


Phillip Feldman  added the comment:

Ideally, I'd like to see support for all combinations of the following occupancy problem features:

- Labeled and unlabeled boxes
- Labeled and unlabeled balls
- Empty boxes allowed and empty boxes forbidden
- Boxes with no capacity limits and with capacity limits

There are 2^4= 16 combinations in total.  As has been previously noted, some of these can be handled with the existing toolset, but the majority cannot.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 06:44:58 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Wed, 21 Sep 2011 04:44:58 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316580298.42.0.376103736064.issue12961@psf.upfronthosting.co.za>


Phillip Feldman  added the comment:

With the exception of the "empty boxes forbidden" category, I've come across all of these at one time or another, many in the context of error control coding (data communications).  Much of the early work on occupancy problems was motivated by physics and the theory of probability, but if one does Internet searches on occupancy problems, it seems as though there is now more interest in such area as the biological sciences, genetic testing, wildlife monitoring, and the like.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 08:53:09 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 21 Sep 2011 06:53:09 +0000
Subject: [issue13022] _multiprocessing.recvfd() doesn't check that file
	descriptor was actually received
In-Reply-To: 
Message-ID: 


Charles-Fran?ois Natali  added the comment:

> The patch includes a test case, but like the other recently-added
> tests for the function, it isn't guarded against
> multiprocessing.reduction being unavailable.  Issue #12981 has a
> patch "skip_reduction.diff" (already in 3.3) to fix this,

I'll apply skip_reduction.diff and your patch to 2.7 and 3.2.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 09:07:20 2011
From: report at bugs.python.org (Gilles PION)
Date: Wed, 21 Sep 2011 07:07:20 +0000
Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc
In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za>
Message-ID: <1316588840.25.0.445164103091.issue6006@psf.upfronthosting.co.za>


Gilles PION  added the comment:

According to ffi site (http://sourceware.org/libffi/, the latest version is libffi-3.0.10, dated few days ago (which BTW I've been unable to compile on AIX, while 3.0.9 is OK)

So what are those 4.2.0-3 versions coming from?

----------
nosy: +gpion

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 09:31:23 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 07:31:23 +0000
Subject: [issue13014] Resource is not released before returning from the
	functiion
In-Reply-To: <1316530275.76.0.31607583855.issue13014@psf.upfronthosting.co.za>
Message-ID: <1316590283.6.0.778795592423.issue13014@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

This doesn't look right to me: If (rdn != NULL) && (PyList_Size(rdn) > 0),
rdn is already decremented.

There is a leak though if  (rdn != NULL) && (PyList_Size(rdn) == 0).

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 10:06:22 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 08:06:22 +0000
Subject: [issue13014] _ssl.c: resource is not released before returning from
	the function
In-Reply-To: <1316530275.76.0.31607583855.issue13014@psf.upfronthosting.co.za>
Message-ID: <1316592382.02.0.96949626495.issue13014@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
title: Resource is not released before returning from the functiion -> _ssl.c: resource is not released before returning from the function

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 10:14:35 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Sep 2011 08:14:35 +0000
Subject: [issue1172711] long long support for array module
Message-ID: <1316592875.34.0.429007295205.issue1172711@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

> New changeset 672b63aff0f4 by Meador Inge in branch 'default'

Woops, I wrote the wrong module name. Thanks for fixing it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 10:41:36 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Sep 2011 08:41:36 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316594496.79.0.366404158587.issue12961@psf.upfronthosting.co.za>


Raymond Hettinger  added the comment:

Sorry Phillip, I'm closing this feature request because the benefits would likely be outweighed by the costs (maintenance, learning curve, module complexity, etc).  It was not the goal of the module to become a complete combinatorics toolkit; rather, the goal was to provide a set of practical tools for reasonably common needs (i.e. generating combinations of test case inputs).

You are invited to create a full-featured third-party combinatorics module and put it on PyPi. If the quality of the module is high, I will provide links to it from the itertools docs.  If the external module becomes popular (demonstrable user demand), I'll re-open this feature request for further discussion.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 11:44:44 2011
From: report at bugs.python.org (Stefan Ring)
Date: Wed, 21 Sep 2011 09:44:44 +0000
Subject: [issue8271] str.decode('utf8',
	'replace') -- conformance with Unicode 5.2.0
In-Reply-To: <1270002492.52.0.790856673013.issue8271@psf.upfronthosting.co.za>
Message-ID: <1316598284.68.0.337733201827.issue8271@psf.upfronthosting.co.za>


Changes by Stefan Ring :


----------
nosy: +Ringding

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 13:20:51 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 21 Sep 2011 11:20:51 +0000
Subject: [issue12508] Codecs Anomaly
In-Reply-To: <1316278067.86.0.927795690805.issue12508@psf.upfronthosting.co.za>
Message-ID: <4E79C879.50708@egenix.com>


Marc-Andre Lemburg  added the comment:

The final parameter is an extension to the decoder API signature,
so it's not surprising that not all codecs implement it.

The ones that do should use it for all calls, since that way
the actual consumed number of bytes is correctly reported
back to the StreamReader instance.

Note: The parameter name "final" is a bit misleading. What happens
is that the number of bytes consumed by the decoder were previously
always reported as len(buffer), since the C API for decoders did
not provide a way to report back the number of bytes consumed.
This was changed when stateful decoders were added to the C API,
since these do allow reporting back the consumed bytes. A more
appropriate name for the parameter would have been
"report_bytes_consumed".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 13:45:21 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Wed, 21 Sep 2011 11:45:21 +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: <1316605521.99.0.0889984241734.issue12991@psf.upfronthosting.co.za>


Wong Wah Meng  added the comment:

Good news is now I am still using ld, like what is generated in the Makefile file by configure script, and able to do the linking process for the built-in modules successfully. 

I only need to set CC="cc +DD64" and "CXX=aCC" and the process make process is able to build python executable 64-bit and all the built-in modules where the necessary bit can be found.

For other built-in modules, for example, _tkinter, I am also able to build it this time by setting these 3 environment variables where ~/local is where I installed my tcl/tk binary.

export CC="cc +DD64 -I/home/r32813/local/include"
export CXX=aCC
export LDFLAGS="-L/home/r32813/local/lib -lxnet"

I am finally able to build python 64-bit and built-in library on HP ia64 using HP compiler aCC. Thanks for the input everyone. :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 13:48:42 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Wed, 21 Sep 2011 11:48:42 +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: <1316605722.85.0.204010557161.issue12991@psf.upfronthosting.co.za>


Wong Wah Meng  added the comment:

Closing the issue. Please contact me if the README file for HP-UX Itanium 64-bit build should be amended.

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 14:18:47 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Wed, 21 Sep 2011 12:18:47 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1316607527.96.0.0048523387555.issue12729@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


----------
nosy: +zbysz

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 14:23:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 21 Sep 2011 12:23:35 +0000
Subject: [issue12508] Codecs Anomaly
In-Reply-To: <1309992349.71.0.826004213615.issue12508@psf.upfronthosting.co.za>
Message-ID: <1316607815.81.0.973971741836.issue12508@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

AFAIU final means:
  * final=0: I'm passing in a few bytes, but there are more to come, so if the last byte(s) doesn't make sense on its own (e.g. it's a start byte but the continuation bytes are missing), wait for the others before raising an error;
  * final=1: these are the last bytes, so if the last byte(s) doesn't make sense raise an error (or ignore/replace) because there won't be other bytes that might turn that in a well-formed byte sequence.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 15:36:12 2011
From: report at bugs.python.org (Teng Ricky)
Date: Wed, 21 Sep 2011 13:36:12 +0000
Subject: [issue12990] launcher can't work on path including tradition chinese
	char
In-Reply-To: <1316174067.93.0.0828890653583.issue12990@psf.upfronthosting.co.za>
Message-ID: <1316612172.04.0.361000379864.issue12990@psf.upfronthosting.co.za>


Changes by Teng Ricky :


Added file: http://bugs.python.org/file23220/IMG_4359.JPG

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 15:55:51 2011
From: report at bugs.python.org (Ricky Teng)
Date: Wed, 21 Sep 2011 13:55:51 +0000
Subject: [issue12990] launcher can't work on path including tradition
	chinese	char
In-Reply-To: <1316174067.93.0.0828890653583.issue12990@psf.upfronthosting.co.za>
Message-ID: <4E79ECDA.6040606@gmail.com>


Ricky Teng  added the comment:

Excuse me

This is my first time use this bug report.

I have uploaded a jpg to show what I do.

The result is that a console will show and nothing happen.

? 2011/9/16 ?? 07:54, Ronald Oussoren ??:
> New submission from Ronald Oussoren:
>
> Could you please add some more information on how I can reproduce this issue?
>
> ----------
> stage:  ->  test needed
> type:  ->  behavior
>
> _______________________________________
> Python tracker
> 
> _______________________________________
>

----------
title: launcher can't work on path including tradition chinese char -> launcher can't work on path including tradition chinese	char

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 15:59:39 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 21 Sep 2011 13:59:39 +0000
Subject: [issue13019] bytearrayobject.c: Resource is not released before
	returning from the functiion
In-Reply-To: <1316530611.41.0.519397979389.issue13019@psf.upfronthosting.co.za>
Message-ID: <1316613579.62.0.843012836901.issue13019@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
components: +Interpreter Core
title: Resource is not released before returning from the functiion -> bytearrayobject.c: Resource is not released before returning from the functiion

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 16:26:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Sep 2011 14:26:55 +0000
Subject: [issue11682] PEP 380 reference implementation for 3.3
In-Reply-To: <1301110605.68.0.392943983038.issue11682@psf.upfronthosting.co.za>
Message-ID: <1316615215.91.0.176602089706.issue11682@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Doc patch 002 is not strictly related to PEP 380 but pertains more to #10289.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 16:34:50 2011
From: report at bugs.python.org (rubisher)
Date: Wed, 21 Sep 2011 14:34:50 +0000
Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc
In-Reply-To: <1316588840.25.0.445164103091.issue6006@psf.upfronthosting.co.za>
Message-ID: <4E79F606.9000400@scarlet.be>


rubisher  added the comment:

Hello Gilles,

The libffi-4.2.0-3 I used, was coming from the previously mentioned repository:
.

That said, if I click on  link, it points me to 
So, as far as I understand, it's the version of libffi coming with gcc project and so of the same release as the gcc 
available at this place i.e. 4.2.0-3.

What's the difference with sourceware.org/libffi?
It's very not clear to me: reading this announce: , it seems 
that gcc one is the merge of the upstream?

Hth,
	r.

PS: As I was fired from my previous position, I don't have any more access to my testing system and so couldn't more 
helpful, sorry :<(

On 09/21/2011 09:07 AM, Gilles PION wrote:
>
> Gilles PION  added the comment:
>
> According to ffi site (http://sourceware.org/libffi/, the latest version is libffi-3.0.10, dated few days ago (which BTW I've been unable to compile on AIX, while 3.0.9 is OK)
>
> So what are those 4.2.0-3 versions coming from?
>
> ----------
> nosy: +gpion
>
> _______________________________________
> Python tracker
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 16:39:15 2011
From: report at bugs.python.org (higery)
Date: Wed, 21 Sep 2011 14:39:15 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1316615955.87.0.913487907556.issue828450@psf.upfronthosting.co.za>


higery  added the comment:

>>I?ve just found another problem with MANIFEST files created in Windows: they use CRLF.

One cann't let Python generate MANIFEST files taking Unix-style LF as newline endings On Windows, I think.

So, does it mean even though we have already made much effort for this bug, it still cann't make MANIFEST file on different platforms cross-platform?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 16:42:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Sep 2011 14:42:55 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1316616175.66.0.616959595583.issue828450@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> One cann't let Python generate MANIFEST files taking Unix-style LF as newline
> endings On Windows, I think.
Why?  Python can open it fine, and it?s not meant for human edition, so the stupidity of notepad.exe is not a problem .

> So, does it mean even though we have already made much effort for this bug, it
> still cann't make MANIFEST file on different platforms cross-platform?
The problem is that the docs never say that MANIFEST is cross-platform, so I?m not sure changing this qualify for a bug fix.  I have to find time to ask distutils-sig.

See also my point 1) in my previous message: the tests don?t test anything on non-Windows.

For d2 however we can change the MANIFEST format as we like.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 17:09:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Sep 2011 15:09:28 +0000
Subject: [issue12944] Accept arbitrary files for packaging's upload command
In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>
Message-ID: <1316617768.44.0.980235671856.issue12944@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

This was discussed some time ago in a thread starting here: http://mail.python.org/pipermail/catalog-sig/2011-May/003736.html  I?ll summarize the important parts below.

Currently, upload will only push files that are products of a command run from the same command line, e.g. ?sdist upload?.
If you run ?sdist?, check the result, and then do ?sdist upload?, the second sdist should be exactly the same, unless your setup.py is buggy, you made changes to your files or you have a computer problem.  (I agree that?s a lot of unless).  So for distutils, having to run ?sdist upload? is not inefficient, and makes you be explicit about the files you want to push, which is IMO good.

A trick can be used to avoid the second sdist to redo all its work: Fist you run ?python setup.py sdist --keep-temp?, then you check the sdist, and to upload you call ?python setup.py sdist --dry-run upload?.  I?m not in favor of adding that trick to the doc, as for normal usage, running sdist twice is okay.

As you may not be aware, distutils is under a feature freeze.  To cut a long story short, let?s just say that it?s impossible to gradually improve it without breaking a lot of third-party code, so we only fix bugs and we add features in distutils2, the next gen (included in Python 3.3 and available on PyPI for 2.4-3.2 soon).

I think there are good arguments to improve upload for distutils2, mainly:
- you never know what can go wrong, so you want to upload files you have tested
- PyPI will reject bad files anyway, no sense in being more restrictive on the client side

I propose a new option, say -f/--file, that takes a filename as argument:

  pysetup run upload -f dist/spam-0.2.tar.gz -f dist/spam-0.2.exe

I?d prefer to avoid globs (upload -i 'dist.spam-0.1.*' e.g.) because I want to retain the original design choice of the upload command: the person doing the upload needs to be explicit about what kind of file for what versions and with what Python version to upload.

Does that sounds good?

----------
assignee: tarek -> eric.araujo
components: +Distutils2 -Distutils
nosy: +alexis
title: setup.py upload to pypi needs to work with specified files -> Accept arbitrary files for packaging's upload command
versions: +3rd party, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 18:47:46 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Sep 2011 16:47:46 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset c158eac8e951 by Charles-Fran?ois Natali in branch '2.7':
Issue #12981: test_multiprocessing: catch ImportError when importing
http://hg.python.org/cpython/rev/c158eac8e951

New changeset 6e04d406bb86 by Charles-Fran?ois Natali in branch '3.2':
Issue #12981: test_multiprocessing: catch ImportError when importing
http://hg.python.org/cpython/rev/6e04d406bb86

New changeset 21b837aa07b9 by Charles-Fran?ois Natali in branch 'default':
Issue #12981: test_multiprocessing: catch ImportError when importing
http://hg.python.org/cpython/rev/21b837aa07b9

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 19:10:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Sep 2011 17:10:12 +0000
Subject: [issue13002] peephole.c: unused parameter
In-Reply-To: <1316270635.94.0.378241205596.issue13002@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 573d73e62bbc by Stefan Krah in branch 'default':
Issue #13002: Fix Visual Studio warning (not enough actual parameters).
http://hg.python.org/cpython/rev/573d73e62bbc

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 19:32:39 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 21 Sep 2011 17:32:39 +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: <1316626359.88.0.121188990752.issue12991@psf.upfronthosting.co.za>


Senthil Kumaran  added the comment:

Wah Meng and I were discussing about this in a separate thread as well.
I think, it is a good idea to improve the Readme for this issue.

Wah Meng,  since you already went at length to contact HP and clarify linker issue with 64 bit and found a solution to it, it would be a good idea to document it.

Is this the only change for the successful compilation - CC="cc +DD64" and CXX="aCC" .

If there are more details, you can provide changes to the Readme in the form a diff and I shall commit to the trunk.

Thanks!

----------
assignee:  -> orsenthil
components: +Documentation -Build
nosy: +orsenthil
resolution: works for me -> 
status: closed -> open
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 19:44:36 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 17:44:36 +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: <1316627076.28.0.204109113076.issue12991@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

> I think, it is a good idea to improve the Readme for this issue.

+1.

Wah Meng: Building everything is not enough, does 'make test'
complete successfully?

For gcc, Python2.7 relies on two critical options, -fno-strict-aliasing
and -fwrapv. The HP compiler might need similar options.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 19:44:58 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 21 Sep 2011 17:44:58 +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: <1316627098.97.0.301397028531.issue12991@psf.upfronthosting.co.za>


Senthil Kumaran  added the comment:

Wah meng - Instructions to get the _tkinter compile would be a good idea too.  Also, can you verify the same instructions would work for 3.2 version of Python?

----------
keywords: +patch
Added file: http://bugs.python.org/file23221/README.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 20:10:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Sep 2011 18:10:25 +0000
Subject: [issue13005] operator module docs include repeat
In-Reply-To: <1316373895.0.0.0510419466495.issue13005@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 0d0bfbaaf95c by Senthil Kumaran in branch '3.2':
Fix closes issue13005 - Remove the mention of 'repeat' method in the operator module documentation.
http://hg.python.org/cpython/rev/0d0bfbaaf95c

New changeset 6c60f2aacc83 by Senthil Kumaran in branch 'default':
merge 3.2.  Fix closes issue13005 - Remove the mention of 'repeat' method in the operator module documentation.
http://hg.python.org/cpython/rev/6c60f2aacc83

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:23:21 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:23:21 +0000
Subject: [issue13020] structseq.c: refleak
In-Reply-To: <1316530655.8.0.189777030615.issue13020@psf.upfronthosting.co.za>
Message-ID: <1316633001.28.0.106383497882.issue13020@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
title: Resource is not released before returning from the functiion -> structseq.c: refleak

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:24:09 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:24:09 +0000
Subject: [issue13013] _ctypes.c: refleak
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1316633049.63.0.174777202709.issue13013@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
title: Resource is not released before returning from the functiion -> _ctypes.c: refleak

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:26:07 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:26:07 +0000
Subject: [issue13017] pyexpat.c: refleak
In-Reply-To: <1316530520.98.0.265221985232.issue13017@psf.upfronthosting.co.za>
Message-ID: <1316633167.54.0.723069340117.issue13017@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
title: Resource is not released before returning from the functiion -> pyexpat.c: refleak

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:27:03 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:27:03 +0000
Subject: [issue13018] dictobject.c: refleak
In-Reply-To: <1316530564.57.0.408350668852.issue13018@psf.upfronthosting.co.za>
Message-ID: <1316633223.22.0.619654352912.issue13018@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
title: Resource is not released before returning from the functiion -> dictobject.c: refleak

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:28:08 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:28:08 +0000
Subject: [issue13017] pyexpat.c: refleak
In-Reply-To: <1316530520.98.0.265221985232.issue13017@psf.upfronthosting.co.za>
Message-ID: <1316633288.26.0.806594853636.issue13017@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
components: +Extension Modules
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:28:56 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:28:56 +0000
Subject: [issue13018] dictobject.c: refleak
In-Reply-To: <1316530564.57.0.408350668852.issue13018@psf.upfronthosting.co.za>
Message-ID: <1316633336.92.0.257823153529.issue13018@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
components: +Interpreter Core
stage:  -> patch review
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:30:03 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:30:03 +0000
Subject: [issue13014] _ssl.c: refleak
In-Reply-To: <1316530275.76.0.31607583855.issue13014@psf.upfronthosting.co.za>
Message-ID: <1316633403.51.0.981859152046.issue13014@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
components: +Extension Modules
title: _ssl.c: resource is not released before returning from the function -> _ssl.c: refleak
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:31:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:31:49 +0000
Subject: [issue13016] selectmodule.c: refleak
In-Reply-To: <1316530474.09.0.885561459136.issue13016@psf.upfronthosting.co.za>
Message-ID: <1316633509.21.0.603895998632.issue13016@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
components: +Extension Modules
stage:  -> patch review
title: Resource is not released before returning from the functiion -> selectmodule.c: refleak
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:35:43 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:35:43 +0000
Subject: [issue13015] _collectionsmodule.c: refleak
In-Reply-To: <1316530406.22.0.00922720094034.issue13015@psf.upfronthosting.co.za>
Message-ID: <1316633743.44.0.00752137547952.issue13015@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
components: +Extension Modules
stage:  -> patch review
title: Resource is not released before returning from the functiion -> _collectionsmodule.c: refleak
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 21:37:20 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 19:37:20 +0000
Subject: [issue13019] bytearrayobject.c: refleak
In-Reply-To: <1316530611.41.0.519397979389.issue13019@psf.upfronthosting.co.za>
Message-ID: <1316633840.44.0.210783789276.issue13019@psf.upfronthosting.co.za>


Changes by Stefan Krah :


----------
title: bytearrayobject.c: Resource is not released before returning from the functiion -> bytearrayobject.c: refleak

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 22:08:35 2011
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 21 Sep 2011 20:08:35 +0000
Subject: [issue13002] peephole.c: unused parameter
In-Reply-To: <1316270635.94.0.378241205596.issue13002@psf.upfronthosting.co.za>
Message-ID: <1316635715.14.0.231048261964.issue13002@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Thanks for checking the patch! Closing this now.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 22:24:20 2011
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2011 20:24:20 +0000
Subject: [issue6549] ttk.Style not translating some Tcl options
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1316636660.2.0.368894593103.issue6549@psf.upfronthosting.co.za>


Ethan Furman  added the comment:

Not sure what 'embossed' has to do with not having dashes as part of the element option names.

Attached is a patch (hopefully in the right format) agains the current 3.3 sources to remove the dash from the names in .element_names(), as well as return None from .configure() when setting options.

----------
keywords: +patch
nosy: +stoneleaf
Added file: http://bugs.python.org/file23222/ttk.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 23:07:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Sep 2011 21:07:14 +0000
Subject: [issue13010] devguide doc: ./python.exe on OS X
In-Reply-To: <1316450298.9.0.0678816170988.issue13010@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 9363db42626a by Ezio Melotti in branch 'default':
#13010: explain why the python executable has an .exe extension on OS X.
http://hg.python.org/devguide/rev/9363db42626a

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 23:09:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 21 Sep 2011 21:09:24 +0000
Subject: [issue13010] devguide doc: ./python.exe on OS X
In-Reply-To: <1316450298.9.0.0678816170988.issue13010@psf.upfronthosting.co.za>
Message-ID: <1316639364.1.0.451488367184.issue13010@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Fixed, thanks for the report and the suggestion!

----------
components: +Devguide -Documentation
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 21 23:22:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 21 Sep 2011 21:22:25 +0000
Subject: [issue13010] devguide doc: ./python.exe on OS X
In-Reply-To: <1316450298.9.0.0678816170988.issue13010@psf.upfronthosting.co.za>
Message-ID: <1316640145.77.0.474377753351.issue13010@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
assignee: docs at python -> ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 00:02:38 2011
From: report at bugs.python.org (Arnaud Delobelle)
Date: Wed, 21 Sep 2011 22:02:38 +0000
Subject: [issue13026] Dis module - documentation of MAKE_FUNCTION
Message-ID: <1316642558.64.0.601129278503.issue13026@psf.upfronthosting.co.za>


New submission from Arnaud Delobelle :

The description of the opcode MAKE_FUNCTION in the dis module document is out of date.  It still describes the 2.X version of the opcode:

"""
MAKE_FUNCTION(argc)
Pushes a new function object on the stack. TOS is the code associated with the function. The function object is defined to have argc default parameters, which are found below TOS.
"""

According to http://hg.python.org/cpython/file/default/Python/ceval.c#l2684:


 2684             int posdefaults = oparg & 0xff;
 2685             int kwdefaults = (oparg>>8) & 0xff;
 2686             int num_annotations = (oparg >> 16) & 0x7fff;

So the documentation should read something like

"""
MAKE_FUNCTION(argc)
Pushes a new function object on the stack. TOS is the code associated with the function. The function object is defined to have argc & 0xFF positional default parameters, (argc >> 8) & 0xFF keyword only default parameters, and (argc >> 16) & 0x7FFF parameter annotations which are push below TOS in this order. For each keyword only default, the name of the parameter is pushed just below its default value. On top of all the annotations, a tuple is pushed listing the parameter names for these annotations.
"""

----------
assignee: docs at python
components: Documentation
messages: 144393
nosy: arno, docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Dis module - documentation of MAKE_FUNCTION
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 00:16:07 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 21 Sep 2011 22:16:07 +0000
Subject: [issue13026] Dis module - documentation of MAKE_FUNCTION
In-Reply-To: <1316642558.64.0.601129278503.issue13026@psf.upfronthosting.co.za>
Message-ID: <1316643367.6.0.812565034852.issue13026@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Minor edit: in 'which are push below TOS', /push/pushed/.
I understand 'in this order' to mean that positional defaults are pushed first so that they end up on the bottom, whereas annotations are pushed last and end up just under the code object. Correct? (This order makes sense given the structure of function headers.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 00:21:08 2011
From: report at bugs.python.org (Arnaud Delobelle)
Date: Wed, 21 Sep 2011 22:21:08 +0000
Subject: [issue13026] Dis module - documentation of MAKE_FUNCTION
In-Reply-To: <1316642558.64.0.601129278503.issue13026@psf.upfronthosting.co.za>
Message-ID: <1316643668.77.0.478586944503.issue13026@psf.upfronthosting.co.za>


Arnaud Delobelle  added the comment:

Yes, you are correct.  Reading this again, I don't think I should have used the word "pushed" as it sounds like the effect of the opcode is to push stuff onto the stack, whereas I was only trying to describe what is on the stack just before the opcode is executed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 00:21:49 2011
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2011 22:21:49 +0000
Subject: [issue6549] ttk.Style not translating some Tcl options
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1316643709.07.0.372527146994.issue6549@psf.upfronthosting.co.za>


Ethan Furman  added the comment:

The changes to Style.configure were not good.  Corrected so the (possibly empty) result is returned when a query is made but not when configuration is set.

Two patches: one for the element_names issue, one for the configure issue.

Question:  Does it ever make sense to do both a query and a configuration update in the same call?  I don't think it is:

--> ttk.Style.configure('TButton', 'relief', relief='sunken'
'raised'
--> s.configure('TButton','relief')
'raised'

Does it make sense to raise an exception in configure if both query_opt and kw specified?

----------
Added file: http://bugs.python.org/file23223/ttk_style_fixes.zip

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 01:17:17 2011
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 21 Sep 2011 23:17:17 +0000
Subject: [issue6549] ttk.Style -- minor issues with element_names and configure
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1316647037.65.0.229710647099.issue6549@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
title: ttk.Style not translating some Tcl options -> ttk.Style -- minor issues with element_names and configure

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 04:30:46 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 22 Sep 2011 02:30:46 +0000
Subject: [issue13013] _ctypes.c: refleak
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1316658646.76.0.373991259566.issue13013@psf.upfronthosting.co.za>


Meador Inge  added the comment:

This patch seems reasonable.  Upon looking at the code in more
detail, however, I can't see how the error condition that leaks the
reference can ever by triggered.  In particular, the following code
from the 'PyCArrayType_from_ctype' function:

    if (!PyType_Check(itemtype)) {
        PyErr_SetString(PyExc_TypeError,
                        "Expected a type object");
        return NULL;
    }

'PyCArrayType_from_ctype' is only called from 'CDataType_repeat'.  The
'CDataType_repeat' function is only used to implement the 'sq_repeat' 
slot in 'CDataType_as_sequence'.  'CDataType_as_sequence' is used in all 
of the implemented ctypes (struct, array, union, simple, ...).

Unless 'PyCArrayType_from_ctype' is called through some other means
(it is public), then 'itemtype' should *always* be a type.  Or am 
I missing something obvious?  So, we could add the decref or just remove 
the type check code all together (and make 'PyCArrayType_from_ctype'
private).

----------
nosy: +amaury.forgeotdarc, belopolsky

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 04:52:36 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 22 Sep 2011 02:52:36 +0000
Subject: [issue13020] structseq.c: refleak
In-Reply-To: <1316530655.8.0.189777030615.issue13020@psf.upfronthosting.co.za>
Message-ID: <1316659956.46.0.328480063182.issue13020@psf.upfronthosting.co.za>


Meador Inge  added the comment:

In general I agree that a test case is needed, but in this particular
case its looks to be non-trivial to come up with one.  The only way
the reference leak is triggered is when memory is exhausted during an
attempt to new up a 'PyStructSequence' object.

----------
nosy: +meador.inge

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 05:21:29 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 22 Sep 2011 03:21:29 +0000
Subject: [issue12881] ctypes: segfault with large structure field names
In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za>
Message-ID: <1316661689.49.0.525765308843.issue12881@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I am going to open separate issues for the other crashers.

> Also, PyUnicode_FromFormat could be used instead of sprintf.

Amaury, how so?  'sprintf' and 'stgdict->format' work with 'char *'s 
where as 'PyUnicode_FromFormat' builds a unicode string object.

Unless there are any objections, I am going to commit as is.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 06:02:34 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 22 Sep 2011 04:02:34 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1316664154.47.0.753662819154.issue11816@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I took a quick look over the final patch (I will do a more thorough
review later).  I like the general idea a lot.  The first thing that
popped out at me are the names 'OpInfo' and 'get_opinfo'.

'OpInfo' makes it sound like information concerning only the opcode, but
these objects really represent bytecode instructions.  I see a lot
of code in the future like:

    for opinfo in dis.get_opinfo(thing):
        process(opinfo)

which seems vague.  The following seems clearer to me:

    for instr in dis.bytecode_instructions(thing):
        process(instr)

And instead of 'OpInfo' perhaps 'ByteCodeInstruction'.  Even the current
'dis' documentation uses the terminology "Byte Code Instruction".

----------
nosy: +meador.inge

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 06:28:05 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 22 Sep 2011 04:28:05 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1316665685.24.0.0103012336174.issue11816@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

'Op' is just an abbreviation of 'operation'. So 'operation code' becomes 'opcode' and 'operation information' becomes 'opinfo'. The fact that it comes for the 'dis' module gives the context that the *kind* of operation we're talking about is a Python byte code instruction.

When people are hacking on bytecode in the future, they'll likely end up using get_opinfo() a fair bit, so swapping the succinct 'opinfo' for the verbose 'bytecode_instruction' strikes me as a poor trade-off.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 09:02:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 22 Sep 2011 07:02:19 +0000
Subject: [issue13026] Dis module - documentation of MAKE_FUNCTION
In-Reply-To: <1316642558.64.0.601129278503.issue13026@psf.upfronthosting.co.za>
Message-ID: <1316674939.42.0.853579461082.issue13026@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Right. This opcode is the end of a sequence of opcodes that sets up the stack in the way expected. Perhaps something like

Pushes a new function object on the stack. From bottom to top, the consumed stack must have have argc & 0xFF positional default parameter objects, (argc >> 8) & 0xFF keyword only name, default parameter object pairs (with name and object in separate positions), (argc >> 16) & 0x7FFF parameter annotations, a tuple listing the parameter names for the annotations, and finally a code object as TOS.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 09:33:52 2011
From: report at bugs.python.org (Arnaud Delobelle)
Date: Thu, 22 Sep 2011 07:33:52 +0000
Subject: [issue13026] Dis module - documentation of MAKE_FUNCTION
In-Reply-To: <1316642558.64.0.601129278503.issue13026@psf.upfronthosting.co.za>
Message-ID: <1316676832.38.0.0790389615376.issue13026@psf.upfronthosting.co.za>


Arnaud Delobelle  added the comment:

This reads a lot better.  Perhaps change 

    (with name and object in separate positions)

to something like

    (with name just below object on the stack)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 09:44:57 2011
From: report at bugs.python.org (ozan caglayan)
Date: Thu, 22 Sep 2011 07:44:57 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1316677497.01.0.567551375576.issue1625@psf.upfronthosting.co.za>


ozan caglayan  added the comment:

I ported the bz2ms.patch to Python 2.7.2 and it works correctly within the bz2 module.

But when you open a multistream (tar)bz2 with the tarfile module, even the tarfile uses the BZ2File() class, there exists unextracted missing files. I'll now try with the current tip.

----------
nosy: +ozan.caglayan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 10:13:21 2011
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 22 Sep 2011 08:13:21 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316679201.74.0.37475474155.issue12943@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

I don't think the help option needs to be documented, it will document itself.

An additional suggestion is to catch errors on tokenizing and exiting with a non-zero exit status in these cases.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 10:17:22 2011
From: report at bugs.python.org (ozan caglayan)
Date: Thu, 22 Sep 2011 08:17:22 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1316679442.18.0.228159248859.issue1625@psf.upfronthosting.co.za>


ozan caglayan  added the comment:

With the current tip everything works correctly. I think it's because of the complete rewrite of the bz2 module with python and the refactoring of _bz2.so.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 13:24:36 2011
From: report at bugs.python.org (Keith Briggs)
Date: Thu, 22 Sep 2011 11:24:36 +0000
Subject: [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1316690676.3.0.6803900461.issue7133@psf.upfronthosting.co.za>


Keith Briggs  added the comment:

I am still getting this error with SocketServer in Python 2.7.2, even though it looks the same as was fixed in Issue7133:

  File "/usr/local/lib/python2.7/SocketServer.py", line 284, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/lib/python2.7/SocketServer.py", line 310, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/lib/python2.7/SocketServer.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/lib/python2.7/SocketServer.py", line 641, in __init__
    self.finish()
  File "/usr/local/lib/python2.7/SocketServer.py", line 694, in finish
    self.wfile.flush()
  File "/usr/local/lib/python2.7/socket.py", line 303, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
TypeError: must be string or read-only buffer, not memoryview


Keith

----------
nosy: +kbriggs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 15:11:05 2011
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 22 Sep 2011 13:11:05 +0000
Subject: [issue6549] ttk.Style -- minor issues with element_names and configure
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1316697065.99.0.888861954055.issue6549@psf.upfronthosting.co.za>


Changes by Ethan Furman :


----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 15:56:26 2011
From: report at bugs.python.org (Balachandran Sivakumar)
Date: Thu, 22 Sep 2011 13:56:26 +0000
Subject: [issue13027] python 2.6.6 interpreter core dumps on modules command
	from help prompt
Message-ID: <1316699786.14.0.395194212825.issue13027@psf.upfronthosting.co.za>


New submission from Balachandran Sivakumar :

>From the python 2.6.6 interpreter on Debian Lenny(Debian 5.0), on invoking help(), and issuing the modules command, the interpreter seg faults, and dumps core. Also, it throws a few Deprecated warnings for modules like md5. The gdb backtrace on the core had 1 frame. attaching the bt in a separate file.


Core was generated by `python'.
Program terminated with signal 11, Segmentation fault.
#0  0xb5d72e47 in XQueryExtension () from /usr/lib/libX11.so.6
(gdb)

----------
components: Interpreter Core
files: python_bt.log
messages: 144408
nosy: Balachandran.Sivakumar
priority: normal
severity: normal
status: open
title: python 2.6.6 interpreter core dumps on modules command from help prompt
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file23224/python_bt.log

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 16:30:22 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 22 Sep 2011 14:30:22 +0000
Subject: [issue11816] Refactor the dis module to provide better building
	blocks for bytecode analysis
In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za>
Message-ID: <1316701822.03.0.992552271867.issue11816@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I agree that 'bytecode_instructions' is a long-winded.  FWIW, I
have worked on or with a fair amount instruction level things and
"instruction" or "instr" seem to be the established domain terminology.

Here are a few examples:

* Java ASM - http://asm.ow2.org/asm33/javadoc/user/index.html
   - Classes named 'InsnList', 'InsnNode'
* PyPy - https://bitbucket.org/pypy/pypy/src/default/pypy/interpreter/astcompiler/assemble.py
   - class named 'Instruction'
* Python - http://hg.python.org/cpython/file/a06ef7ab7321/Python/compile.c#l45
   - struct named 'instr'
* binutils - http://sourceware.org/git/?p=binutils.git;a=tree
   - structs, variables, etc ... with use of 'insn' and 'instruction'
* gcc - http://gcc.gnu.org/git/?p=gcc.git;a=tree
   - structs, variables, etc ... with use of 'insn' and 'instruction'

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 17:36:27 2011
From: report at bugs.python.org (Cherniavsky Beni)
Date: Thu, 22 Sep 2011 15:36:27 +0000
Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ...
In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za>
Message-ID: <1316705787.24.0.781796104508.issue7475@psf.upfronthosting.co.za>


Changes by Cherniavsky Beni :


----------
nosy: +cben

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 19:59:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 17:59:54 +0000
Subject: [issue13027] python 2.6.6 interpreter core dumps on modules command
	from help prompt
In-Reply-To: <1316699786.14.0.395194212825.issue13027@psf.upfronthosting.co.za>
Message-ID: <1316714394.32.0.0132010631546.issue13027@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

help("modules") imports all the modules, and you probably have some module that once imported makes the interpreter crash (maybe _keybinder? you could try importing that from the interpreter and see if it crashes).
The deprecation warnings comes from deprecated modules that get imported too, maybe these could be silenced by help().

I'm not sure there's much we can do with this though, see also #12902.

----------
nosy: +ezio.melotti, terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 20:05:48 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Thu, 22 Sep 2011 18:05:48 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1316714748.44.0.391675926622.issue1625@psf.upfronthosting.co.za>


Changes by G?k?en Eraslan :


----------
nosy: +G?k?en.Eraslan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 20:08:20 2011
From: report at bugs.python.org (Balachandran Sivakumar)
Date: Thu, 22 Sep 2011 18:08:20 +0000
Subject: [issue13027] python 2.6.6 interpreter core dumps on modules command
	from help prompt
In-Reply-To: <1316699786.14.0.395194212825.issue13027@psf.upfronthosting.co.za>
Message-ID: <1316714900.79.0.857373533707.issue13027@psf.upfronthosting.co.za>


Balachandran Sivakumar  added the comment:

But this doesn't happen in other versions of python. Also what I did is something like this:
bala at bala$ python
...
...
>>> help()
...
...
...
help > modules

It is after this I see it dumping. And I see this only with 2.6.6. I have other versions in other machines(all running Debian) and none of them crash. In my opinion, a seg fault doesn't look good. Of course, if we can't do much about it, I don't have a problem closing it down. core But a segv looks bad to the beginner, who is more likely to use this. In fact, I was using that just to show a beginner how to get help :(

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 20:46:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 18:46:37 +0000
Subject: [issue13027] python 2.6.6 interpreter core dumps on modules command
	from help prompt
In-Reply-To: <1316699786.14.0.395194212825.issue13027@psf.upfronthosting.co.za>
Message-ID: <1316717197.88.0.840366023947.issue13027@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Doing "help('modules')" and "help(), help> modules" should be the same.
My point is that the crash is not Python's fault, but it's caused by some extension module that gets imported by help('modules').  This module is probably not installed on the other machines and on the same machine for other Python versions, so it doesn't crash there.  You can look on sys.path to see the places where Python searches for the modules.

If you manage to identify the module, you could report the problem to their bug tracker.  AFAIK Python can't do anything to prevent/contain a crash while importing an extension module.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 20:56:47 2011
From: report at bugs.python.org (Roger)
Date: Thu, 22 Sep 2011 18:56:47 +0000
Subject: [issue13028] python wastes linux users time by checking for dylib on
	each dynamic library load
Message-ID: <1316717807.43.0.635056141333.issue13028@psf.upfronthosting.co.za>


New submission from Roger :

instead it should check for linux once, store that linux is used and not even once check for dylib

strace extract

[pid 23025] stat64("//lib/libreadline.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libreadline.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libreadline.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib64/libreadline.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib64/libreadline.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib64/libreadline.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib64/libreadline.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib64/libreadline.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib64/libreadline.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib/libreadline.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib/libreadline.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib/libreadline.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib/libreadline.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib/libreadline.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib/libreadline.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libncursesw.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libncursesw.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libncursesw.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib64/libncursesw.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib64/libncursesw.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib64/libncursesw.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib64/libncursesw.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib64/libncursesw.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib64/libncursesw.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib/libncursesw.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib/libncursesw.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/lib/libncursesw.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib/libncursesw.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib/libncursesw.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/lib/libncursesw.a", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libncurses.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libncurses.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libncurses.a", {st_mode=S_IFREG|0644, st_size=431218, ...}) = 0
[pid 23025] stat64("//lib/libcrypt.dylib", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libcrypt.so", 0xbfd27c1c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libcrypt.a", {st_mode=S_IFREG|0644, st_size=8, ...}) = 0
[pid 23025] stat64("//include/openssl/ssl.h", {st_mode=S_IFREG|0644, st_size=93660, ...}) = 0
[pid 23025] stat64("//include/krb5.h", 0xbfd27cac) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("./krb5.h", 0xbfd27cac) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("Include/krb5.h", 0xbfd27cac) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("./Include/krb5.h", 0xbfd27cac) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/src/Python-2.7.2/Include/krb5.h", 0xbfd27cac) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/src/Python-2.7.2/krb5.h", 0xbfd27cac) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/include/krb5.h", 0xbfd27cac) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("/usr/kerberos/include/krb5.h", 0xbfd27cac) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libssl.dylib", 0xbfd27b3c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libssl.so", 0xbfd27b3c) = -1 ENOENT (No such file or directory)
[pid 23025] stat64("//lib/libssl.a", {st_mode=S_IFREG|0644, st_size=448496, ...}) = 0

----------
messages: 144413
nosy: fzvqedi
priority: normal
severity: normal
status: open
title: python wastes linux users time by checking for dylib on each dynamic library load
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 21:00:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 19:00:24 +0000
Subject: [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1316718024.54.0.124032574679.issue12902@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Since help("modules") just shows a list of modules without any description, maybe it could avoid importing them until further information about individual modules are requested.

Also while trying to do help("modules") twice on py3k, I noticed that the second time many modules are missing from the list.  Is this expected and/or a known issue?

----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 21:36:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Sep 2011 19:36:54 +0000
Subject: [issue13028] python wastes linux users time by checking for dylib on
	each dynamic library load
In-Reply-To: <1316717807.43.0.635056141333.issue13028@psf.upfronthosting.co.za>
Message-ID: <1316720214.46.0.995254539934.issue13028@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

The list of file extensions is written in _PyImport_DynLoadFiletab constant. This list depends on the OS. For Linux, the list is defined in: Python/dynload_shlib.c.

I don't understand because in Python 2.7, Python/dynload_shlib.c doesn't contain ".dylib".

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:06:51 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 22 Sep 2011 21:06:51 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1316725611.07.0.933964293913.issue10141@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

Here's an updated patch, with more tests.
Please review!

----------
keywords: +needs review
nosy: +haypo
stage: patch review -> commit review
Added file: http://bugs.python.org/file23225/socketcan_v4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:09:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Sep 2011 21:09:04 +0000
Subject: [issue13029] test_strptime fails on Windows 7 french
Message-ID: <1316725744.77.0.0655730808912.issue13029@psf.upfronthosting.co.za>


New submission from STINNER Victor :

Python 3 uses wcsftime() to format a timestamp and decodes tzname[0] and tzname[1] from UTF-8. The problem is that both methods format the quote differently: U+0092 for wcsftime("%Z") and U+2019 in tzname[1].


>>> time.strftime("%Z")
'Paris, Madrid (heure d\x92?t?)'

>>> time.tzname
('Paris, Madrid', 'Paris, Madrid (heure d\u2019?t?)')

======================================================================
ERROR: test_timezone (test.test_strptime.StrptimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\victor\cpython\lib\test\test_strptime.py", line 303, in test_timezone

    strp_output = _strptime._strptime_time(strf_output, "%Z")
  File "C:\victor\cpython\lib\_strptime.py", line 482, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "C:\victor\cpython\lib\_strptime.py", line 340, in _strptime
    data_string[found.end():])
ValueError: unconverted data remains:  (heure d\x92?t?)

======================================================================
FAIL: test_timezone (test.test_strptime.LocaleTime_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\victor\cpython\lib\test\test_strptime.py", line 78, in test_timezone
    (timezone, self.LT_ins.timezone))
AssertionError: False is not true : timezone paris, madrid (heure d\x92?t?) not
found in (frozenset({'utc', 'paris, madrid', 'gmt'}), frozenset({'paris, madrid
(heure d\u2019?t?)'}))

----------------------------------------------------------------------

----------
components: Unicode, Windows
messages: 144417
nosy: haypo
priority: normal
severity: normal
status: open
title: test_strptime fails on Windows 7 french
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:09:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Sep 2011 21:09:18 +0000
Subject: [issue13029] test_strptime fails on Windows 7 french
In-Reply-To: <1316725744.77.0.0655730808912.issue13029@psf.upfronthosting.co.za>
Message-ID: <1316725758.75.0.0181810319545.issue13029@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +belopolsky

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:09:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Sep 2011 21:09:36 +0000
Subject: [issue13029] test_strptime fails on Windows 7 french
In-Reply-To: <1316725744.77.0.0655730808912.issue13029@psf.upfronthosting.co.za>
Message-ID: <1316725776.65.0.308341407834.issue13029@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

See also issue #10653.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:09:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Sep 2011 21:09:43 +0000
Subject: [issue10653] test_time test_strptime fails on windows
In-Reply-To: <1291820491.4.0.666293971337.issue10653@psf.upfronthosting.co.za>
Message-ID: <1316725783.24.0.0082659495227.issue10653@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

See also issue #13029.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:26:37 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 22 Sep 2011 21:26:37 +0000
Subject: [issue13029] test_strptime fails on Windows 7 french
In-Reply-To: <1316725744.77.0.0655730808912.issue13029@psf.upfronthosting.co.za>
Message-ID: <1316726797.71.0.373478440527.issue13029@psf.upfronthosting.co.za>


Alexander Belopolsky  added the comment:

Isn't this a duplicate of #10653?  In any case, this looks like a windows only issue, so I cannot move it further.  Would be interested in resolution, though.  Thanks for making me nosy.

----------
nosy: +ocean-city

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:30:25 2011
From: report at bugs.python.org (Victor Ruiz)
Date: Thu, 22 Sep 2011 21:30:25 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1316727025.26.0.468929895035.issue10254@psf.upfronthosting.co.za>


Victor Ruiz  added the comment:

Hi,

I think I've come across what seems to be another flavor of this issue. The  following string will cause a crash in some interpreters.

text = u"""\u062d\u064e\u064a\u0651\u064b\u0627\u060c\u0648\u064e\u064a\u064e\u062d\u0650\u0642\u0651\u064e \u0627\u0644\u0652\u0642\u064e\u0648\u0652\u0644\u064f
\u0648\u064e\u0644\u0651\u064e\u064a\u0652\u062a\u064f\u0643\u064f\u0645\u064e\u0627\u060c \u0648\u064e\u0625\u0650\u0646\u0652 \u0623\u064e\u0628\u064e\u064a\u0652\u062a\u064f\u0645\u064e\u0627 
\u0623\u064e\u0646\u0652 \u062a\u064f\u0642\u0650\u0631\u0651\u064e\u0627 \u0628\u0650\u0627\u0644\u0625\u0650\u0633\u0652\u0644\u0627\u064e\u0645\u0650 \u0641\u064e\u0625\u0650\u0646\u0651\u064e
\u0648\u064e\u062e\u064e\u064a\u0652\u0644\u0650\u064a \u062a\u064e\u062d\u064f\u0644\u0651\u064f \u0628\u0650\u0633\u064e\u0627\u062d\u064e\u062a\u0650\u0643\u064f\u0645\u064e\u0627\u060c 
\u0648\u064e\u062a\u064e\u0638\u0652\u0647\u064e\u0631\u064f \u0646\u064f\u0628\u064f\u0648\u0651\u064e\u062a\u0650\u064a 
\u0645\u064f\u0644\u0652\u0643\u0650\u0643\u064f\u0645\u064e\u0627".\u0648\u0643\u062a\u0628 \u0623\u0628\u064a\u0651\u064f \u0628\u0646 \u0643\u0639\u0628 
\u0627\u0644\u0652\u0631\u064e\u0651\u062d\u0650\u064a\u0652\u0645\u060c \u0645\u0650\u0646 \u0645\u064f\u062d\u064e\u0645\u064e\u0651\u062f \u0631\u064e\u0633\u064f\u0648\u0652\u0644 
\u0627\u0644\u0652\u0644\u064e\u0651\u0647 \u0625\u0650\u0644\u064e\u0649 \u0627\u0644\u0652\u0645\u064f\u0646\u0652\u0630\u0650\u0631 \u0628\u0652\u0646 \u0633\u064e\u0627\u0648\u0650\u064a
\u0633\u064e\u0644\u064e\u0627\u0645 \u0639\u064e\u0644\u064e\u064a\u0652\u0643 \u0641\u064e\u0625\u0650\u0646\u0650\u0651\u064a \u0623\u064e\u062d\u0652\u0645\u064e\u062f \u0627\u0644\u0652\u0644\u064e\u0651\u0647
\u0625\u0650\u0644\u064e\u064a\u0652\u0643 \u0627\u0644\u064e\u0651\u0630\u0650\u064a\u0644\u064e\u0627 \u0625\u0650\u0644\u064e\u0647 \u063a\u064e\u064a\u0652\u0631\u064f\u0647 
\u0648\u064e\u0623\u064e\u0634\u0652\u0647\u064e\u062f \u0623\u064e\u0646 \u0644\u064e\u0627 \u0625\u0650\u0644\u064e\u0647 \u0625\u0650\u0644\u064e\u0651\u0627 \u0627\u0644\u0652\u0644\u064e\u0651\u0647
"""

There is a sample script attached. This issue does not seem to be related to the python version itself but rather to its compilation. Since the exact same version crashes in OSX but not Ubuntu linux for example.

ERROR -> Python 2.7.1 (r271:86832, Apr 9 2011, 17:12:59) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin
OK -> Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] on linux2

Default version 2.6.6 on Debian squeeze should crash too for example.

This is a trace of the error in 2.7.1 OSX (this interpreter passes the test posted on msg124450):

Process:         Python [78170]
Path:            /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:      Python
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  bash [77126]

Date/Time:       2011-09-22 23:20:48.892 +0200
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:          88509 sec
Crashes Since Last Report:           135
Per-App Crashes Since Last Report:   134
Anonymous UUID:                      F5DD44CE-A8F4-474C-BA10-2B21B4C92C1E

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   org.python.python             	0x0000000100086b33 _PyUnicode_Resize + 51
1   unicodedata.so                	0x0000000100601bff nfc_nfkc + 335
2   unicodedata.so                	0x0000000100601f2a unicodedata_normalize + 154
3   org.python.python             	0x00000001000bfccd PyEval_EvalFrameEx + 20797
4   org.python.python             	0x00000001000c1f16 PyEval_EvalCodeEx + 2118
5   org.python.python             	0x00000001000c2036 PyEval_EvalCode + 54
6   org.python.python             	0x00000001000e6a5e PyRun_FileExFlags + 174
7   org.python.python             	0x00000001000e6d19 PyRun_SimpleFileExFlags + 489
8   org.python.python             	0x00000001000fd6fc Py_Main + 2940
9   org.python.python             	0x0000000100000f14 0x100000000 + 3860

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0644062700200627  rbx: 0x0000000100373d9c  rcx: 0x000000000000003c  rdx: 0x000000000000000a
  rdi: 0x00007fff5fbff078  rsi: 0x0000000080169ba9  rbp: 0x00007fff5fbfefa0  rsp: 0x00007fff5fbfef80
   r8: 0x000000000000004e   r9: 0x000000000000000a  r10: 0x0000000100373db8  r11: 0x0000000100373dac
  r12: 0x00007fff5fbff078  r13: 0x0000000080169ba9  r14: 0x0000000080169ba9  r15: 0x00000000000000a1
  rip: 0x0000000100086b33  rfl: 0x0000000000010206  cr2: 0x000000010066a2f4

Binary Images:
       0x100000000 -        0x100000fff +org.python.python 2.7.1 (2.7.1) <751B99F0-4C88-4BF6-C8CD-AE2D57E4254B> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
       0x100003000 -        0x100163fff +org.python.python 2.7.1, (c) 2004-2008 Python Software Foundation. (2.7.1)  /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python
       0x100600000 -        0x100694fff +unicodedata.so ??? (???)  /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/unicodedata.so
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???)  /usr/lib/dyld
    0x7fff83094000 -     0x7fff8314aff7  libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <03140531-3B2D-1EBA-DA7F-E12CC8F63969> /usr/lib/libobjc.A.dylib
    0x7fff85ddf000 -     0x7fff85de3ff7  libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib
    0x7fff8642d000 -     0x7fff8643eff7  libz.1.dylib 1.2.3 (compatibility 1.0.0)  /usr/lib/libz.1.dylib
    0x7fff8674c000 -     0x7fff868c3fe7  com.apple.CoreFoundation 6.6.5 (550.43) <31A1C118-AD96-0A11-8BDF-BD55B9940EDC> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff86f60000 -     0x7fff8711efff  libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <4274FC73-A257-3A56-4293-5968F3428854> /usr/lib/libicucore.A.dylib
    0x7fff88cd0000 -     0x7fff88e91fef  libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib
    0x7fff88eb7000 -     0x7fff88f34fef  libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib
    0x7fff8a2d8000 -     0x7fff8a324fff  libauto.dylib ??? (???)  /usr/lib/libauto.dylib
    0x7fffffe00000 -     0x7fffffe01fff  libSystem.B.dylib ??? (???) <9AB4F1D1-89DC-0E8A-DC8E-A4FE4D69DB69> /usr/lib/libSystem.B.dylib

Model: MacBookPro5,4, BootROM MBP53.00AC.B03, 2 processors, Intel Core 2 Duo, 2.53 GHz, 4 GB, SMC 1.49f2
Graphics: NVIDIA GeForce 9400M, NVIDIA GeForce 9400M, PCI, 256 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom BCM43xx 1.0 (5.10.131.42.4)
Bluetooth: Version 2.4.5f3, 2 service, 12 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: ST9320423ASG, 298,09 GB
Serial ATA Device: MATSHITADVD-R   UJ-868
USB Device: Internal Memory Card Reader, 0x05ac  (Apple Inc.), 0x8403, 0x26500000 / 2
USB Device: Built-in iSight, 0x05ac  (Apple Inc.), 0x8507, 0x24400000 / 2
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8242, 0x04500000 / 3
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac  (Apple Inc.), 0x0236, 0x04600000 / 2
USB Device: BRCM2046 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0x06100000 / 2
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x8213, 0x06110000 / 5

----------
nosy: +bictorman
Added file: http://bugs.python.org/file23226/crash2.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:31:51 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 22 Sep 2011 21:31:51 +0000
Subject: [issue13030] Be more generic when identifying the Windows main dir in
	installation doc
Message-ID: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za>


New submission from Sandro Tosi :

Given I have no knowledge of the windows system, I'm just proxying http://mail.python.org/pipermail/docs/2011-September/005793.html :

>>>
Under: http://docs.python.org/install/index.html#inst-how-install-works


It notes "Windows	prefix\Lib\site-packages	C:\PythonXY\Lib\site-packages"
for default values on Windows.

In the paragraph following the table is the text: "prefix and
exec-prefix stand for the directories that Python is installed to, and
where it finds its libraries at run-time. They are always the same
under Windows, and very often the same under Unix and Mac OS X. "

I don't know if it's hardcoded into Python distributions to use C, but
it's not correct. The correct way to identify what most people think
of as C is via the %SYSTEMROOT% environment variable, so the path
described would be "%SYSTEMROOT%\PythonXY\Lib\site-packages"

(This is still not the correct way to do things on Windows, but it at
least shouldn't break on systems with a %SYSTEMROOT% other than C.
I've seen configurations like that on systems which boot multiple
versions of Windows.)
<<<

----------
assignee: docs at python
components: Documentation
messages: 144422
nosy: brian.curtin, docs at python, sandro.tosi, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: Be more generic when identifying the Windows main dir in installation doc
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:38:21 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 22 Sep 2011 21:38:21 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1316727501.77.0.0127225230081.issue10254@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky :


----------
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:42:18 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 22 Sep 2011 21:42:18 +0000
Subject: [issue12729] Python lib re cannot handle Unicode properly due to
	narrow/wide bug
In-Reply-To: <1313089435.8.0.838915767835.issue12729@psf.upfronthosting.co.za>
Message-ID: <1316727738.13.0.346680127858.issue12729@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky :


----------
nosy: +belopolsky

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:51:44 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 22 Sep 2011 21:51:44 +0000
Subject: [issue13026] Dis module - documentation of MAKE_FUNCTION
In-Reply-To: <1316642558.64.0.601129278503.issue13026@psf.upfronthosting.co.za>
Message-ID: <1316728304.51.0.134289004232.issue13026@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Agreed

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:52:58 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 22 Sep 2011 21:52:58 +0000
Subject: [issue6549] ttk.Style -- minor issues with element_names and configure
In-Reply-To: <1248300651.32.0.979739193906.issue6549@psf.upfronthosting.co.za>
Message-ID: <1316728378.4.0.239535508196.issue6549@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
stage:  -> patch review
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 22 23:57:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 22 Sep 2011 21:57:32 +0000
Subject: [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1316728652.83.0.341054847373.issue12902@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

As I said in msg143786, the second time only c-coded modules are listed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 00:03:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 22:03:16 +0000
Subject: [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1316728996.43.0.672019306441.issue12902@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Right, I missed that.
If we change the way the list is created this bug will be probably get fixed too.  If we don't, we should open another issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 00:07:10 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 22 Sep 2011 22:07:10 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1316729230.69.0.761116440231.issue10254@psf.upfronthosting.co.za>


Alexander Belopolsky  added the comment:

This new data does not crash Python 2.7.2, so I assume the issue has been fixed.  Re-closing.

----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 00:11:23 2011
From: report at bugs.python.org (Adam Cohen)
Date: Thu, 22 Sep 2011 22:11:23 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1316729483.01.0.736413531424.issue12398@psf.upfronthosting.co.za>


Adam Cohen  added the comment:

I encountered this issue as well. "params" is simply a bytestring, with no encoding. Workaround/proper solution is to cast the string as a bytearray with bytearray(params).

----------
nosy: +Adam.Cohen

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 00:31:22 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Sep 2011 22:31:22 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1316730682.58.0.953116718966.issue10254@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

"This new data does not crash Python 2.7.2, so I assume the issue has been fixed."

Yes, the bug was already fixed in branch 2.7 by the SVN commit r87541:

changeset:   67185:54f1d5651555
branch:      2.7
parent:      67159:2d09af4c137c
user:        Alexander Belopolsky 
date:        Tue Dec 28 15:47:56 2010 +0000
files:       Lib/test/test_normalization.py Lib/test/test_unicodedata.py Modules/unicodedata.c
description:
Merged revisions 87442 via svnmerge from
svn+ssh://pythondev at svn.python.org/python/branches/py3k

........
  r87442 | alexander.belopolsky | 2010-12-22 21:27:37 -0500 (Wed, 22 Dec 2010) | 1 line

  Issue #10254: Fixed a crash and a regression introduced by the implementation of PRI 29.
........

This fix is part of Python 2.7.2, but not of 2.7.2.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 00:46:21 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Sep 2011 22:46:21 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1316731581.65.0.187847229543.issue10254@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

"This fix is part of Python 2.7.2, but not of 2.7.2."

... but not of 2.7.1.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 01:01:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 23:01:16 +0000
Subject: [issue9319] imp.find_module('test/badsyntax_pep3120') causes segfault
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1316732476.49.0.459958704837.issue9319@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Can the workaround be removed from Lib/pydoc.py:2001 ?
I tried to remove it from 3.2 and help('modules spam') seems to work fine.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 01:31:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Sep 2011 23:31:11 +0000
Subject: [issue12931] xmlrpclib confuses unicode and string
In-Reply-To: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset c02e790c4535 by Victor Stinner in branch '2.7':
Issue #12931: xmlrpclib now encodes Unicode URI to ISO-8859-1, instead of
http://hg.python.org/cpython/rev/c02e790c4535

New changeset 5ceab07bcd02 by Victor Stinner in branch '3.2':
Issue #12931: Add a test with Unicode URI to test_xmlrpc
http://hg.python.org/cpython/rev/5ceab07bcd02

New changeset 3b46f2e2d280 by Victor Stinner in branch 'default':
Merge 3.2: Issue #12931: Add a test with Unicode URI to test_xmlrpc
http://hg.python.org/cpython/rev/3b46f2e2d280

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 01:32:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Sep 2011 23:32:31 +0000
Subject: [issue12931] xmlrpclib confuses unicode and string
In-Reply-To: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>
Message-ID: <1316734351.96.0.264190733515.issue12931@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 01:40:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 23:40:14 +0000
Subject: [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1316734814.9.0.254846330826.issue12902@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

> A separate issue would be a feature request to not do that (assuming it really does).

I tried to verify this (the fact that modules get imported with help('modules')).  Here are the results:
  * Lib/foobar.py:
    - help('modules'): foobar in the list, code is *not* executed;
    - help('foobar'): code is executed;
  * Lib/deleteme/__init__.py:
    - help('modules'): deleteme in the list, code is executed;
    - help('deleteme'): code is executed;
  * Lib/deleteme/__init__.py and Lib/deleteme/foobar.py:
    - help('modules'): deleteme in the list, only __init__ code is executed;
    - help('deleteme.foobar'): foobar code is executed;

So it seems the only code that gets executed with help('modules') is the one in packages' __init__s.  It also seems that the code is executed only once, so doing help('deleteme') after help('modules') doesn't execute the code again.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 01:48:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 22 Sep 2011 23:48:37 +0000
Subject: [issue12931] xmlrpclib confuses unicode and string
In-Reply-To: <1315405807.49.0.456740277996.issue12931@psf.upfronthosting.co.za>
Message-ID: <1316735317.96.0.18902509101.issue12931@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
stage:  -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 01:54:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Sep 2011 23:54:34 +0000
Subject: [issue12398] Sending binary data with a POST request in httplib can
	cause Unicode exceptions
In-Reply-To: <1308929993.57.0.810230060664.issue12398@psf.upfronthosting.co.za>
Message-ID: <1316735674.87.0.76035264682.issue12398@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

Here is a patch for httplib encoding HTTP headers to ISO-8859-1, as done in Python 3 (see HTTPConnection.putheader() from http.client). urllib is not affected by this issue because it does already encode Unicode, but encode to ASCII instead of ISO-8859-1.

Related commit in Python 3:

changeset:   67720:b3cadf5cf742
user:        Armin Ronacher 
date:        Sat Jan 22 13:44:22 2011 +0000
files:       Lib/http/client.py Lib/test/test_httpservers.py Misc/NEWS
description:

To match the behaviour of HTTP server, the HTTP client library now also encodes headers with iso-8859-1 (latin1) encoding.  It was already doing that for incoming headers which makes this behaviour now consistent in both incoming and outgoing direction.

----------
keywords: +patch
Added file: http://bugs.python.org/file23227/urllib2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 02:17:41 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Sep 2011 00:17:41 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1316737061.33.0.353797692488.issue10141@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

socketcan_v4.patch:
 - dummy question: why an address is a tuple with 1 string instead of just the string? Does AF_UNIX also uses a tuple of 1 string?
 - the example should also use struct.pack() to create the frame, I don't like hardcoded BLOB
 - in test_socket: _have_socket_can() interprets permission denied as "CAN is not supported", it would be nice to provide a better skip message. Create maybe a decorator based?
 - _have_socket_can(): you may move s.close() outside the try block (add maybe a "else:" block?) because you may hide a real bug in .close()
 - data += b'\0' * (8 - can_dlc): I prefer data = data.ljust(8, '\x00')
 - you might add frame encoder/decoder in your example
 - if (!strcmp(PyBytes_AS_STRING(interfaceName), "")) hum..... PyBytes_GET_SIZE(intername)==0 should be enough
 - you truncate the interface name, it can be surprising, I would prefer an error (e.g. "interface name too long: 20 characters, the maximum is 10 characters" ?)
 - (oh no! don't include horrible configure diff in patches for the bug tracker :-p)

In which Linux version was CAN introduced?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 05:55:26 2011
From: report at bugs.python.org (Meador Inge)
Date: Fri, 23 Sep 2011 03:55:26 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316750126.45.0.500259482176.issue12943@psf.upfronthosting.co.za>


Meador Inge  added the comment:

> I don't think the help option needs to be documented, it will document 
> itself.

Normally I would document it anyway, but in this case there is only the
one option.  So, I dropped it.

> An additional suggestion is to catch errors on tokenizing and exiting 
> with a non-zero exit status in these cases.

I like that idea.  Sample output:

$ python -m tokenize foo.py
foo.py: error: unknown encoding: meador
$ python -m tokenize foo.py
foo.py:7:2: error: unindent does not match any outer indentation level
$ ./python -m tokenize bogus.py
error: [Errno 2] No such file or directory: 'bogus.py'
$ python -m tokenize foo.py
$ echo '[1,' | ./python -m tokenize
1,0-1,1:            OP             '['            
1,1-1,2:            NUMBER         '1'            
1,2-1,3:            OP             ','            
1,3-1,4:            NL             '\n'           
:2:0: error: EOF in multi-line statement

Attached is the latest patch implementing these suggestions.

----------
Added file: http://bugs.python.org/file23228/issue12943-5.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 06:48:55 2011
From: report at bugs.python.org (Justin Peel)
Date: Fri, 23 Sep 2011 04:48:55 +0000
Subject: [issue13031] [PATCH] small speed-up for tarfile.py when unzipping
	tarballs
Message-ID: <1316753335.88.0.48389267066.issue13031@psf.upfronthosting.co.za>


New submission from Justin Peel :

Attached small diff speeds up extracting a gzipped tarball on my machine using python 3.2 by 3-5%. It will probably be a larger percentage on machines that have faster hard drives (mine is 5400rpm).

Basically, the changes speed up calculating the checksums by only doing one slice rather than four and call struct.unpack twice rather than four times. We are able to use less unpack calls because 'x' means to skip a byte.

----------
components: Library (Lib)
files: cpython_tarfile.diff
keywords: patch
messages: 144436
nosy: jpeel
priority: normal
severity: normal
status: open
title: [PATCH] small speed-up for tarfile.py when unzipping tarballs
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23229/cpython_tarfile.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 06:50:04 2011
From: report at bugs.python.org (Justin Peel)
Date: Fri, 23 Sep 2011 04:50:04 +0000
Subject: [issue13031] [PATCH] small speed-up for tarfile.py when unzipping
	tarballs
In-Reply-To: <1316753335.88.0.48389267066.issue13031@psf.upfronthosting.co.za>
Message-ID: <1316753404.2.0.0979990866936.issue13031@psf.upfronthosting.co.za>


Changes by Justin Peel :


----------
type:  -> performance

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 07:20:11 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 23 Sep 2011 05:20:11 +0000
Subject: [issue12943] tokenize: add python -m tokenize support back
In-Reply-To: <1315537867.15.0.614423357455.issue12943@psf.upfronthosting.co.za>
Message-ID: <1316755211.55.0.0983796144842.issue12943@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

I would say this looks good now.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 08:46:23 2011
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Fri, 23 Sep 2011 06:46:23 +0000
Subject: [issue13031] [PATCH] small speed-up for tarfile.py when unzipping
	tarballs
In-Reply-To: <1316753335.88.0.48389267066.issue13031@psf.upfronthosting.co.za>
Message-ID: <1316760383.07.0.667830875634.issue13031@psf.upfronthosting.co.za>


Changes by Lars Gust?bel :


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel
priority: normal -> low
versions: +Python 3.3 -Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 10:37:41 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 23 Sep 2011 08:37:41 +0000
Subject: [issue13032] h2py.py can fail with UnicodeDecodeError
Message-ID: <1316767061.34.0.367682305149.issue13032@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis :

Tools/scripts/h2py.py fails with UnicodeDecodeError when a header file contains characters undecodable in current locale. I suggest to use binary mode. I'm attaching a patch.

----------
components: Demos and Tools
files: h2py.py.patch
keywords: needs review, patch
messages: 144438
nosy: Arfrever, georg.brandl, haypo
priority: normal
severity: normal
status: open
title: h2py.py can fail with UnicodeDecodeError
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23230/h2py.py.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 10:38:29 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 23 Sep 2011 08:38:29 +0000
Subject: [issue13032] h2py.py can fail with UnicodeDecodeError
In-Reply-To: <1316767061.34.0.367682305149.issue13032@psf.upfronthosting.co.za>
Message-ID: <1316767109.21.0.43154826725.issue13032@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis :


----------
keywords: +easy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 11:24:09 2011
From: report at bugs.python.org (Low Kian Seong)
Date: Fri, 23 Sep 2011 09:24:09 +0000
Subject: [issue13033] recursive chown for shutils
Message-ID: <1316769849.87.0.0298236424523.issue13033@psf.upfronthosting.co.za>


New submission from Low Kian Seong :

Currently shutils chown still can't do a recursive chown. It would be nice to have this instead of having to do the looping dance we put our selves through each time we need recursion. Ruby's FileUtils already have this.

----------
components: Library (Lib)
messages: 144439
nosy: Low.Kian.Seong
priority: normal
severity: normal
status: open
title: recursive chown for shutils
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 11:58:48 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 23 Sep 2011 09:58:48 +0000
Subject: [issue13033] recursive chown for shutils
In-Reply-To: <1316769849.87.0.0298236424523.issue13033@psf.upfronthosting.co.za>
Message-ID: <1316771928.65.0.84774457889.issue13033@psf.upfronthosting.co.za>


Eric V. Smith  added the comment:

See also issue 12191, where there was a brief discussion of this.

----------
nosy: +eric.smith

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 13:53:13 2011
From: report at bugs.python.org (Andrea Trasatti)
Date: Fri, 23 Sep 2011 11:53:13 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from SSL
	certificates larger than 1024 bits
Message-ID: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>


New submission from Andrea Trasatti :

We found a problem with SSL certificates, when they are larger than 1024 bits and you need to check Alternative Subject Names.
In our case we have a 2048 bit certificate, issued by Verisign for the domain developer.nokia.com. The certificate also covers other sub-domains, once of which is projects.developer.nokia.com. We found the issue using the mercurial client, but we dug down to SSLSocket.getpeercert. It looks like when the openSSL library reads the certificate it does not return any Alternative Subject Name, even though they are there. Using the standard openssl binary we could read the certificate with no problems and the alternative domain names are all there, including the one we need.

See below two examples, the first is our 2048 bit certificate and what Python returns. Then there is Google's code.google.com SSL certificate, 1024 bits and as you can see Python returns the other names correctly.

This was tested with Python 2.7.2.

Binary for projects.developer.nokia.com
'0\x82\x06\xb10\x82\x05\x99\xa0\x03\x02\x01\x02\x02\x10\x0e\xf6_f@\xe4\xd1gtU\x9e39Rn80\r\x06\t*\x86H\x86\xf7\r\x01\x01\x05\x05\x000\x81\xbc1\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x170\x15\x06\x03U\x04\n\x13\x0eVeriSign,
Inc.1\x1f0\x1d\x06\x03U\x04\x0b\x13\x16VeriSign Trust Network1;09\x06\x03U\x04\x0b\x132Terms of use at https://www.verisign.com/rpa (c)101604\x06\x03U\x04\x03\x13-VeriSign Class 3 International Server CA - G30\x1e\x17\r110608000000Z\x17\r120607235959Z0h1\x0b0\t\x06\x03U\x04\x06\x13\x02FI1\x0e0\x0c\x06\x03U\x04\x08\x13\x05Espoo1\x0e0\x0c\x06\x03U\x04\x07\x14\x05Espoo1\x0e0\x0c\x06\x03U\x04\n\x14\x05Nokia1\x0b0\t\x06\x03U\x04\x0b\x14\x02IT1\x1c0\x1a\x06\x03U\x04\x03\x14\x13developer.nokia.com0\x82\x01"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x01\x0f\x000\x82\x01\n\x02\x82\x01\x01\x00\xf8\xdeL"\x8az\xbb\xa6\xddj\x14\x89X\xeeh\x87\x07\xbd\xb3\xc5=!
\xb9\x80\xe8\xe6v"*\xec6w\x82\r\xb6b\x10\xb8\xe5\x06\x88w\xfd\x03\xa9\x82\x9d\xdf\xdb\xbft\xdb\x06\xc5\'\xdd\x83\x0e\
xf1GdM\x9a\x14\xefyO\x8e\x9dO,
\x92\xf8\xcf\xd3\xb3\xa8m\xc3@^\xa5\x0e\xfb$ddn\xc0\x1cV\xe4\xeaE\xce\x1eoG\xca\xf3\x01\xab\x08V\xd2<\x91\x7f7\xbc\x90\x16\xd6b\xdb\x83(ySA\xccH\x1b\x80"7)^\xe9\x1c\xcaZ&r-\xc6\xf0\xe0\xb6\xde\x16c
W\x0b\xf4\xd24ei[E\xbaY\xc9[;
\xbbs\nQ\xfc\x1b_TiM\x8e\xb6\x9c9\x7f}\xa3\xfe\x96\xab\xa9\xb4\x8dn\\S\xfc\x08\xd5\x1a71
\xd3\x14\xaaF\xd0\xe4\xcf\x0f-\xf9\x10\xa7U\xf6\x92\xafQa\x8b\x02x\xc7V;
\xe2F\xf5 L\xe4\xc1\r\x1f\xec|
\x02\xee\xda\x9ej\xb3\xda\xda\x9b\xf8\xaf\xb5\xa2=\x1e\n\x14qf\xe7\xef\xbd\x8av\xe7l\x9d7\x93\xea\x11\x02\x03\x01\x00\x01\xa3\x82\x03\x000\x82\x02\xfc0\x82\x01I\x06\x03U\x1d\x11\x04\x82\x01 at 0\x82\x01<\x82\x13developer.nokia.com\x82\x17www.developer.nokia.com\x82\x17aux.developer.nokia.com\x82\x16cc.developer.nokia.com\x82\x1cprojects.developer.nokia.com\x82\x17sso.developer.nokia.com\x82\x19stage.developer.nokia.com\x82\x17ejb.developer.nokia.com\x82\x16cm.developer.nokia.com\x82\x17dav.developer.nokia.com\x82\x1fdav.sandbox.developer.nokia.com\x
82\x1ect.sandbox.developer.nokia.com0\t\x06\x03U\x1d\x13\x04\x020\x000\x0b\x06\x03U\x1d\x0f\x04\x04\x03\x02\x05\xa00A\x06\x03U\x1d\x1f\x04:0806\xa04\xa02\x860http://SVRIntl-
G3-crl.verisign.com/SVRIntlG3.crl0D\x06\x03U\x1d
\x04=0;09\x06\x0b`\x86H\x01\x86\xf8E\x01\x07\x17\x030*0(\x06\x08+\x06\x01\x05\x05\x07\x02\x01\x16\x1chttps://www.verisign.com/rpa0(\x06\x03U\x1d%\x04!
0\x1f\x06\t`\x86H\x01\x86\xf8B\x04\x01\x06\x08+\x06\x01\x05\x05\x07\x03\x01\x06\x08+\x06\x01\x05\x05\x07\x03\x020r\x06\x08+\x06\x01\x05\x05\x07\x01\x01\x04f0d0$\x06\x08+\x06\x01\x05\x05\x070\x01\x86\x18http://ocsp.verisign.com0<\x06\x08+\x06\x01\x05\x05\x070\x02\x860http://SVRIntl-
G3-
aia.verisign.com/SVRIntlG3.cer0n\x06\x08+\x06\x01\x05\x05\x07\x01\x0c\x04b0`\xa1^\xa0\\0Z0X0V\x16\timage/gif0!
0\x1f0\x07\x06\x05+\x0e\x03\x02\x1a\x04\x14Kk\xb9(\x96\x06\x0c\xbb\xd0R8\x9b)\xacK\x07\x8b!
\x05\x180&\x16$http://logo.verisign.com/vslogo1.gif0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x05\x05\x00\x03\x82\x01\x01\x006N\x97\x1e\xba\x85\xcb\x1e
\xddO6\xf9\xf3\x16-\xb6\x05\x13"\xec*\x00\x0f\xde\x89\xc1\xb7\xc1^\xf0\x8b0=C\x87\xf3|
zI\xe4\r\xedmD1\xc1\x06[GqMuV\xd9\x03\xdd\xa6\xbd2Z!
\x0c\xdf\x93\x9c\xc6\xba\x12\xd1\xaa\xd08\x1c\x82\x02\xd1\xb3\xeeK\xca\xcaEK\x07\xffR\xcfW\xae\xa0\x85\xeb\xc1h\xeb\r\xad\xd5\x92d\x82\xac\x03(\x07\xa1F\x82\x93\xdep\xe9\x9a\xf8O\xb1\xfc\xe0&\xfat\xf4d\xa3q&`\x05J\xb9\xdb\x9a\xb5o;
\xb7O\xaa/\xac\xba\xab\xc9\xd9)m\xf2c\xe8=\xc4\x95\xef\xe9\x92\xee\tlx\xe2\xfc>\x87\xab\xbe\xde\xd4[\xc3\x85>X\x8f\xf3\xe3\x89\xc9,
\\\xb2:\x9f\xf3\xe2\xf3\x81;
\xdbk\x9f\x1e\xbc\x00\xc7\x87@\xb3\xac\xdf\xe09\xfe:
\xef\n\xcf\xdaCZ\xc7\x07X\xd0\x0f\xf2nBKe\x1f\xd8\xcc\xb4\xa2%\x01<\x0eE\nt{G\r\x9a\xfd\xaf\x97\xaf\xba\xb8\x983\xc5~\xd2\x1d\xdd\x04\x13*\xd3\xf3VK:'

Python dictionary extracted
{'notAfter': 'Jun  7 23:59:59 2012 GMT', 'subject': ((('countryName', u'FI'),), (('stateOrProvinceName', u'Espoo'),), (('localityName', u'Espoo'),), (('organizationName', u'Nokia'),), (('organizationalUnitName', u'IT'),), (('commonName', u'developer.nokia.com'),))}





Binary for code.google.com
'0\x82\x05\x080\x82\x04q\xa0\x03\x02\x01\x02\x02\nk\xf3\xf0+\x00\x03\x00\x00/\xf60\r\x06\t*\x86H\x86\xf7\r\x01\x01\x05\x05\x000F1\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x130\x11\x06\x03U\x04\n\x13\nGoogle
Inc1"0 \x06\x03U\x04\x03\x13\x19Google Internet Authority0\x1e\x17\r110905060549Z\x17\r120905061549Z0f1\x0b0\t\x06\x03U\x04\x06\x13\x02US1\x130\x11\x06\x03U\x04\x08\x13\nCalifornia1\x160\x14\x06\x03U\x04\x07\x13\rMountain
View1\x130\x11\x06\x03U\x04\n\x13\nGoogle
Inc1\x150\x13\x06\x03U\x04\x03\x14\x0c*.google.com0\x81\x9f0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x81\x8d\x000\x81\x89\x02\x81\x81\x00\xbd\x7f49\x0c\xbdg\x962\xd4\x18\x8d#\x16\x91[\xbcH\x8f\xac+\x8a=\xd0\x1cW\x8bRVIh\x89\xf4\x85\xe0\x12\xe1\xfaG\x1a\xf9\x0bQ\xc2\\b;
\x0f$)c\xb9\xc7\xc45\xb90dK1\xf9\xcd\x111\x15]\xac\xb4\xfd\xa7>\x85\x16a\x15\xd3\x870\x82\xf4\xee^\x86\xbb\xd1\xf6\x81\x9a\x06\x07\xbe\xb7\xebx*\x9a\tX\x03;
\x9bE\xad\x02\xeb`(:\xa3k|
\xca"\xca&\xd4\x98\x03I\\\x81\xc1\xb3\xf7\xf2\x95\xc9;\x02\x03\x01\x00\x01\x
a3\x82\x02\xdb0\x82\x02\xd70\x1d\x06\x03U\x1d\x0e\x04\x16\x04\x140\xf5l\xa9\xb8\xd6\xe2\xc7\xcdy\x7fF\xf5)t%\xe4\x9f\x16U0\x1f\x06\x03U\x1d#\x04\x180\x16\x80\x14\xbf\xc00\xeb\xf5C\x11>g\xba\x9e\x91\xfb\xfcj\xda\xe3k\x12$0[\x06\x03U\x1d\x1f\x04T0R0P\xa0N\xa0L\x86Jhttp://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crl0f\x06\x08+\x06\x01\x05\x05\x07\x01\x01\x04Z0X0V\x06\x08+\x06\x01\x05\x05\x070\x02\x86Jhttp://www.gstatic.com/GoogleInternetAuthority/GoogleInternetAuthority.crt0!
\x06\t+\x06\x01\x04\x01\x827\x14\x02\x04\x14\x1e\x12\x00W\x00e\x00b\x00S\x00e\x00r\x00v\x00e\x00r0\x82\x01\xab\x06\x03U\x1d\x11\x04\x82\x01\xa20\x82\x01\x9e\x82\x0c*.google.com\x82\ngoogle.com\x82\x0b*.atggl.com\x82\r*.youtube.com\x82\x0byoutube.com\x82\x0b*.ytimg.com\x82\x0f*.google.com.br\x82\x0e*.google.co.in\x82\x0b*.google.es\x82\x0e*.google.co.uk\x82\x0b*.google.ca\x82\x0b*.google.fr\x82\x0b*.google.pt\x82\x0b*.google.it\x82\x0b*.google.de\x82\x0b*.google.cl\x82\x0b*.google.pl\x82\x0b*.goo
gle.nl\x82\x0f*.google.com.au\x82\x0e*.google.co.jp\x82\x0b*.google.hu\x82\x0f*.google.com.mx\x82\x0f*.google.com.ar\x82\x0f*.google.com.co\x82\x0f*.google.com.vn\x82\x0f*.google.com.tr\x82\r*.android.com\x82\x14*.googlecommerce.com0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x05\x05\x00\x03\x81\x81\x00Mfgo\xae\xd5}\xcb\xf7\xca\x82\xed\xcerGvl`\'F0\x0e?
\x8c0\xbc\x7f\xc6\x0c:\x98\xe0\x02\xe4
J\x10\x9d\xe3\xe5p\xd6\xfam\xe0\x91wY\xdb\xf0-\xefV\xfc\xaeVJ!\x0eL_\xf4|
\xff\xb3q\xf4h%\xcc\xf1\xfe
\xfe\xe4\xa57\xb5\x8d\xeeT\xf3-\x04\x01\xfdB`P\xfb\x82\xf3w\xce\x93\x8e+q\x9b\x03\xc9\xcf[Y\xc0\x0f\xf5,V\xb0$\xe6\x1f9qi\xef\xf1\xb3\xda\xba\xc9\xc0\xbb\x84\x1a\x9f\x89'

Python dictionary
{'notAfter': 'Sep  5 06:15:49 2012 GMT', 'subjectAltName': (('DNS', '*.google.com'), ('DNS', 'google.com'), ('DNS', '*.atggl.com'), ('DNS', '*.youtube.com'), ('DNS', 'youtube.com'), ('DNS', '*.ytimg.com'), ('DNS', '*.google.com.br'), ('DNS', '*.google.co.in'), ('DNS', '*.google.es'), ('DNS', '*.google.co.uk'), ('DNS', '*.google.ca'), ('DNS', '*.google.fr'), ('DNS', '*.google.pt'), ('DNS', '*.google.it'), ('DNS', '*.google.de'), ('DNS', '*.google.cl'), ('DNS', '*.google.pl'), ('DNS', '*.google.nl'), ('DNS', '*.google.com.au'), ('DNS', '*.google.co.jp'), ('DNS', '*.google.hu'), ('DNS', '*.google.com.mx'), ('DNS', '*.google.com.ar'), ('DNS', '*.google.com.co'), ('DNS', '*.google.com.vn'), ('DNS', '*.google.com.tr'), ('DNS', '*.android.com'), ('DNS', '*.googlecommerce.com')), 'subject': 
((('countryName', u'US'),), (('stateOrProvinceName', u'California'),), (('localityName', u'Mountain View'),), (('organizationName', u'Google Inc'),), (('commonName', u'*.google.com'),))}
>>>

----------
messages: 144441
nosy: atrasatti
priority: normal
severity: normal
status: open
title: Python does not read Alternative Subject Names from SSL certificates larger than 1024 bits
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 14:00:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Sep 2011 12:00:43 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from SSL
	certificates larger than 1024 bits
In-Reply-To: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>
Message-ID: <1316779243.99.0.298321788248.issue13034@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
components: +Extension Modules
nosy: +giampaolo.rodola, janssen, pitrou

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 14:14:22 2011
From: report at bugs.python.org (Attila Csipa)
Date: Fri, 23 Sep 2011 12:14:22 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from SSL
	certificates larger than 1024 bits
In-Reply-To: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>
Message-ID: <1316780062.6.0.388046389202.issue13034@psf.upfronthosting.co.za>


Changes by Attila Csipa :


----------
nosy: +achipa

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 15:04:54 2011
From: report at bugs.python.org (poq)
Date: Fri, 23 Sep 2011 13:04:54 +0000
Subject: [issue13031] [PATCH] small speed-up for tarfile.py when unzipping
	tarballs
In-Reply-To: <1316753335.88.0.48389267066.issue13031@psf.upfronthosting.co.za>
Message-ID: <1316783094.82.0.210813616144.issue13031@psf.upfronthosting.co.za>


poq  added the comment:

I don't think you even need the slice, if you use unpack_from.

----------
nosy: +poq

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 15:06:06 2011
From: report at bugs.python.org (ozan caglayan)
Date: Fri, 23 Sep 2011 13:06:06 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1316783166.43.0.699763061486.issue1625@psf.upfronthosting.co.za>


ozan caglayan  added the comment:

Attached patch is a revised version of bz2ms.patch against Python 2.7.2. The patch is tested using tarfile and bz2 modules. It also passes the included tests correctly.

It also imports a missing class from BytesIO to fix the tests.

It's up to you to take that into 2.7.x branch or not.

----------
Added file: http://bugs.python.org/file23231/bz2-multiple-stream-support-issue1625.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 15:57:25 2011
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 23 Sep 2011 13:57:25 +0000
Subject: [issue13035] "maintainer" value clear the "author" value when
	registering
Message-ID: <1316786245.72.0.911460125553.issue13035@psf.upfronthosting.co.za>


New submission from Joshua Bronson :

This issue was originally opened in the PyPI tracker but was dismissed on the theory that it's a bug in Python:

https://sourceforge.net/tracker/index.php?func=detail&aid=3396924&group_id=66150&atid=513503


"""
If in one package's setup.py I provide maintainer (with email) and author (whith email) after the "python setup.py register ... upload" I create a new package where I see the maintainer as a creator.

If I manually fix it through the pypi user interface it works, so seems that this is only a bug in the register procedure.
"""

----------
messages: 144444
nosy: jab
priority: normal
severity: normal
status: open
title: "maintainer" value clear the "author" value when registering

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 16:28:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 14:28:12 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1316788092.12.0.720295724749.issue1625@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

We don?t add news features in stable releases.  Nadeem has closed this bug as fixed for 3.3 and it can?t go in 2.7, so I think we?re done here.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 16:50:34 2011
From: report at bugs.python.org (Russell Keith-Magee)
Date: Fri, 23 Sep 2011 14:50:34 +0000
Subject: [issue11472] upload command fails to read auth information from
	.pypirc
In-Reply-To: <1299882429.66.0.49580074551.issue11472@psf.upfronthosting.co.za>
Message-ID: <1316789434.02.0.326986802493.issue11472@psf.upfronthosting.co.za>


Russell Keith-Magee  added the comment:

This isn't just a Python 3 issue -- I'm seeing this with the default Python install on OS X Snow Leopard (i.e. Python 2.6.1). Changing the .pypirc config line to [server-login] fixed the problem for me, too.

----------
nosy: +freakboy3742

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 17:21:37 2011
From: report at bugs.python.org (Yves Dorfsman)
Date: Fri, 23 Sep 2011 15:21:37 +0000
Subject: [issue13036] time format in logging is wrong
Message-ID: <1316791297.78.0.299394793338.issue13036@psf.upfronthosting.co.za>


New submission from Yves Dorfsman :

The basic time format in the logging module uses a comma instead of a dot to separate the seconds from the tenth of seconds:

    import logging
    logging.basicConfig(format='%(asctime)s %(message)s')
    logging.warning('hello')

2011-09-23 09:08:53,739 hello



Using a dot seems to be more accepted, see:

ls -l --full-time

Java's default dates

python's datetime.datetime.isoformat( datetime.datetime.now() )

----------
components: Library (Lib)
messages: 144447
nosy: yves at zioup.com
priority: normal
severity: normal
status: open
title: time format in logging is wrong
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 17:33:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Sep 2011 15:33:42 +0000
Subject: [issue13036] time format in logging is wrong
In-Reply-To: <1316791297.78.0.299394793338.issue13036@psf.upfronthosting.co.za>
Message-ID: <1316792022.5.0.825525906619.issue13036@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +belopolsky, vinay.sajip

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:00:23 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 23 Sep 2011 16:00:23 +0000
Subject: [issue13036] time format in logging is wrong
In-Reply-To: <1316791297.78.0.299394793338.issue13036@psf.upfronthosting.co.za>
Message-ID: <1316793623.58.0.0022899506811.issue13036@psf.upfronthosting.co.za>


Vinay Sajip  added the comment:

Logging's date/time representation is supposed to conform to ISO 8601.

>From ISO Standard 8601 (Third Edition, dated 2004-12-01):

4.2.2.4 Representations with decimal fraction

If necessary for a particular application a decimal fraction of hour, minute or second may be included. If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of
these, the comma is the preferred sign.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:23:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Sep 2011 16:23:12 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from SSL
	certificates larger than 1024 bits
In-Reply-To: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>
Message-ID: <1316794992.49.0.645157278421.issue13034@psf.upfronthosting.co.za>


Antoine Pitrou  added the comment:

Thanks for reporting. This trivial patch seems to fix it (still needs a test):

diff -r 1b4fae183da3 Modules/_ssl.c
--- a/Modules/_ssl.c	Tue Aug 09 18:48:02 2011 -0500
+++ b/Modules/_ssl.c	Fri Sep 23 18:16:04 2011 +0200
@@ -590,7 +590,7 @@ _get_peer_alt_names (X509 *certificate) 
     /* get a memory buffer */
     biobuf = BIO_new(BIO_s_mem());
 
-    i = 0;
+    i = -1;
     while ((i = X509_get_ext_by_NID(
                     certificate, NID_subject_alt_name, i)) >= 0) {
 

Yay for undocumented OpenSSL APIs with weird semantics.

----------
assignee:  -> pitrou
versions: +Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:29:42 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 23 Sep 2011 16:29:42 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1316795382.92.0.761173081892.issue7732@psf.upfronthosting.co.za>


Barry A. Warsaw  added the comment:

Note that Python 2.6 is also vulnerable to the crash.  While we do not have an exploit, we did get a report on security@ which led to this bug.  I could be convinced to allow the patch to 2.6 on grounds that if the crasher can be exploited, better to apply it now rather than wait.  Certainly if it's easier to apply 2.6 and forward port, I'm fine with that.

Victor's pyfile_fromfile_close.patch looks good to me and fixes the problem with no discernible ill effects.  On IRC, he said he'll apply it to 2.7, 3.2, and 3.3.  I will approve it for 2.6 if he wants to apply it there too.

----------
nosy: +barry
versions: +Python 2.6, Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:30:14 2011
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 23 Sep 2011 16:30:14 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: <1316795415.0.0.830966949868.issue7732@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw :


----------
versions:  -Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:33:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:33:35 +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: <1316795615.48.0.373094481757.issue13031@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
title: [PATCH] small speed-up for tarfile.py when unzipping tarballs -> small speed-up for tarfile.py when unzipping tarballs

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:34:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 23 Sep 2011 16:34:19 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from SSL
	certificates larger than 1024 bits
In-Reply-To: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>
Message-ID: <1316795659.83.0.740122637253.issue13034@psf.upfronthosting.co.za>


Antoine Pitrou  added the comment:

For the record, curl uses the (also undocumented) X509_get_ext_d2i() function instead.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:34:57 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:34:57 +0000
Subject: [issue13033] Support recursivity in shutil.chown
In-Reply-To: <1316769849.87.0.0298236424523.issue13033@psf.upfronthosting.co.za>
Message-ID: <1316795697.01.0.13229201852.issue13033@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Wasn?t there a python-ideas discussion on this?  If someone could find a link and summarize use cases it would be great.

----------
nosy: +eric.araujo
title: recursive chown for shutils -> Support recursivity in shutil.chown
type:  -> feature request
versions: +Python 3.3 -Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:36:56 2011
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 23 Sep 2011 16:36:56 +0000
Subject: [issue13034] Python does not read Alternative Subject Names from SSL
	certificates larger than 1024 bits
In-Reply-To: <1316778793.21.0.229691764484.issue13034@psf.upfronthosting.co.za>
Message-ID: <1316795816.24.0.979709469165.issue13034@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' :


----------
nosy:  -giampaolo.rodola

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:39:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Sep 2011 16:39:53 +0000
Subject: [issue13033] Support recursivity in shutil.chown
In-Reply-To: <1316769849.87.0.0298236424523.issue13033@psf.upfronthosting.co.za>
Message-ID: <1316795993.49.0.0790789551289.issue13033@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

http://mail.python.org/pipermail/python-dev/2011-May/111661.html

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:41:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:41:07 +0000
Subject: [issue13035] "maintainer" value clear the "author" value when
	registering
In-Reply-To: <1316786245.72.0.911460125553.issue13035@psf.upfronthosting.co.za>
Message-ID: <1316796067.16.0.777366335946.issue13035@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

This was already discussed in #962772 (and reported again in #12840 :)

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> when both maintainer and author provided, author discarded

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:42:23 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:42:23 +0000
Subject: [issue13025] mimetypes should read the rule file using UTF-8,
	not the locale encoding
In-Reply-To: <1316560027.85.0.800562759244.issue13025@psf.upfronthosting.co.za>
Message-ID: <1316796143.09.0.115516120218.issue13025@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

+1.  I?ve finally understood that open using the locale is Evil?.  Please use the file from Fedora in a test.

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:49:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:49:58 +0000
Subject: [issue10884] pkgutil EggInfoDistribution requirements for .egg-info
	metadata
In-Reply-To: <1294721787.13.0.963133670506.issue10884@psf.upfronthosting.co.za>
Message-ID: <1316796598.38.0.778124613825.issue10884@psf.upfronthosting.co.za>


Changes by ?ric Araujo :


----------
versions: +3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:50:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:50:46 +0000
Subject: [issue9395] clean does not remove all temp files
In-Reply-To: <1280311771.86.0.556150594835.issue9395@psf.upfronthosting.co.za>
Message-ID: <1316796646.81.0.149670536398.issue9395@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

As I can?t recall what the bug was, closing.

----------
assignee: tarek -> eric.araujo
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:51:44 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:51:44 +0000
Subject: [issue8927] Handle version incompatibilities in dependencies
In-Reply-To: <1275853060.23.0.0333552205181.issue8927@psf.upfronthosting.co.za>
Message-ID: <1316796704.08.0.818626839533.issue8927@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Per Tarek?s pronouncement, closing.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:52:55 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:52:55 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1316796775.17.0.305056843902.issue11751@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Hi Justin, is there any way I can help you move forward with this?  Please tell if you don?t have the time, I can work on completing the patch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:54:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:54:31 +0000
Subject: [issue11921] distutils2 should be able to compile an Extension based
	on the Python implementation
In-Reply-To: <1303750597.71.0.868083563179.issue11921@psf.upfronthosting.co.za>
Message-ID: <1316796871.7.0.782187649643.issue11921@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

One remark: I?m not sure distutils2 *runs* at all on other VMs.  For one example, parsing sys.version to get the Python version relies on an implementation detail of CPython.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:55:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:55:43 +0000
Subject: [issue9306] distutils: raise informative error message when cmd_class
	is None
In-Reply-To: <1279557321.49.0.203770679838.issue9306@psf.upfronthosting.co.za>
Message-ID: <1316796943.68.0.386450467805.issue9306@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Given that it is documented that the argument must be a dictionary, I?m rejecting this.

----------
assignee: tarek -> eric.araujo
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:57:12 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:57:12 +0000
Subject: [issue1092365] Distutils needs a way *not* to install files
Message-ID: <1316797032.99.0.109726299103.issue1092365@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

We don?t have enough information to understand what the bug is and act on it.  Closing as invalid, please reopen if you can clarify.

----------
assignee: tarek -> eric.araujo
dependencies:  -add a resource+files section in setup.cfg
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:58:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 16:58:58 +0000
Subject: [issue13008] syntax error when pasting valid snippet into console
	without empty string after the function def
In-Reply-To: <1316442084.93.0.49113454288.issue13008@psf.upfronthosting.co.za>
Message-ID: <1316797138.74.0.468040874809.issue13008@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

The example is not in our documentation.  I don?t see a bug, closing.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:59:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Sep 2011 16:59:14 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 125887a41a6f by Victor Stinner in branch '3.2':
Issue #7732: Don't open a directory as a file anymore while importing a
http://hg.python.org/cpython/rev/125887a41a6f

New changeset 8c6fea5794b2 by Victor Stinner in branch 'default':
Merge 3.2: Issue #7732: Don't open a directory as a file anymore while
http://hg.python.org/cpython/rev/8c6fea5794b2

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 18:59:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Sep 2011 16:59:50 +0000
Subject: [issue13025] mimetypes should read the rule file using UTF-8,
	not the locale encoding
In-Reply-To: <1316560027.85.0.800562759244.issue13025@psf.upfronthosting.co.za>
Message-ID: <1316797190.58.0.257675954441.issue13025@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 19:11:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 23 Sep 2011 17:11:37 +0000
Subject: [issue13033] Add shutil.chowntree
In-Reply-To: <1316769849.87.0.0298236424523.issue13033@psf.upfronthosting.co.za>
Message-ID: <1316797897.28.0.97735400399.issue13033@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Following Nick?s opinion in the thread, I?d prefer a distinct function.

----------
title: Support recursivity in shutil.chown -> Add shutil.chowntree

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 19:37:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Sep 2011 17:37:23 +0000
Subject: [issue7732] imp.find_module crashes Python if there exists a
	directory named "__init__.py"
In-Reply-To: <1263816426.99.0.320342241745.issue7732@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 0f5b64630fda by Victor Stinner in branch '2.7':
Issue #7732: Fix a crash on importing a module if a directory has the same name
http://hg.python.org/cpython/rev/0f5b64630fda

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 20:32:41 2011
From: report at bugs.python.org (Justin Peel)
Date: Fri, 23 Sep 2011 18:32:41 +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: <1316802761.93.0.00779129495149.issue13031@psf.upfronthosting.co.za>


Justin Peel  added the comment:

poq,

You're quite right. I've added that change too. By the way, four unnecessary extra tuples are no longer being created for each call to this function too because of these changes.

----------
Added file: http://bugs.python.org/file23232/cpython_tarfile2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 20:50:42 2011
From: report at bugs.python.org (Christopher Egner)
Date: Fri, 23 Sep 2011 18:50:42 +0000
Subject: [issue13037] [Regression] socket.error does not inherit from IOError
	as documented
Message-ID: <1316803842.26.0.835338049921.issue13037@psf.upfronthosting.co.za>


New submission from Christopher Egner :

http://docs.python.org/library/socket.html#socket.error
"Changed in version 2.6: socket.error is now a child class of IOError."

However, this is not the case.

$ python
Python 2.7.2 (default, Aug 18 2011, 18:26:35) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> isinstance( socket.error, IOError )
False


Catching IOError in except blocks does not catch socket.error, as one might expect according to the documentation.

----------
components: IO
messages: 144467
nosy: Christopher.Egner
priority: normal
severity: normal
status: open
title: [Regression] socket.error does not inherit from IOError as documented
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 20:52:26 2011
From: report at bugs.python.org (Christopher Egner)
Date: Fri, 23 Sep 2011 18:52:26 +0000
Subject: [issue13037] [Regression] socket.error does not inherit from IOError
	as documented
In-Reply-To: <1316803842.26.0.835338049921.issue13037@psf.upfronthosting.co.za>
Message-ID: <1316803946.09.0.858461949558.issue13037@psf.upfronthosting.co.za>


Christopher Egner  added the comment:

Or I could learn to type...

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 21:13:56 2011
From: report at bugs.python.org (Isaac Salsberg)
Date: Fri, 23 Sep 2011 19:13:56 +0000
Subject: [issue11725] httplib and urllib2 failed ssl connection
	httplib.BadStatusLine
In-Reply-To: <1301550234.98.0.946954388837.issue11725@psf.upfronthosting.co.za>
Message-ID: <1316805236.43.0.327638493919.issue11725@psf.upfronthosting.co.za>


Isaac Salsberg  added the comment:

The output for the command: 

   $ openssl s_client -connect www.finratrace.org:443

was the same on MAC OS X 10.6 and on Red hat 5 (https works fine under linux).

Nevertheless, Ned Deily is right: the bug is on the openssl libs supplied with OS X 10.6 

To solve this issue, I compiled and install OpenSSL 1.0.0d and then link python against this library.

This is the full recipe, step by step:

1. Install openssl. 
   Download the source tar for openssl. I used version openssl-1.0.0d.
   To build 64-bit library, then you have to invoke 
   './Configure darwin64-x86_64-cc' *manually*. Also, to make ssl work in python,
   the openssl libraries must be 'shared libraries'. 
   

   First, Expand the tar file into a temporary directory, I am using /tmp:
   
   $ cd /tmp
   
   $ tar xvzf openssl-1.0.0d.tar.gz
   
   $ cd openssl-1.0.0d
   

   To Build openssl as 64 bits shared libraries and install it:
   
   $ ./Configure darwin64-x86_64-cc shared
   
   $ make 
   
   $ make test # this step is optional
   
   $ sudo make install
   
   
   This will install openssl in the default directory: /usr/local/ssl
   
2. Compile and install python. 
   Download the source tar file. I used version Python 2.7.2
   
   a) Expand the tar file (again into a temporary directory)
   
   b) then go into the Modules folder
   
   c) vi the Setup.dist file, looking for the SSL string (if your are not familiar 
      with vi, you can use any text editor), then uncomment the lines BELLOW the 
      message:
      
               "# Socket module helper for SSL support ..."
               
      Your file must look as follows:
   
   
# Socket module helper for SSL support; you must comment out the other
# socket line above, and possibly edit the SSL variable:
SSL=/usr/local/ssl
_ssl _ssl.c \
        -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
        -L$(SSL)/lib -lssl -lcrypto
 
   

   d) Then using python defaults (installing under /usr/local) execute:
   
   $   ./configure 

   $ make

   $ make test # optional

   $ sudo make install
   

3. To test if python now has ssl support, start python and execute
   these commands (be sure you invoke the new python under /usr/local/bin):

imac:~ isaac$ /usr/local/bin/python
Python 2.7.2 (default, Jun 30 2011, 16:00:06) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import httplib
>>> hasattr(httplib, 'HTTPS')
True
>>> # MUST be  True, otherwise has NO ssl support
... 
>>> import socket
>>> hasattr(socket,'ssl')
True
>>> # MUST be  True, otherwise has NO ssl support
... 
>>> import _ssl
>>> # should NOT give any error when importing
... 
>>> 


That's all, now you have ssl support with python under MAC OS X 10.6

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 21:22:20 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Sep 2011 19:22:20 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316805740.77.0.96680994765.issue13012@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

I agree with Alex. The poorly documented fact that *some* C-coded functions cannot accept arguments identified by keyword rather than position is a bit hole in the function abstraction.
+1 to the patch (and the int to bool change)

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 21:25:34 2011
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Fri, 23 Sep 2011 19:25:34 +0000
Subject: [issue12944] Accept arbitrary files for packaging's upload command
In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>
Message-ID: <1316805934.68.0.905497548227.issue12944@psf.upfronthosting.co.za>


Jean-Paul Calderone  added the comment:

> pysetup run upload -f dist/spam-0.2.tar.gz -f dist/spam-0.2.exe

I'm not sure why it's "run upload" instead of just "upload", but maybe that's the convention in pysetup.  Apart from that, this looks like a vast improvement to me.  As far as not supporting globs goes, I guess I don't really care either way.  If globs aren't supported, then I'll probably end up globbing somewhere else (or constructing the full upload list in some other automated way).  The motivation for the complaint is that too many things require manual interaction; I'm not going to use a new, easily automated utility manually. :)

----------
nosy: +exarkun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 21:36:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Sep 2011 19:36:18 +0000
Subject: [issue13013] _ctypes.c: refleak
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1316806578.31.0.402445669257.issue13013@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

My impression is that plugging refleaks (unlike minor speedups) is a bugfix rather than feature addition, so this and the other issues should be marked for 2.7 and 3.2 also. (I am only changing this one.)

Deprecating a public (but obscure) CAPI function is a separate issue that would only affect 3.3 at the earliest (with a PendingDeprecation or Deprecation warning) and would be in addition to plugging the potential leak in the existing code.

----------
nosy: +terry.reedy
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 21:39:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Sep 2011 19:39:25 +0000
Subject: [issue13023] argparse should allow displaying argument default values
	in addition to setting a formatter class
In-Reply-To: <1316557707.22.0.0719652961871.issue13023@psf.upfronthosting.co.za>
Message-ID: <1316806765.4.0.287668379398.issue13023@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
nosy: +bethard
stage:  -> test needed
versions:  -Python 2.7, Python 3.2, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 21:50:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 23 Sep 2011 19:50:24 +0000
Subject: [issue13030] Be more generic when identifying the Windows main dir in
	installation doc
In-Reply-To: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za>
Message-ID: <1316807424.78.0.299863901397.issue13030@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Windows does not require that executables be on any particular 'drive'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 23:04:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 23 Sep 2011 21:04:00 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316811840.91.0.608672868951.issue13012@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

The attached patch adds 'keepends=' to a few calls and replaces 0/1 with False/True.  The patch can be applied after Mark's patch.  Doing two separate commits is probably better.

----------
Added file: http://bugs.python.org/file23233/issue13012-repl.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 23:04:27 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Fri, 23 Sep 2011 21:04:27 +0000
Subject: [issue13023] argparse should allow displaying argument default values
	in addition to setting a formatter class
In-Reply-To: <1316557707.22.0.0719652961871.issue13023@psf.upfronthosting.co.za>
Message-ID: <1316811867.25.0.0251297073945.issue13023@psf.upfronthosting.co.za>


Zbyszek Szmek  added the comment:

Yeah, adding a formatter instance seems overkill for the usual case of wanting to preserver formatting of the epilog.

----------
nosy: +zbysz

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 23 23:33:36 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Sep 2011 21:33:36 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1316737061.33.0.353797692488.issue10141@psf.upfronthosting.co.za>
Message-ID: 


Charles-Fran?ois Natali  added the comment:

>  - dummy question: why an address is a tuple with 1 string instead of just
> the string? Does AF_UNIX also uses a tuple of 1 string?

I think the reason behind the tuple is future proofing.
Here's the definition of `struct sockaddr_can` in my Linux box's headers:
"""
/**
 * struct sockaddr_can - the sockaddr structure for CAN sockets
 * @can_family:  address family number AF_CAN.
 * @can_ifindex: CAN network interface index.
 * @can_addr:    protocol specific address information
 */
struct sockaddr_can {
    sa_family_t can_family;
    int         can_ifindex;
    union {
        /* transport protocol class address information (e.g. ISOTP) */
        struct { canid_t rx_id, tx_id; } tp;

        /* reserved for future CAN protocols address information */
    } can_addr;
};
"""

By making it a tuple, it will be easier to extend the address that
must be passed to bind(2), should it ever evolve, in a backward
compatible way. Well, that's just a guess (I'm by no means a SocketCAN
expert :-).

>  - the example should also use struct.pack() to create the frame, I don't
> like hardcoded BLOB

Done.

>  - in test_socket: _have_socket_can() interprets permission denied as "CAN
> is not supported", it would be nice to provide a better skip message. Create
> maybe a decorator based?

AFAICT, it shouldn't fail with EPERM or so.
Also, I'm not sure what the message would look like, and it's probably
a bit overkill.

>  - _have_socket_can(): you may move s.close() outside the try block (add
> maybe a "else:" block?) because you may hide a real bug in .close()

Changed that.

>  - data += b'\0' * (8 - can_dlc): I prefer data = data.ljust(8, '\x00')

Hum... Done.

>  - you might add frame encoder/decoder in your example

Done.

>  - if (!strcmp(PyBytes_AS_STRING(interfaceName), "")) hum.....
> PyBytes_GET_SIZE(intername)==0 should be enough

Done.

>  - you truncate the interface name, it can be surprising, I would prefer an
> error (e.g. "interface name too long: 20 characters, the maximum is 10
> characters" ?)

I changed that, and added a test. Also, note that AF_PACKET suffers
from the same problem.
I'll submit a separate patch.

>  - (oh no! don't include horrible configure diff in patches for the bug
> tracker :-p)

Yeah, I usually take care of that, but forgot this time.

> In which Linux version was CAN introduced?
>

Apparently, 2.6.25. Note that we don't need
@support.requires_linux_version() though, it should be catched by
HAVE_SOCKET_CAN (also, you can't use it as a class decorator...).

Here's the updated patch. It passes on all the buildbots (of course,
it's only relevant on Linux).

----------
Added file: http://bugs.python.org/file23234/socketcan_v5.patch

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
diff -r a06ef7ab7321 Doc/library/socket.rst
--- a/Doc/library/socket.rst	Wed Sep 21 22:05:01 2011 +0200
+++ b/Doc/library/socket.rst	Fri Sep 23 23:27:19 2011 +0200
@@ -80,6 +80,11 @@
     If *addr_type* is TIPC_ADDR_ID, then *v1* is the node, *v2* is the
     reference, and *v3* should be set to 0.
 
+- A tuple ``(interface, )`` is used for the :const:`AF_CAN` address family,
+  where *interface* is a string representing a network interface name like
+  ``'can0'``. The network interface name ``''`` can be used to receive packets
+  from all network interfaces of this family.
+
 - Certain other address families (:const:`AF_BLUETOOTH`, :const:`AF_PACKET`)
   support specific representations.
 
@@ -216,6 +221,19 @@
    in the Unix header files are defined; for a few symbols, default values are
    provided.
 
+.. data:: AF_CAN
+          PF_CAN
+          SOL_CAN_*
+          CAN_*
+
+   Many constants of these forms, documented in the Linux documentation, are
+   also defined in the socket module.
+
+   Availability: Linux >= 2.6.25.
+
+   .. versionadded:: 3.3
+
+
 .. data:: SIO_*
           RCVALL_*
 
@@ -387,10 +405,14 @@
 
    Create a new socket using the given address family, socket type and protocol
    number.  The address family should be :const:`AF_INET` (the default),
-   :const:`AF_INET6` or :const:`AF_UNIX`.  The socket type should be
-   :const:`SOCK_STREAM` (the default), :const:`SOCK_DGRAM` or perhaps one of the
-   other ``SOCK_`` constants.  The protocol number is usually zero and may be
-   omitted in that case.
+   :const:`AF_INET6`, :const:`AF_UNIX` or :const:`AF_CAN`. The socket type
+   should be :const:`SOCK_STREAM` (the default), :const:`SOCK_DGRAM`,
+   :const:`SOCK_RAW` or perhaps one of the other ``SOCK_`` constants. The
+   protocol number is usually zero and may be omitted in that case or
+   :const:`CAN_RAW` in case the address family is :const:`AF_CAN`.
+
+   .. versionchanged:: 3.3
+      The AF_CAN family was added.
 
 
 .. function:: socketpair([family[, type[, proto]]])
@@ -1213,7 +1235,7 @@
    print('Received', repr(data))
 
 
-The last example shows how to write a very simple network sniffer with raw
+The next example shows how to write a very simple network sniffer with raw
 sockets on Windows. The example requires administrator privileges to modify
 the interface::
 
@@ -1238,6 +1260,45 @@
    # disabled promiscuous mode
    s.ioctl(socket.SIO_RCVALL, socket.RCVALL_OFF)
 
+The last example shows how to use the socket interface to communicate to a CAN
+network. This example might require special priviledge::
+
+   import socket
+   import struct
+
+
+   # CAN frame packing/unpacking (see `struct can_frame` in )
+
+   can_frame_fmt = "=IB3x8s"
+
+   def build_can_frame(can_id, data):
+       can_dlc = len(data)
+       data = data.ljust(8, b'\x00')
+       return struct.pack(can_frame_fmt, can_id, can_dlc, data)
+
+   def dissect_can_frame(frame):
+       can_id, can_dlc, data = struct.unpack(can_frame_fmt, frame)
+       return (can_id, can_dlc, data[:can_dlc])
+
+
+   # create a raw socket and bind it to the `vcan0` interface
+   s = socket.socket(socket.AF_CAN, socket.SOCK_RAW, socket.CAN_RAW)
+   s.bind(('vcan0',))
+
+   while True:
+       cf, addr = s.recvfrom(16)
+
+       print('Received: can_id=%x, can_dlc=%x, data=%s' % dissect_can_frame(cf))
+
+       try:
+           s.send(cf)
+       except socket.error:
+           print('Error sending CAN frame')
+
+       try:
+           s.send(build_can_frame(0x01, b'\x01\x02\x03'))
+       except socket.error:
+           print('Error sending CAN frame')
 
 Running an example several times with too small delay between executions, could
 lead to this error::
diff -r a06ef7ab7321 Doc/whatsnew/3.3.rst
--- a/Doc/whatsnew/3.3.rst	Wed Sep 21 22:05:01 2011 +0200
+++ b/Doc/whatsnew/3.3.rst	Fri Sep 23 23:27:19 2011 +0200
@@ -246,15 +246,22 @@
 socket
 ------
 
-The :class:`~socket.socket` class now exposes addititonal methods to
-process ancillary data when supported by the underlying platform:
+* The :class:`~socket.socket` class now exposes addititonal methods to process
+  ancillary data when supported by the underlying platform:
 
-* :func:`~socket.socket.sendmsg`
-* :func:`~socket.socket.recvmsg`
-* :func:`~socket.socket.recvmsg_into`
+  * :func:`~socket.socket.sendmsg`
+  * :func:`~socket.socket.recvmsg`
+  * :func:`~socket.socket.recvmsg_into`
 
-(Contributed by David Watson in :issue:`6560`, based on an earlier patch
-by Heiko Wundram)
+  (Contributed by David Watson in :issue:`6560`, based on an earlier patch by
+  Heiko Wundram)
+
+* The :class:`~socket.socket` class now supports the PF_CAN protocol family
+  (http://en.wikipedia.org/wiki/Socketcan), on Linux
+  (http://lwn.net/Articles/253425).
+
+  (Contributed by Matthias Fuchs, updated by Tiago Gon??alves in :issue:`10141`)
+
 
 ssl
 ---
diff -r a06ef7ab7321 Lib/test/test_socket.py
--- a/Lib/test/test_socket.py	Wed Sep 21 22:05:01 2011 +0200
+++ b/Lib/test/test_socket.py	Fri Sep 23 23:27:19 2011 +0200
@@ -21,6 +21,7 @@
 import signal
 import math
 import pickle
+import struct
 try:
     import fcntl
 except ImportError:
@@ -36,6 +37,18 @@
     thread = None
     threading = None
 
+def _have_socket_can():
+    """Check whether CAN sockets are supported on this host."""
+    try:
+        s = socket.socket(socket.PF_CAN, socket.SOCK_RAW, socket.CAN_RAW)
+    except (AttributeError, socket.error, OSError):
+        return False
+    else:
+        s.close()
+    return True
+
+HAVE_SOCKET_CAN = _have_socket_can()
+
 # Size in bytes of the int type
 SIZEOF_INT = array.array("i").itemsize
 
@@ -80,6 +93,24 @@
             with self._cleanup_lock:
                 return super().doCleanups(*args, **kwargs)
 
+class SocketCANTest(unittest.TestCase):
+
+    interface = 'vcan0'
+    bufsize = 128
+
+    def setUp(self):
+        self.s = socket.socket(socket.PF_CAN, socket.SOCK_RAW, socket.CAN_RAW)
+        try:
+            self.s.bind((self.interface,))
+        except socket.error:
+            self.skipTest('network interface `%s` does not exist' %
+                           self.interface)
+            self.s.close()
+
+    def tearDown(self):
+        self.s.close()
+        self.s = None
+
 class ThreadableTest:
     """Threadable Test class
 
@@ -210,6 +241,26 @@
         self.cli = None
         ThreadableTest.clientTearDown(self)
 
+class ThreadedCANSocketTest(SocketCANTest, ThreadableTest):
+
+    def __init__(self, methodName='runTest'):
+        SocketCANTest.__init__(self, methodName=methodName)
+        ThreadableTest.__init__(self)
+
+    def clientSetUp(self):
+        self.cli = socket.socket(socket.PF_CAN, socket.SOCK_RAW, socket.CAN_RAW)
+        try:
+            self.cli.bind((self.interface,))
+        except socket.error:
+            self.skipTest('network interface `%s` does not exist' %
+                           self.interface)
+            self.cli.close()
+
+    def clientTearDown(self):
+        self.cli.close()
+        self.cli = None
+        ThreadableTest.clientTearDown(self)
+
 class SocketConnectedTest(ThreadedTCPSocketTest):
     """Socket tests for client-server connection.
 
@@ -1072,6 +1123,112 @@
         srv.close()
 
 
+ at unittest.skipUnless(HAVE_SOCKET_CAN, 'SocketCan required for this test.')
+class BasicCANTest(unittest.TestCase):
+
+    def testCrucialConstants(self):
+        socket.AF_CAN
+        socket.PF_CAN
+        socket.CAN_RAW
+
+    def testCreateSocket(self):
+        with socket.socket(socket.PF_CAN, socket.SOCK_RAW, socket.CAN_RAW) as s:
+            pass
+
+    def testBindAny(self):
+        with socket.socket(socket.PF_CAN, socket.SOCK_RAW, socket.CAN_RAW) as s:
+            s.bind(('', ))
+
+    def testTooLongInterfaceName(self):
+        # most systems limit IFNAMSIZ to 16, take 1024 to be sure
+        with socket.socket(socket.PF_CAN, socket.SOCK_RAW, socket.CAN_RAW) as s:
+            self.assertRaisesRegexp(socket.error, 'interface name too long',
+                                    s.bind, ('x' * 1024,))
+
+    @unittest.skipUnless(hasattr(socket, "CAN_RAW_LOOPBACK"),
+                         'socket.CAN_RAW_LOOPBACK required for this test.')
+    def testLoopback(self):
+        with socket.socket(socket.PF_CAN, socket.SOCK_RAW, socket.CAN_RAW) as s:
+            for loopback in (0, 1):
+                s.setsockopt(socket.SOL_CAN_RAW, socket.CAN_RAW_LOOPBACK,
+                             loopback)
+                self.assertEqual(loopback,
+                    s.getsockopt(socket.SOL_CAN_RAW, socket.CAN_RAW_LOOPBACK))
+
+    @unittest.skipUnless(hasattr(socket, "CAN_RAW_FILTER"),
+                         'socket.CAN_RAW_FILTER required for this test.')
+    def testFilter(self):
+        can_id, can_mask = 0x200, 0x700
+        can_filter = struct.pack("=II", can_id, can_mask)
+        with socket.socket(socket.PF_CAN, socket.SOCK_RAW, socket.CAN_RAW) as s:
+            s.setsockopt(socket.SOL_CAN_RAW, socket.CAN_RAW_FILTER, can_filter)
+            self.assertEqual(can_filter,
+                    s.getsockopt(socket.SOL_CAN_RAW, socket.CAN_RAW_FILTER, 8))
+
+
+ at unittest.skipUnless(HAVE_SOCKET_CAN, 'SocketCan required for this test.')
+ at unittest.skipUnless(thread, 'Threading required for this test.')
+class CANTest(ThreadedCANSocketTest):
+
+    """The CAN frame structure is defined in :
+
+    struct can_frame {
+        canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
+        __u8    can_dlc; /* data length code: 0 .. 8 */
+        __u8    data[8] __attribute__((aligned(8)));
+    };
+    """
+    can_frame_fmt = "=IB3x8s"
+
+    def __init__(self, methodName='runTest'):
+        ThreadedCANSocketTest.__init__(self, methodName=methodName)
+
+    @classmethod
+    def build_can_frame(cls, can_id, data):
+        """Build a CAN frame."""
+        can_dlc = len(data)
+        data = data.ljust(8, b'\x00')
+        return struct.pack(cls.can_frame_fmt, can_id, can_dlc, data)
+
+    @classmethod
+    def dissect_can_frame(cls, frame):
+        """Dissect a CAN frame."""
+        can_id, can_dlc, data = struct.unpack(cls.can_frame_fmt, frame)
+        return (can_id, can_dlc, data[:can_dlc])
+
+    def testSendFrame(self):
+        cf, addr = self.s.recvfrom(self.bufsize)
+        self.assertEqual(self.cf, cf)
+        self.assertEqual(addr[0], self.interface)
+        self.assertEqual(addr[1], socket.AF_CAN)
+
+    def _testSendFrame(self):
+        self.cf = self.build_can_frame(0x00, b'\x01\x02\x03\x04\x05')
+        self.cli.send(self.cf)
+
+    def testSendMaxFrame(self):
+        cf, addr = self.s.recvfrom(self.bufsize)
+        self.assertEqual(self.cf, cf)
+
+    def _testSendMaxFrame(self):
+        self.cf = self.build_can_frame(0x00, b'\x07' * 8)
+        self.cli.send(self.cf)
+
+    def testSendMultiFrames(self):
+        cf, addr = self.s.recvfrom(self.bufsize)
+        self.assertEqual(self.cf1, cf)
+
+        cf, addr = self.s.recvfrom(self.bufsize)
+        self.assertEqual(self.cf2, cf)
+
+    def _testSendMultiFrames(self):
+        self.cf1 = self.build_can_frame(0x07, b'\x44\x33\x22\x11')
+        self.cli.send(self.cf1)
+
+        self.cf2 = self.build_can_frame(0x12, b'\x99\x22\x33')
+        self.cli.send(self.cf2)
+
+
 @unittest.skipUnless(thread, 'Threading required for this test.')
 class BasicTCPTest(SocketConnectedTest):
 
@@ -4185,6 +4342,7 @@
     if isTipcAvailable():
         tests.append(TIPCTest)
         tests.append(TIPCThreadableTest)
+    tests.extend([BasicCANTest, CANTest])
     tests.extend([
         CmsgMacroTests,
         SendmsgUDPTest,
diff -r a06ef7ab7321 Misc/ACKS
--- a/Misc/ACKS	Wed Sep 21 22:05:01 2011 +0200
+++ b/Misc/ACKS	Fri Sep 23 23:27:19 2011 +0200
@@ -318,6 +318,7 @@
 Martin Franklin
 Robin Friedrich
 Ivan Frohne
+Matthias Fuchs
 Jim Fulton
 Tadayoshi Funaba
 Gyro Funch
@@ -353,6 +354,7 @@
 Yannick Gingras
 Christoph Gohlke
 Tim Golden
+Tiago Gon??alves
 Chris Gonnerman
 David Goodger
 Hans de Graaff
diff -r a06ef7ab7321 Modules/socketmodule.c
--- a/Modules/socketmodule.c	Wed Sep 21 22:05:01 2011 +0200
+++ b/Modules/socketmodule.c	Fri Sep 23 23:27:19 2011 +0200
@@ -1220,6 +1220,25 @@
     }
 #endif
 
+#ifdef HAVE_LINUX_CAN_H
+    case AF_CAN:
+    {
+        struct sockaddr_can *a = (struct sockaddr_can *)addr;
+        char *ifname = "";
+        struct ifreq ifr;
+        /* need to look up interface name given index */
+        if (a->can_ifindex) {
+            ifr.ifr_ifindex = a->can_ifindex;
+            if (ioctl(sockfd, SIOCGIFNAME, &ifr) == 0)
+                ifname = ifr.ifr_name;
+        }
+
+        return Py_BuildValue("O&h", PyUnicode_DecodeFSDefault,
+                                    ifname,
+                                    a->can_family);
+    }
+#endif
+
     /* More cases here... */
 
     default:
@@ -1587,6 +1606,51 @@
     }
 #endif
 
+#ifdef HAVE_LINUX_CAN_H
+    case AF_CAN:
+        switch (s->sock_proto) {
+        case CAN_RAW:
+        {
+            struct sockaddr_can* addr;
+            PyObject *interfaceName;
+            struct ifreq ifr;
+            addr = (struct sockaddr_can *)addr_ret;
+            Py_ssize_t len;
+
+            if (!PyArg_ParseTuple(args, "O&", PyUnicode_FSConverter, &interfaceName))
+                return 0;
+
+            len = PyBytes_GET_SIZE(interfaceName);
+
+            if (len == 0) {
+                ifr.ifr_ifindex = 0;
+            } else if (len < sizeof(ifr.ifr_name)) {
+                strcpy(ifr.ifr_name, PyBytes_AS_STRING(interfaceName));
+                if (ioctl(s->sock_fd, SIOCGIFINDEX, &ifr) < 0) {
+                    s->errorhandler();
+                    Py_DECREF(interfaceName);
+                    return 0;
+                }
+            } else {
+                PyErr_SetString(socket_error,
+                                "AF_CAN interface name too long");
+                Py_DECREF(interfaceName);
+                return 0;
+            }
+
+            addr->can_family = AF_CAN;
+            addr->can_ifindex = ifr.ifr_ifindex;
+
+            *len_ret = sizeof(*addr);
+            Py_DECREF(interfaceName);
+            return 1;
+        }
+        default:
+            PyErr_SetString(socket_error, "getsockaddrarg: unsupported CAN protocol");
+            return 0;
+        }
+#endif
+
     /* More cases here... */
 
     default:
@@ -1680,6 +1744,14 @@
     }
 #endif
 
+#ifdef HAVE_LINUX_CAN_H
+    case AF_CAN:
+    {
+        *len_ret = sizeof (struct sockaddr_can);
+        return 1;
+    }
+#endif
+
     /* More cases here... */
 
     default:
@@ -5533,6 +5605,15 @@
     PyModule_AddStringConstant(m, "BDADDR_LOCAL", "00:00:00:FF:FF:FF");
 #endif
 
+#ifdef AF_CAN
+    /* Controller Area Network */
+    PyModule_AddIntConstant(m, "AF_CAN", AF_CAN);
+#endif
+#ifdef PF_CAN
+    /* Controller Area Network */
+    PyModule_AddIntConstant(m, "PF_CAN", PF_CAN);
+#endif
+
 #ifdef AF_PACKET
     PyModule_AddIntMacro(m, AF_PACKET);
 #endif
@@ -5803,6 +5884,28 @@
 #else
     PyModule_AddIntConstant(m, "SOL_UDP", 17);
 #endif
+#ifdef SOL_CAN_BASE
+    PyModule_AddIntConstant(m, "SOL_CAN_BASE", SOL_CAN_BASE);
+#endif
+#ifdef SOL_CAN_RAW
+    PyModule_AddIntConstant(m, "SOL_CAN_RAW", SOL_CAN_RAW);
+    PyModule_AddIntConstant(m, "CAN_RAW", CAN_RAW);
+#endif
+#ifdef HAVE_LINUX_CAN_H
+    PyModule_AddIntConstant(m, "CAN_EFF_FLAG", CAN_EFF_FLAG);
+    PyModule_AddIntConstant(m, "CAN_RTR_FLAG", CAN_RTR_FLAG);
+    PyModule_AddIntConstant(m, "CAN_ERR_FLAG", CAN_ERR_FLAG);
+
+    PyModule_AddIntConstant(m, "CAN_SFF_MASK", CAN_SFF_MASK);
+    PyModule_AddIntConstant(m, "CAN_EFF_MASK", CAN_EFF_MASK);
+    PyModule_AddIntConstant(m, "CAN_ERR_MASK", CAN_ERR_MASK);
+#endif
+#ifdef HAVE_LINUX_CAN_RAW_H
+    PyModule_AddIntConstant(m, "CAN_RAW_FILTER", CAN_RAW_FILTER);
+    PyModule_AddIntConstant(m, "CAN_RAW_ERR_FILTER", CAN_RAW_ERR_FILTER);
+    PyModule_AddIntConstant(m, "CAN_RAW_LOOPBACK", CAN_RAW_LOOPBACK);
+    PyModule_AddIntConstant(m, "CAN_RAW_RECV_OWN_MSGS", CAN_RAW_RECV_OWN_MSGS);
+#endif
 #ifdef  IPPROTO_IP
     PyModule_AddIntConstant(m, "IPPROTO_IP", IPPROTO_IP);
 #else
diff -r a06ef7ab7321 Modules/socketmodule.h
--- a/Modules/socketmodule.h	Wed Sep 21 22:05:01 2011 +0200
+++ b/Modules/socketmodule.h	Fri Sep 23 23:27:19 2011 +0200
@@ -72,6 +72,14 @@
 # include 
 #endif
 
+#ifdef HAVE_LINUX_CAN_H
+#include 
+#endif
+
+#ifdef HAVE_LINUX_CAN_RAW_H
+#include 
+#endif
+
 #ifndef Py__SOCKET_H
 #define Py__SOCKET_H
 #ifdef __cplusplus
@@ -126,6 +134,9 @@
 #ifdef HAVE_NETPACKET_PACKET_H
     struct sockaddr_ll ll;
 #endif
+#ifdef HAVE_LINUX_CAN_H
+    struct sockaddr_can can;
+#endif
 } sock_addr_t;
 
 /* The object holding a socket.  It holds some extra information,
diff -r a06ef7ab7321 configure.in
--- a/configure.in	Wed Sep 21 22:05:01 2011 +0200
+++ b/configure.in	Fri Sep 23 23:27:19 2011 +0200
@@ -1354,6 +1354,13 @@
 #endif
 ])
 
+# On Linux, can.h and can/raw.h require sys/socket.h
+AC_CHECK_HEADERS(linux/can.h linux/can/raw.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 -r a06ef7ab7321 pyconfig.h.in
--- a/pyconfig.h.in	Wed Sep 21 22:05:01 2011 +0200
+++ b/pyconfig.h.in	Fri Sep 23 23:27:19 2011 +0200
@@ -467,6 +467,12 @@
 /* Define to 1 if you have the `linkat' function. */
 #undef HAVE_LINKAT
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_LINUX_CAN_H
+
+/* 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_NETLINK_H
 

From report at bugs.python.org  Fri Sep 23 23:35:17 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 23 Sep 2011 21:35:17 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1316813717.22.0.695341269352.issue10141@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


Removed file: http://bugs.python.org/file23225/socketcan_v4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 00:14:32 2011
From: report at bugs.python.org (Mitch Frazier)
Date: Fri, 23 Sep 2011 22:14:32 +0000
Subject: [issue13038] distutils windows installer
	STATUS_INVALID_CRUNTIME_PARAMETER (C0000417) exception when
	python dir is read only
Message-ID: <1316816072.59.0.865990615621.issue13038@psf.upfronthosting.co.za>


New submission from Mitch Frazier :

Distutils built installers will fail on Windows with a run-time exception of STATUS_INVALID_CRUNTIME_PARAMETER, error-code: C0000417 if the python installation directory (e.g. C:\Python27) is read-only for the user running the installer.  I've experienced this with the pyside and pywin32 installers on Windows XP.

Using procmon I discovered that the installer fails when it tries to create the installation log file in the python install directory.  That led me to look at the directory which is when I discovered that it was read only for my user account.  It's read-only because the Python installer was run as Administrator and the other installers are being run from my user account.

Changing the directory to read-only for my account allows the installer to run without problem.

Perhaps the installer could check for this and provide a friendlier response.

----------
assignee: tarek
components: Distutils
messages: 144477
nosy: eric.araujo, mitchfrazier, tarek
priority: normal
severity: normal
status: open
title: distutils windows installer STATUS_INVALID_CRUNTIME_PARAMETER (C0000417) exception when python dir is read only
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 00:26:59 2011
From: report at bugs.python.org (etuardu)
Date: Fri, 23 Sep 2011 22:26:59 +0000
Subject: [issue13039] IDLE3 editor: shell-like behaviour on line starting with
	">>>"
Message-ID: <1316816819.73.0.347712729805.issue13039@psf.upfronthosting.co.za>


New submission from etuardu :

In the editor window, if a line starts with the shell prompt string ">>>", backspacing is inhibited when reaching the first space, just like in the shell window.

OS: Linux 2.6.38-11-generic-pae #50-Ubuntu i386 GNU/Linux
Python version: 3.2
IDLE version: 3.2
Tk version: 8.5

----------
components: IDLE
messages: 144478
nosy: etuardu
priority: normal
severity: normal
status: open
title: IDLE3 editor: shell-like behaviour on line starting with ">>>"
type: behavior
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 00:33:32 2011
From: report at bugs.python.org (Nadeem Vawda)
Date: Fri, 23 Sep 2011 22:33:32 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1316817212.72.0.539380221519.issue1625@psf.upfronthosting.co.za>


Nadeem Vawda  added the comment:

Ozan: Thanks for taking the time to backport the patch. Unfortunately, as
?ric said, 2.7 is in maintenance mode, so it no longer receives new features.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 01:15:28 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 23 Sep 2011 23:15:28 +0000
Subject: [issue13008] syntax error when pasting valid snippet into console
	without empty string after the function def
In-Reply-To: <1316442084.93.0.49113454288.issue13008@psf.upfronthosting.co.za>
Message-ID: <1316819728.57.0.953831739913.issue13008@psf.upfronthosting.co.za>


anatoly techtonik  added the comment:

I understand your desire to keep the tracker clean, but I'd like that another person closes this issue. Maybe he will have another opinion.

----------
resolution: invalid -> 
status: closed -> languishing

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 03:27:50 2011
From: report at bugs.python.org (Justin Love)
Date: Sat, 24 Sep 2011 01:27:50 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1316827670.35.0.719480729126.issue11751@psf.upfronthosting.co.za>


Justin Love  added the comment:

Sorry, it's been sitting at the bottom of my starred list for months, the prospect of reloading context always making it a little less attractive than something else.  I turned out I had to update to even have 'packaging'

Error was caused by an actual change in behavior - I was testing the argument-check by providing an action with no argument.  The new code assumes a single 'word' is a filename, and translates it to include, eg. 'include include' which then passes the parse.

I modified the Manifest to test against the list of actions, since this makes it harder for users to make a mistake.  Of course we could just drop the test, or only check multi-argument actions.

----------
Added file: http://bugs.python.org/file23235/packaging-manifest_v2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 04:20:58 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 24 Sep 2011 02:20:58 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316830858.86.0.819835023986.issue13012@psf.upfronthosting.co.za>


Meador Inge  added the comment:

> Doing two separate commits is probably better.

Out of curiosity, what is typically the convention on that?  The 
devguide seems to suggest one changeset per issue:

"""
Just please make sure that you generate a single, condensed patch rather than a series of several changesets.
"""

I think for this case two patches is better.  In general, I am OK with
the git-style series and hg-style patchbombs, but the devguide seems
to say otherwise.  Hmmm, that makes me wonder if we can patchbomb the
tracker :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 04:36:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Sep 2011 02:36:45 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316831805.14.0.86000360703.issue13012@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

One changeset per issue is a general goal. So is the ability to review patches. Sometime people forget to add a News or Acks entry and have to followup with an addendum. (Mark's patch still lack that, for instance.) Sometimes a patch is so large that a reviewer asks or requires splitting. In this case, each patch is large enough and touches enough files (up to 10 I think) that two is plausible. What would not be appreciated by either a reviewer or commit-list recipients would be one patch file per patched file. That would be a patch bomb indeed ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 08:55:33 2011
From: report at bugs.python.org (Benjamin West)
Date: Sat, 24 Sep 2011 06:55:33 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1316847333.75.0.956948517947.issue9253@psf.upfronthosting.co.za>


Benjamin West  added the comment:

I spent some time looking at this, as I was interested in
using this pattern to simulate what git and hg do.  I
considered a few modifications and then found this bug.  I
think the default keyword passed to
_SubParsersAction.__init__ makes sense.

I started on a patch, that looks promising, but I'm having
trouble getting the regexp right.

Here's a changeset higlighting where I think the
problematic regexp is:
https://bitbucket.org/bewest/argparse/changeset/938e1e91ddd0

https://gist.github.com/1202975#file_test_opt_subcommand.py
Is the meager little test I put together.

----------
hgrepos: +68
nosy: +Benjamin.West

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:00:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Sep 2011 08:00:37 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset b378864d8ff3 by Mark Dickinson in branch '3.2':
Issue #12973: Fix itertools bug caused by signed integer overflow.  Thanks Stefan Krah.
http://hg.python.org/cpython/rev/b378864d8ff3

New changeset 18eec56bcf29 by Mark Dickinson in branch 'default':
Merge #12973 itertools fix.
http://hg.python.org/cpython/rev/18eec56bcf29

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:02:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Sep 2011 08:02:36 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 5a1cb8506cea by Mark Dickinson in branch '2.7':
Backport issue #12973 itertools fix from 3.x.
http://hg.python.org/cpython/rev/5a1cb8506cea

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:04:08 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Sep 2011 08:04:08 +0000
Subject: [issue12973] int_pow() implementation is incorrect
In-Reply-To: <1315943210.06.0.258464290509.issue12973@psf.upfronthosting.co.za>
Message-ID: <1316851448.96.0.438321336026.issue12973@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Okay, all fixed here.  Let's add any further signed overflow issues to the issue #1621 discussion.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:15:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Sep 2011 08:15:45 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 0b2660384d4e by Mark Dickinson in branch 'default':
Issue #13012: Allow 'keepends' to be passed as a keyword argument in str.splitlines, bytes.splitlines and bytearray.splitlines.
http://hg.python.org/cpython/rev/0b2660384d4e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:17:56 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Sep 2011 08:17:56 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316852276.28.0.429939054854.issue13012@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Thanks for the reviews.

Applied the first patch, plus Misc/NEWS entry, and minus the change to Lib/collections/__init__.py;  I think that change belongs more with the second patch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:24:55 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Sep 2011 08:24:55 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1316852695.47.0.679618741217.issue1621@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Resetting versions.

----------
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:26:27 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Sep 2011 08:26:27 +0000
Subject: [issue13008] syntax error when pasting valid snippet into console
	without empty string after the function def
In-Reply-To: <1316442084.93.0.49113454288.issue13008@psf.upfronthosting.co.za>
Message-ID: <1316852787.08.0.491594722615.issue13008@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Closing as per python-dev discussion.

----------
nosy: +georg.brandl
status: languishing -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:27:19 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Sep 2011 08:27:19 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1316852839.46.0.665855729121.issue1621@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Clang has an -ftrapv option that seems to be less buggy and more complete than gcc's.  Compiling and running the test suite with that option enabled looks like a good way to catch a lot of these signed overflows.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:29:39 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Sep 2011 08:29:39 +0000
Subject: [issue13013] _ctypes.c: refleak
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1316852979.83.0.0859275722225.issue13013@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

I vote for plugging the refleak and keeping the function non-static.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:31:28 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Sep 2011 08:31:28 +0000
Subject: [issue13019] bytearrayobject.c: refleak
In-Reply-To: <1316530611.41.0.519397979389.issue13019@psf.upfronthosting.co.za>
Message-ID: <1316853088.57.0.810258620657.issue13019@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Both hunks look reasonable.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 10:32:57 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 24 Sep 2011 08:32:57 +0000
Subject: [issue13015] _collectionsmodule.c: refleak
In-Reply-To: <1316530406.22.0.00922720094034.issue13015@psf.upfronthosting.co.za>
Message-ID: <1316853177.72.0.682812288159.issue13015@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Looks correct but awkwardly indented.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 12:44:06 2011
From: report at bugs.python.org (Richard86)
Date: Sat, 24 Sep 2011 10:44:06 +0000
Subject: [issue13040] call to tkinter.messagebox.showinfo hangs the script
Message-ID: <1316861046.74.0.26633284396.issue13040@psf.upfronthosting.co.za>


New submission from Richard86 :

Call to tkinter.messagebox.showinfo("Test", "test") makes the script hang in Windows 7 with Python 3.2.2 with Timer(2, methodname, ()).start().

----------
components: Tkinter, Windows
files: test1.py
messages: 144496
nosy: Richard86
priority: normal
severity: normal
status: open
title: call to tkinter.messagebox.showinfo hangs the script
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file23236/test1.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 12:52:28 2011
From: report at bugs.python.org (Richard86)
Date: Sat, 24 Sep 2011 10:52:28 +0000
Subject: [issue13040] call to tkinter.messagebox.showinfo hangs the script
	after timer
In-Reply-To: <1316861046.74.0.26633284396.issue13040@psf.upfronthosting.co.za>
Message-ID: <1316861548.8.0.310596892776.issue13040@psf.upfronthosting.co.za>


Changes by Richard86 :


----------
title: call to tkinter.messagebox.showinfo hangs the script -> call to tkinter.messagebox.showinfo hangs the script after timer

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 12:52:31 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Sep 2011 10:52:31 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316861551.62.0.563425870072.issue13012@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Ezio's patch looks fine to me, though as Meador points out in the Rietveld review, there are a couple of omissions that could be fixed.

Personally, I'm not so convinced of the value of upgrading all the existing uses of splitlines to use 'keepends';  I just wanted to be able to do this in *new* code. :-)  I guess I'm +0 on the int -> bool changes (replacing .splitlines(1) with .splitlines(True)), and -0 on adding the extra 'splitlines' keywords throughout existing source.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 15:21:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Sep 2011 13:21:46 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316870506.72.0.242743969638.issue13012@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

> Out of curiosity, what is typically the convention on that?

In theory every issue should be about a single problem and therefore have a single patch to fix it.  Sometimes a secondary "problem" that is not strictly related to the first one arises, for example when a cleanup is necessary before applying the patch, or when a new feature is added and a few places get changed to use it.  In these cases is not worth opening another issue, so both the patches are attached to the same issue, but committed separately because they address two different "problems".

> Sometime people forget to add a News or Acks entry and have to
> followup with an addendum. (Mark's patch still lack that, for 
> instance.)

Avoiding to include the NEWS entry in patches is common, because the file gets updated often and it will most likely cause conflicts.  `make patchcheck` remind us to add it -- assuming you don't forget to use it.

> Ezio's patch looks fine to me, though as Meador points out in the 
> Rietveld review, there are a couple of omissions that could be fixed.

Adding keepends there would have made the line too long, required some splitting and probably made the code less readable overall, so I prefer to keep it out.

> Personally, I'm not so convinced of the value of upgrading all the
> existing uses of splitlines to use 'keepends'; I just wanted to be
> able to do this in *new* code. :-)

If we can make old code more readable too and we already have a patch to do it, why not?  (one instance also had the comment # True == keep line ends)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 16:48:04 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 24 Sep 2011 14:48:04 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1316875684.43.0.111591467199.issue1621@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

Do we consider these overflows as bugs in Python, or do we declare that we expect compilers to "do the right thing" for the bug fix releases (i.e. care only about the default branch). I'd personally vote for the latter - i.e. don't apply any of the resulting changes to the maintenance releases, and target the issue only for 3.3.

Realistically, a compiler that invokes truly undefined behavior for signed overflow has no chance of getting 3.2 compiled correctly, and we have no chance of finding all these issues within the lifetime of 3.2.

If that is agreed, I would start committing changes that fix the issues Mark already discussed in 2009 (unless he wants to commit them himself).

----------
priority: high -> normal

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 17:54:53 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Sat, 24 Sep 2011 15:54:53 +0000
Subject: [issue13023] argparse should allow displaying argument default values
	in addition to setting a formatter class
In-Reply-To: <1316557707.22.0.0719652961871.issue13023@psf.upfronthosting.co.za>
Message-ID: <1316879693.55.0.544824367157.issue13023@psf.upfronthosting.co.za>


Denilson Figueiredo de S?  added the comment:

> adding a formatter instance seems overkill for the usual case of
> wanting to preserve formatting of the epilog.

Related bug (look at it before (re)designing the API):
http://bugs.python.org/issue12806

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 17:57:05 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 24 Sep 2011 15:57:05 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1316879825.64.0.0286461968626.issue1621@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> don't apply any of the resulting changes to the maintenance releases,
> and target the issue only for 3.3.

That sounds fine to me, though if we find more instances of signed overflow that actually trigger test failures in the maintenance branches (like the int_pow one) on mainstream compilers, we might want to fix those there too, on a case-by-case basis.

To get started, here's a patch that fixes occurrences of signed overflow in the bytes, str and tuple hash methods, and also in set lookups.  It also fixes a related and minor casting inconsistency in dictobject.c  (which was using (size_t)hash & mask in some places, and just 'hash & mask' in others).  These are the minimal changes required to get Python to build completely using Clang with '-ftrapv' turned on and --with-pydebug enabled.

----------
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23237/issue1621_hashes_and_sets.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 18:01:47 2011
From: report at bugs.python.org (Luke Plant)
Date: Sat, 24 Sep 2011 16:01:47 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1316880107.43.0.855383311975.issue2193@psf.upfronthosting.co.za>


Luke Plant  added the comment:

David,

Thanks again for the time on this. Can I push to get the patches included, or is there work that still needs to be done on the patches now that the idea is accepted in principle? I did experiment with a few approaches to implement, and it seemed like the most sensible.

Thanks,

Luke

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 19:19:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Sep 2011 17:19:43 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 698fa089ce70 by Mark Dickinson in branch 'default':
Issue #1621: Fix undefined behaviour in bytes.__hash__, str.__hash__, tuple.__hash__, frozenset.__hash__ and set indexing operations.
http://hg.python.org/cpython/rev/698fa089ce70

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 20:04:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Sep 2011 18:04:03 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 95ee0df1e746 by Charles-Fran?ois Natali in branch 'default':
Issue #12981: rewrite multiprocessing_{sendfd,recvfd} in Python.
http://hg.python.org/cpython/rev/95ee0df1e746

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 20:12:00 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Sep 2011 18:12:00 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 5e456e1a9e8c by Mark Dickinson in branch 'default':
Issue #1621: Fix undefined behaviour from signed overflow in get_integer (stringlib/formatter.h)
http://hg.python.org/cpython/rev/5e456e1a9e8c

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 22:21:45 2011
From: report at bugs.python.org (Richard86)
Date: Sat, 24 Sep 2011 20:21:45 +0000
Subject: [issue13040] call to tkinter.messagebox.showinfo hangs the script on
	timer on Windows
In-Reply-To: <1316861046.74.0.26633284396.issue13040@psf.upfronthosting.co.za>
Message-ID: <1316895705.46.0.756633679951.issue13040@psf.upfronthosting.co.za>


Changes by Richard86 :


----------
title: call to tkinter.messagebox.showinfo hangs the script after timer -> call to tkinter.messagebox.showinfo hangs the script on timer on Windows

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 22:22:34 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Sep 2011 20:22:34 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1316895754.81.0.985168508426.issue13012@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Given that someone is willing to write a patch and someone else to review it, I am +1 on changing 0/1 to False/True anywhere appropriate in the stdlib. Ditto for using a new feature. The "# True == keep line ends" comment illustrates why the original patch is a good idea.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 23:37:28 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 24 Sep 2011 21:37:28 +0000
Subject: [issue12353] argparse cannot handle empty arguments
In-Reply-To: <1308325206.77.0.428682614263.issue12353@psf.upfronthosting.co.za>
Message-ID: <1316900248.59.0.0607778705411.issue12353@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


----------
nosy: +zbysz

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 24 23:42:10 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 24 Sep 2011 21:42:10 +0000
Subject: [issue4256] argparse: provide a simple way to get a programmatically
	useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1316900530.72.0.85026981264.issue4256@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek :


----------
nosy: +zbysz

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 00:07:19 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 24 Sep 2011 22:07:19 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
Message-ID: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek :

COLUMNS is a shell variable (updated whenever the window size
changes), that usually isn't exported to programs. Therefore checking
for COLUMNS in sys.environ will not work in the majority of cases. The
proper check is to use the TIOCGWINSZ ioctl on stdout.
    
Why COLUMNS is not exported? Because it can change during the lifetime
of a program. Therefore it is better to use the dynamic ioctl.

----------
components: Library (Lib)
files: patch1.diff
keywords: patch
messages: 144507
nosy: zbysz
priority: normal
severity: normal
status: open
title: argparse: terminal width is not detected properly
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23238/patch1.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 00:07:20 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 24 Sep 2011 22:07:20 +0000
Subject: [issue13042] argparse: terminal width is not detected properly
Message-ID: <1316902040.77.0.692202253798.issue13042@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek :

COLUMNS is a shell variable (updated whenever the window size
changes), that usually isn't exported to programs. Therefore checking
for COLUMNS in sys.environ will not work in the majority of cases. The
proper check is to use the TIOCGWINSZ ioctl on stdout.
    
Why COLUMNS is not exported? Because it can change during the lifetime
of a program. Therefore it is better to use the dynamic ioctl.

----------
components: Library (Lib)
files: patch1.diff
keywords: patch
messages: 144508
nosy: zbysz
priority: normal
severity: normal
status: open
title: argparse: terminal width is not detected properly
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file23239/patch1.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 00:12:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Sep 2011 22:12:15 +0000
Subject: [issue13042] argparse: terminal width is not detected properly
In-Reply-To: <1316902040.77.0.692202253798.issue13042@psf.upfronthosting.co.za>
Message-ID: <1316902335.15.0.858624764813.issue13042@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> argparse: terminal width is not detected properly

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 00:13:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Sep 2011 22:13:22 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1316902402.64.0.334133586424.issue13041@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +bethard

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 00:25:53 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 24 Sep 2011 22:25:53 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1316903153.39.0.68148746098.issue2193@psf.upfronthosting.co.za>


R. David Murray  added the comment:

I'm flat out right now on other projects.  But if no one else gets around to doing a final review and commit I should be able to get to it by the end of October.  If I don't, please ping me by posting here again.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 00:34:24 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 24 Sep 2011 22:34:24 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1316903664.31.0.1067416489.issue12806@psf.upfronthosting.co.za>


Zbyszek Szmek  added the comment:

This is a great idea! I think that this formatter is much more useful than the default one. I was pretty surprised the first time I added a multi-paragraph epilog to a program and it got all jumbled into a single line. I would vote to make this (or a variant, see the comments below) the default formatter for the description and epilog fields.

Notes on the interface (a bit of bike-shedding :)):

Continuation backslashes are best avoided. Other means, like parenthesis in case of expressions, are encouraged to avoid adding backslashes. Continuation symbols also interfere with paragraph reflowing in text editors.
Using backslash continuations wouldn't be necessary, if the rules were slightly changed to be more LaTeX like: just line-wrap paragraphs, and paragraphs are separated by a blank line. This would make it impossible to have two line-wrapped parts not separated by an empty line, but I think that this is less common and less important than having a "natural" representation of paragraphs.

In current implementation, lines that are not wrapped (IIUC) are those which start with *, +, >, ., or ). This seems error prone. Maybe it would be better to just detect lines which are indented at least one space in comparison to the first line. This would work for examples and lists:
"""
this is a text that is subject to line-wrapping
  and this line not
and this line would again be wrapped:
  - and a line, not merged with the one above or below
  - and a second point, not merged with the one above
"""

Review of argparse_formatter.py:
> list_match = re.match(r'( *)(([*-+>]+|\w+\)|\w+\.) +)',line)
 A dash '-' has special meaning in brackets:
  [*-+>] means (characters in range from '*' to '+', or '>').
 Because star and plus are adjacent in ASCII, this is equivalent to
  [*+>]
 but quite unclear.

>  if(list_match):
Parenthesis unnecessary.

> lines = list()
Why not just 'lines = []'?

One a side note: due to #13041 the terminal width is normally stuck
at 80 chars.

----------
nosy: +zbysz

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 00:48:09 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 24 Sep 2011 22:48:09 +0000
Subject: [issue13042] argparse: terminal width is not detected properly
In-Reply-To: <1316902040.77.0.692202253798.issue13042@psf.upfronthosting.co.za>
Message-ID: <1316904489.45.0.0173551819563.issue13042@psf.upfronthosting.co.za>


Zbyszek Szmek  added the comment:

Hm, I have somehow submitted the same tex ttwwiiccee. Sorry about that.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 00:52:08 2011
From: report at bugs.python.org (Benjamin West)
Date: Sat, 24 Sep 2011 22:52:08 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1316904728.18.0.570116004569.issue9253@psf.upfronthosting.co.za>


Benjamin West  added the comment:

https://github.com/bewest/argparse/tree/bewest
https://bitbucket.org/bewest/argparse/changesets

I think this does the right thing.

----------
hgrepos: +69

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 01:50:07 2011
From: report at bugs.python.org (Graylin Kim)
Date: Sat, 24 Sep 2011 23:50:07 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1316908207.48.0.255883874112.issue12806@psf.upfronthosting.co.za>


Graylin Kim  added the comment:

I fully support taking blank line based line-wrapping approach and agree with Zbyszek's suggested indentation approach as well. I am not sure why they didn't occur to me at the time but they are certainly a more effective and widely adopted approaches to the structured text problem.

I suppose here is where I should volunteer to update the patch file...


Re: Bike-shedding

>dash '-' has special meaning in brackets:

Good catch, I had intended on '-' being a valid list item character. It clearly needs to be escaped. Not that it would matter given your proposed alternative.

>>  if(list_match):
>Parenthesis unnecessary.

In my defense I have the sadistic pleasure of coding in PHP where they are necessary for 8 hours a day for my day job. I can only apologize profusely for my offense and beg for forgiveness :)

>> lines = list()
>Why not just 'lines = []'?

Not to get off topic, but I happen to like list() and dict() instead of [] and {} for empty collections. If there are non-religious reasons for avoiding this practice I'll consider it. I don't want to invoke a holy war here, just wondering if there are practical reasons.

>One a side note: due to #13041 the terminal width is normally stuck
at 80 chars.

Not a good reason to remove the flexibility from the implementation I don't think.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 02:41:52 2011
From: report at bugs.python.org (Tigger Level-5)
Date: Sun, 25 Sep 2011 00:41:52 +0000
Subject: [issue13033] Add shutil.chowntree
In-Reply-To: <1316769849.87.0.0298236424523.issue13033@psf.upfronthosting.co.za>
Message-ID: <1316911312.71.0.141329688004.issue13033@psf.upfronthosting.co.za>


Tigger Level-5  added the comment:

First time posting, how about something like this. Just added a os.walk method to do the chown recursively.

----------
nosy: +Tigger.Level-5
Added file: http://bugs.python.org/file23240/temp.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 03:54:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 25 Sep 2011 01:54:20 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1316915660.39.0.903059245475.issue11751@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> Sorry, it's been sitting at the bottom of my starred list for months,
> the prospect of reloading context always making it a little less
> attractive than something else.
I understand that very well :)

> Error was caused by an actual change in behavior
Ah, good, I had missed that change.  I?ll just adapt the test to check that one-word == include.

I think I won?t add the Manifest._actions attribute as in your patch; it does not cost much to have the list once in manifest and another time in test_manifest.

The only change I?ll make (or maybe you?d like to do it?) before committing is to add a test to make sure the line marked with ?this cannot happen? really cannot happen.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 03:59:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 25 Sep 2011 01:59:31 +0000
Subject: [issue12944] Accept arbitrary files for packaging's upload command
In-Reply-To: <1315549969.41.0.856641810932.issue12944@psf.upfronthosting.co.za>
Message-ID: <1316915971.69.0.0852931185442.issue12944@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

> I'm not sure why it's "run upload" instead of just "upload"
pysetup has actions and commands.  Actions do stuff on the Python installation: ?pysetup metadata foobar? prints metadata, ?pysetup remove foobar? uninstalls, ?pysetup install foobar? fetches from PyPI and installs, etc.  Commands are like distutils commands, they work on a project in a source directory; for namespacing reasons, they are subitems of the run command.  (I?m working on documenting that.)

> Apart from that, this looks like a vast improvement to me.
Good!  Adding the easy keyword, as it?s not hard to implement if one understands how upload works, or someone could add tests without much difficulty.  I may get to it myself shortly, it will make a nice change from bug fixes and improve my karma :)

----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 04:40:21 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Sun, 25 Sep 2011 02:40:21 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1316918421.39.0.172532151214.issue13041@psf.upfronthosting.co.za>


Changes by Denilson Figueiredo de S? :


----------
nosy: +denilsonsa

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 04:50:51 2011
From: report at bugs.python.org (Phillip Feldman)
Date: Sun, 25 Sep 2011 02:50:51 +0000
Subject: [issue12961] itertools: unlabelled balls in boxes
In-Reply-To: <1315771311.11.0.00644993310332.issue12961@psf.upfronthosting.co.za>
Message-ID: <1316919051.84.0.358467576766.issue12961@psf.upfronthosting.co.za>


Phillip Feldman  added the comment:

Raymond-

I think that you may have overestimated the complexity of the problem.  In about 5 hours, I coded, debugged, and documented a set of generator functions to solve the general formulation (including box limits) for three occupancy problems:

- unlabeled balls in labeled boxes,
- unlabeled_balls_in_unlabeled_boxes, and
- labeled_balls_in_unlabeled_boxes.

(I will add labeled balls in labeled boxes, although this case is less interesting).

On the other hand, I agree with your comment that the general need for these has not yet been demonstrated.  I will post my code to PyPI and we'll see what happens.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 05:10:04 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Sun, 25 Sep 2011 03:10:04 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1316920204.56.0.639972223995.issue12806@psf.upfronthosting.co.za>


Denilson Figueiredo de S?  added the comment:

> Good catch, I had intended on '-' being a valid list item character.
> It clearly needs to be escaped.

Either escaped, or it can be the first character in the set.

> but I happen to like list() and dict() instead of [] and {} for
> empty collections.

I just checked PEP 8, and unfortunately this is not mentioned in there. Maybe you could open a new issue (or post in a mailing list) to ask about which style should be recommended, and then add the conclusion to PEP 8.

> One a side note: due to #13041 the terminal width is normally stuck
> at 80 chars.

Getting the console width (and height) is something so common that I believe there should be a built-in Python library for doing that. And it's also something hard to do correctly (get COLUMNS variable, or use ioctl, or trap SIGWINCH signal, or do something completely different on non-unix, or fallback to hardcoded default or user-supplied default)

What's more, since built-in argparse module needs this feature, that is another good reason to get it inside standard Python library. It has been proposed before, but the issue was closed: #8408

Anyway, although I believe this is important, it is off-topic in this issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 09:08:28 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 07:08:28 +0000
Subject: [issue13043] Unexpected behavior of imp.find_module(".") with a
	package present in sys.path and also referenced in a .pth file
Message-ID: <1316934508.79.0.173574445416.issue13043@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis :

# python3.3 -c 'import imp; print(imp.find_module("."))'
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named '.'
# mkdir /usr/lib64/python3.3/site-packages/something
# touch /usr/lib64/python3.3/site-packages/something/__init__.py
# echo something > /usr/lib64/python3.3/site-packages/something.pth
# python3.3 -c 'import imp; print(imp.find_module("."))'
(None, '/usr/lib64/python3.3/site-packages/something/.', ('', '', 5))

----------
messages: 144519
nosy: Arfrever
priority: normal
severity: normal
status: open
title: Unexpected behavior of imp.find_module(".") with a package present in sys.path and also referenced in a .pth file
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 09:56:42 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 07:56:42 +0000
Subject: [issue13043] Unexpected behavior of imp.find_module(".") with a
	package present in sys.path and also referenced in a .pth file
In-Reply-To: <1316934508.79.0.173574445416.issue13043@psf.upfronthosting.co.za>
Message-ID: <1316937402.03.0.412652528263.issue13043@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis  added the comment:

After thinking more about it, it's probably expected.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 12:02:01 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sun, 25 Sep 2011 10:02:01 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1316944921.17.0.317010996449.issue13041@psf.upfronthosting.co.za>


Zbyszek Szmek  added the comment:

I see that adding a separate module was proposed in issue #8408, which was rejected/closed. I don't have the rights to reopen, so I'll continue here.

#8408 was proposing a new module, which seems a bit overkill, since the implementation for unix and windows is about 20 lines.

I'm attaching a second version of the patch which works on windows (tested with python3.2.2 on XP). Thanks to techtonik for pointing to a windows imlementation.

----------
Added file: http://bugs.python.org/file23241/patch1.1.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 12:07:24 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sun, 25 Sep 2011 10:07:24 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1316908207.48.0.255883874112.issue12806@psf.upfronthosting.co.za>
Message-ID: <4E7EFD53.1010205@in.waw.pl>


Zbyszek Szmek  added the comment:

On 09/25/2011 01:50 AM, Graylin Kim wrote:
>
> Graylin Kim  added the comment:
>
> I fully support taking blank line based line-wrapping approach and agree with Zbyszek's suggested indentation approach as well. I am not sure why they didn't occur to me at the time but they are certainly a more effective and widely adopted approaches to the structured text problem.
>
> I suppose here is where I should volunteer to update the patch file...
>
>
> Re: Bike-shedding
>
>> dash '-' has special meaning in brackets:
>
> Good catch, I had intended on '-' being a valid list item character. It clearly needs to be escaped. Not that it would matter given your proposed alternative.
>
>>>   if(list_match):
>> Parenthesis unnecessary.
>
> In my defense I have the sadistic pleasure of coding in PHP where they are necessary for 8 hours a day for my day job. I can only apologize profusely for my offense and beg for forgiveness :)
>

:)

>>> lines = list()
>> Why not just 'lines = []'?
>
> Not to get off topic, but I happen to like list() and dict() instead of [] and {} for empty collections. If there are non-religious reasons for avoiding this practice I'll consider it. I don't want to invoke a holy war here, just wondering if there are practical reasons.

In general brevity is good, but I agree that this is just a style 
question, and not very important here.

This wasn't my intention, I was only saying that due to this bug the 
wrapping uses fixed width, but I'm hoping that #13041 will be 
successfully resolved.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 12:13:24 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 25 Sep 2011 10:13:24 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316945604.01.0.281257005334.issue12981@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


----------
dependencies:  -_XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED usage on Solaris
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 12:13:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 25 Sep 2011 10:13:34 +0000
Subject: [issue12981] rewrite multiprocessing (senfd|recvfd) in Python
In-Reply-To: <1316029884.26.0.0837911327487.issue12981@psf.upfronthosting.co.za>
Message-ID: <1316945614.57.0.494619808554.issue12981@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 16:18:43 2011
From: report at bugs.python.org (=?utf-8?q?Denilson_Figueiredo_de_S=C3=A1?=)
Date: Sun, 25 Sep 2011 14:18:43 +0000
Subject: [issue13041] argparse: terminal width is not detected properly
In-Reply-To: <1316902039.33.0.744560309521.issue13041@psf.upfronthosting.co.za>
Message-ID: <1316960323.5.0.0470223814517.issue13041@psf.upfronthosting.co.za>


Denilson Figueiredo de S?  added the comment:

> #8408 was proposing a new module, which seems a bit overkill

If a module seems overkill, then maybe add this useful function to os module. Don't leave it private to argparse module. Maybe something along these lines:

    >>> import os
    >>> print(os.get_terminal_size())
    (80, 25)

Why do I believe a module could be better? Because I'd also like some way to detect when the terminal size has changed (without probing it all the time).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 16:35:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Sep 2011 14:35:02 +0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 3fb9464f9b02 by Mark Dickinson in branch 'default':
Issue #1621: Fix undefined behaviour from signed overflow in datetime module hashes, array and list iterations, and get_integer (stringlib/string_format.h)
http://hg.python.org/cpython/rev/3fb9464f9b02

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 18:36:22 2011
From: report at bugs.python.org (akl)
Date: Sun, 25 Sep 2011 16:36:22 +0000
Subject: [issue13044] pdb throws AttributeError at end of debugging session
Message-ID: <1316968582.76.0.94343164649.issue13044@psf.upfronthosting.co.za>


New submission from akl :

Using Python 2.7.1 on OpenBSD-current and 2.7.2 on Arch Linux, pdb throws a (harmless, it appears) exception at the end of a debugging session.  This does not happen for me using Python 2.5 or 2.6 or 3.2.

Console Session (on linux):

$ python2 --version
Python 2.7.2

$ python2 debug.py 
> /tmp/debug.py(4)()
-> a = 1
(Pdb) n
> /tmp/debug.py(5)()
-> b = 2
(Pdb) n
> /tmp/debug.py(6)()
-> sum = a + b
(Pdb) n
--Return--
> /tmp/debug.py(6)()->None
-> sum = a + b
(Pdb) n
Exception AttributeError: "'NoneType' object has no attribute 'path'" in  ignore

----------
components: Library (Lib)
files: debug.py
messages: 144525
nosy: akl
priority: normal
severity: normal
status: open
title: pdb throws AttributeError at end of debugging session
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file23242/debug.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 19:12:20 2011
From: report at bugs.python.org (Artyom Gavrichenkov)
Date: Sun, 25 Sep 2011 17:12:20 +0000
Subject: [issue13045] [PATCH] socket.getsockopt may require custom buffer
	contents
Message-ID: <1316970740.88.0.976956666008.issue13045@psf.upfronthosting.co.za>


New submission from Artyom Gavrichenkov :

Currently the Python implementation of socket.getsockopt allows only option name, level name and buffer size as its arguments. However, IEEE Standard 1003.1-2008 allows one further argument -- an actual buffer to modify at the kernel level. POSIX does not prohibit the kernel from reading this buffer before modification, and the contents of the buffer may be used together with option and level names to specify an exact socket option to return.

In fact, this is how some applications already work, ipset (http://ipset.netfilter.org/) being a noticeable example.

The patch, written against Python 3.2 and aiming at providing this functionality, is attached. It may also apply to previous Python versions, though it's not tested against anything except Python 3.2.

----------
components: Extension Modules
files: getsockopt_buffer_input.patch
keywords: patch
messages: 144526
nosy: Artyom.Gavrichenkov
priority: normal
severity: normal
status: open
title: [PATCH] socket.getsockopt may require custom buffer contents
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file23243/getsockopt_buffer_input.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 21:03:51 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 19:03:51 +0000
Subject: [issue13046] imp.find_module() should not find unimportable modules
Message-ID: <1316977431.22.0.335405032353.issue13046@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis :

imp.find_module() can find files, which cannot be imported. I suggest that imp.find_module() raise an exception in such cases.

$ cd /tmp
$ touch .something.py
$ python3.3
Python 3.3.0a0 (default:5e456e1a9e8c+, Sep 25 2011, 18:57:23) 
[GCC 4.5.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import .something
  File "", line 1
    import .something
           ^
SyntaxError: invalid syntax
>>> module = __import__(".something")
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Empty module name
>>> import imp
>>> file, pathname, description = imp.find_module(".something")
>>> file, pathname, description
(<_io.TextIOWrapper name=4 mode='U' encoding='utf-8'>, '.something.py', ('.py', 'U', 1))

----------
components: Interpreter Core
messages: 144527
nosy: Arfrever
priority: normal
severity: normal
status: open
title: imp.find_module() should not find unimportable modules
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 21:35:03 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 19:35:03 +0000
Subject: [issue10588] imp.find_module raises unexpected SyntaxError
In-Reply-To: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>
Message-ID: <1316979303.18.0.542322751706.issue10588@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis :


----------
nosy: +Arfrever

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 21:35:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Sep 2011 19:35:25 +0000
Subject: [issue13046] imp.find_module() should not find unimportable modules
In-Reply-To: <1316977431.22.0.335405032353.issue13046@psf.upfronthosting.co.za>
Message-ID: <1316979325.37.0.259072668301.issue13046@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

I'm not sure they should be disallowed.  We have ways to set variables and attributes with "invalid" names (like '.something') too.  OTOH __import__ fails to import the .something due to the special meaning of the dot, but it imports things like foo-bar.py just fine.
Also I'm assuming that with "unimportable" you just mean "with a name that is not a valid identifier" and not other modules that can't be imported for other reasons.

----------
nosy: +brett.cannon, ezio.melotti, ncoghlan
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 22:03:05 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 20:03:05 +0000
Subject: [issue13046] imp.find_module() should not find unimportable modules
In-Reply-To: <1316977431.22.0.335405032353.issue13046@psf.upfronthosting.co.za>
Message-ID: <1316980985.88.0.25115477253.issue13046@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis  added the comment:

I mean files, which cannot be imported even by __import__().
I know that __import__() can import foo-bar.py.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 22:19:27 2011
From: report at bugs.python.org (Justin Love)
Date: Sun, 25 Sep 2011 20:19:27 +0000
Subject: [issue11751] Increase distutils.filelist / packaging.manifest test
	coverage
In-Reply-To: <1301857658.21.0.439945432416.issue11751@psf.upfronthosting.co.za>
Message-ID: <1316981967.7.0.610225698764.issue11751@psf.upfronthosting.co.za>


Justin Love  added the comment:

Incorporated some formatting suggestions.

Removed _actions.  Just as well, as I accidentally left in the 'blarg' bogus action ;^)

Added a test for implicit-include.

Whether 'this cannot happen' can happen depends on the output of _parse_template_line.  If you wanted to remove the catch-all and still have test backup, you'd probably have to restort to some form of fuzz-testing _process_template_line.  As the code stands now it could be removed.  I left it alone as insurance against future changes.

----------
Added file: http://bugs.python.org/file23244/packaging-manifest_v3.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 22:25:45 2011
From: report at bugs.python.org (Artyom Gavrichenkov)
Date: Sun, 25 Sep 2011 20:25:45 +0000
Subject: [issue13045] socket.getsockopt may require custom buffer contents
In-Reply-To: <1316970740.88.0.976956666008.issue13045@psf.upfronthosting.co.za>
Message-ID: <1316982345.22.0.276649574931.issue13045@psf.upfronthosting.co.za>


Changes by Artyom Gavrichenkov :


----------
title: [PATCH] socket.getsockopt may require custom buffer contents -> socket.getsockopt may require custom buffer contents

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 22:49:58 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 20:49:58 +0000
Subject: [issue13047] imp.find_module("") and imp.find_module(".")
Message-ID: <1316983798.48.0.694425302693.issue13047@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis :

It's undocumented that imp.find_module("") and imp.find_module(".") try to find __init__.py.

There is also a small difference in behavior between them.
sys.path by default contains "" as the first element, which is sufficient for imp.find_module("."), but not for imp.find_module(""):

$ mkdir /tmp/imp_tests
$ cd /tmp/imp_tests
$ touch __init__.py
$ python3.3 -c 'import imp, sys; print(repr(sys.path[0])); print(imp.find_module("."))'
''
(None, '.', ('', '', 5))
$ python3.3 -c 'import imp, sys; print(repr(sys.path[0])); print(imp.find_module(""))'
''
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named ''

If sys.path contains path (e.g. "." or absolute path) to directory with __init__.py file, then imp.find_module("") will succeed:

$ PYTHONPATH="." python3.3 -c 'import imp, sys; print(repr(sys.path[0:2])); print(imp.find_module("."))'
['', '/tmp/imp_tests']
(None, '.', ('', '', 5))
$ PYTHONPATH="." python3.3 -c 'import imp, sys; print(repr(sys.path[0:2])); print(imp.find_module(""))'
['', '/tmp/imp_tests']
(None, '/tmp/imp_tests/', ('', '', 5))
$ python3.3 -c 'import imp, sys; sys.path.insert(1, "."); print(repr(sys.path[0:2])); print(imp.find_module("."))'
['', '.']
(None, '.', ('', '', 5))
$ python3.3 -c 'import imp, sys; sys.path.insert(1, "."); print(repr(sys.path[0:2])); print(imp.find_module(""))'
['', '.']
(None, './', ('', '', 5))

I think that imp.find_module(".") and imp.find_module("") should have the same behavior, and this behavior should be documented.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 144531
nosy: Arfrever, docs at python
priority: normal
severity: normal
status: open
title: imp.find_module("") and imp.find_module(".")
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 22:54:09 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Sep 2011 20:54:09 +0000
Subject: [issue13047] imp.find_module("") and imp.find_module(".")
In-Reply-To: <1316983798.48.0.694425302693.issue13047@psf.upfronthosting.co.za>
Message-ID: <1316984049.74.0.0484863839049.issue13047@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +brett.cannon, ezio.melotti, ncoghlan

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 23:05:33 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 21:05:33 +0000
Subject: [issue13048] Handling of paths in first argument of imp.find_module()
Message-ID: <1316984733.77.0.135974751185.issue13048@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis :

It's undocumented that imp.find_module() supports paths with "/" as the first argument:

$ mkdir /tmp/imp_tests
$ cd /tmp/imp_tests
$ mkdir a
$ touch a/b.py
$ python3.3 -c 'import imp; print(imp.find_module("a/b"))'
(<_io.TextIOWrapper name=4 mode='U' encoding='utf-8'>, 'a/b.py', ('.py', 'U', 1))

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 144532
nosy: Arfrever, brett.cannon, docs at python, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: Handling of paths in first argument of imp.find_module()
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 23:14:07 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 25 Sep 2011 21:14:07 +0000
Subject: [issue11676] Improve imp.load_module and submodules doc
In-Reply-To: <1301089227.12.0.157951103986.issue11676@psf.upfronthosting.co.za>
Message-ID: <1316985247.55.0.541855740914.issue11676@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis :


----------
nosy: +Arfrever

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 23:18:02 2011
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sun, 25 Sep 2011 21:18:02 +0000
Subject: [issue12806] argparse: Hybrid help text formatter
In-Reply-To: <1313973978.37.0.422477813424.issue12806@psf.upfronthosting.co.za>
Message-ID: <1316985482.08.0.699264664404.issue12806@psf.upfronthosting.co.za>


Zbyszek Szmek  added the comment:

[I now see that roundup ate half of my reply. I have no idea why,
 because the e-mail is formatted correctly. Maybe I'll have more
 luck this time, but since there's no preview, I must try to see.]

On 09/25/2011 01:50 AM, Graylin Kim wrote:
>>>   if(list_match):
>> Parenthesis unnecessary.
>
> In my defense I have the sadistic pleasure of coding in PHP where
> they are necessary for 8 hours a day for my day job. I can only
> apologize profusely for my offense and beg for forgiveness

:)

>>> lines = list()
>> Why not just 'lines = []'?
>
> Not to get off topic, but I happen to like list() and dict() instead
> of [] and {} for empty collections. If there are non-religious
> reasons for avoiding this practice I'll consider it. I don't want to
> invoke a holy war here, just wondering if there are practical reasons.

In general brevity is good, but I agree that this is just a style question, and not very important here.

>> One a side note: due to #13041 the terminal width is normally stuck
> at 80 chars.
> Not a good reason to remove the flexibility from the implementation
> I don't think.
This wasn't my intention, I was only saying that due to this bug the wrapping uses fixed width, but I'm hoping that #13041 will be successfully resolved.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 23:26:51 2011
From: report at bugs.python.org (Richard86)
Date: Sun, 25 Sep 2011 21:26:51 +0000
Subject: [issue13040] call to tkinter.messagebox.showinfo hangs the script on
	timer on Windows
In-Reply-To: <1316861046.74.0.26633284396.issue13040@psf.upfronthosting.co.za>
Message-ID: <1316986011.91.0.706282469678.issue13040@psf.upfronthosting.co.za>


Changes by Richard86 :


----------
nosy: +gpolo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 25 23:48:48 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 25 Sep 2011 21:48:48 +0000
Subject: [issue13044] pdb throws AttributeError at end of debugging session
In-Reply-To: <1316968582.76.0.94343164649.issue13044@psf.upfronthosting.co.za>
Message-ID: <1316987328.71.0.931782052838.issue13044@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc  added the comment:

By modifying a bit the Python intepreter, I got this traceback:

Traceback (most recent call last):
  File "/home/amauryfa/python/cpython2.7/Lib/_weakrefset.py", line 38, in _remove
    def _remove(item, selfref=ref(self)):
  File "/home/amauryfa/python/cpython2.7/Lib/bdb.py", line 50, in trace_dispatch
    return self.dispatch_call(frame, arg)
  File "/home/amauryfa/python/cpython2.7/Lib/bdb.py", line 76, in dispatch_call
    if not (self.stop_here(frame) or self.break_anywhere(frame)):
  File "/home/amauryfa/python/cpython2.7/Lib/bdb.py", line 147, in break_anywhere
    return self.canonic(frame.f_code.co_filename) in self.breaks
  File "/home/amauryfa/python/cpython2.7/Lib/bdb.py", line 33, in canonic
    canonic = os.path.abspath(filename)
AttributeError: 'NoneType' object has no attribute 'path'

Here is the gdb stack when the error is printed:

#0  PyErr_Print () at Python/pythonrun.c:1040
#1  0x0000000000480c1d in handle_callback (object=) at Objects/weakrefobject.c:884
#2  PyObject_ClearWeakRefs (object=) at Objects/weakrefobject.c:966
#3  0x0000000000423a37 in class_dealloc (op=0x7ffff7f68890) at Objects/classobject.c:193
#4  0x000000000046a7ed in tupledealloc (op=0x7ffff7f89410) at Objects/tupleobject.c:220
#5  0x0000000000423afb in class_dealloc (op=0x7ffff7f7ed50) at Objects/classobject.c:194
#6  0x00000000004270cb in instance_dealloc (inst=0x7ffff7f8a518) at Objects/classobject.c:670
#7  0x000000000044de47 in insertdict (mp=0x7f7800, key='environ', hash=-5347984860299468300, value=None)
    at Objects/dictobject.c:530
#8  0x0000000000450287 in PyDict_SetItem (op=
    {'WTERMSIG': None, 'lseek': None, 'EX_IOERR': None, 'EX_NOHOST': None, 'seteuid': None, 'pathsep': None, 'execle': None, 'major': None, '_Environ': None, 'fstatvfs': None, 'uname': None, 'kill': None, 'urandom': None, 'execlp': None, 'getegid': None, 'getresgid': None, 'EX_OSFILE': None, 'umask': None, 'linesep': None, 'fchmod': None, 'lchown': None, 'setgid': None, 'tmpnam': None, 'devnull': None, 'EX_NOINPUT': None, 'makedev': None, 'fstat': None, 'getlogin': None, 'O_CREAT': None, 'dup2': None, 'read': None, '__file__': None, 'getppid': None, 'fchown': None, 'getloadavg': None, 'WIFSTOPPED': None, 'getpgrp': None, '_spawnvef': None, 'TMP_MAX': None, 'utime': None, 'execl': None, 'F_OK': None, '_make_stat_result': None, 'name': None, 'fsync': None, 'tcsetpgrp': None, 'statvfs': None, 'setreuid': None, 'remove': None, 'setegid': None, 'P_NOWAITO': None, '_copy_reg': None, 'execv': None, 'spawnv': None, 'spawnvpe': None, 'EX_OSERR': None, 'ttyname': None, 'pardir': None, 'tempnam': None, 'tmpfile': None, 'sep...(truncated), key='environ', value=None) at Objects/dictobject.c:775
#9  0x000000000045268e in _PyModule_Clear (m=) at Objects/moduleobject.c:138
#10 0x00000000004bfa17 in PyImport_Cleanup () at Python/import.c:498
#11 0x00000000004cd9ef in Py_Finalize () at Python/pythonrun.c:447

So, when the interpreter shuts down, the debugger is still active...
Python 3 does not seem to be affected by this issue. And indeed if I make UserDict a new-style class, I don't reproduce the error on 2.7 either.

A possible fix is to reset the trace function to None in Py_Finalize.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 03:01:03 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 26 Sep 2011 01:01:03 +0000
Subject: [issue13013] _ctypes.c: refleak
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1316998863.49.0.252642482979.issue13013@psf.upfronthosting.co.za>


Meador Inge  added the comment:

OK, I will just fix the ref leak in 2.7, 3.2, and 3.3.  This is a pretty low-risk fix (as I mentioned before, I can't see how the error condition is even executed).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 04:08:59 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 26 Sep 2011 02:08:59 +0000
Subject: [issue13044] pdb throws AttributeError at end of debugging session
In-Reply-To: <1316968582.76.0.94343164649.issue13044@psf.upfronthosting.co.za>
Message-ID: <1317002939.97.0.444055983934.issue13044@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
nosy: +meador.inge

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 15:15:27 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 26 Sep 2011 13:15:27 +0000
Subject: [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1317042927.14.0.688940688176.issue7133@psf.upfronthosting.co.za>


Senthil Kumaran  added the comment:

Keith, was your python compiled with ssl? Any extra information to reproduce this can help. (Download 2.7.2 from python.org, do a ./configure;make and verify if this can bug can be reproduced).

----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 15:15:45 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 26 Sep 2011 13:15:45 +0000
Subject: [issue13024] cgitb uses stdout encoding
In-Reply-To: <1316559729.08.0.724028142076.issue13024@psf.upfronthosting.co.za>
Message-ID: <1317042945.53.0.703404037873.issue13024@psf.upfronthosting.co.za>


Changes by Senthil Kumaran :


----------
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 15:16:05 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 26 Sep 2011 13:16:05 +0000
Subject: [issue12966] cookielib.LWPCookieJar breaks on cookie values with a
	newline
In-Reply-To: <1315854880.61.0.95908383563.issue12966@psf.upfronthosting.co.za>
Message-ID: <1317042965.27.0.0275556999944.issue12966@psf.upfronthosting.co.za>


Changes by Senthil Kumaran :


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 15:30:45 2011
From: report at bugs.python.org (Keith Briggs)
Date: Mon, 26 Sep 2011 13:30:45 +0000
Subject: [issue7133] test_ssl failure
In-Reply-To: <1255560072.28.0.0342134369979.issue7133@psf.upfronthosting.co.za>
Message-ID: <1317043845.36.0.859037619496.issue7133@psf.upfronthosting.co.za>


Keith Briggs  added the comment:

Senthil: thanks for the reply.   That's how I did build python 2.7.2 anyway.   But I can't see anything about SSL in the generated config files.    However, on another system (Fedora 15 with python 2.7.1), I don't get the problem.
In case it's useful, I was trying to run the recipe http://code.activestate.com/recipes/573444-threaded-documenting-xml-rpc-server-over-https/?c=13559 when this crash happened.   Is there something in that recipe which is not compatible with the current python modules?  

Keith

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 15:40:34 2011
From: report at bugs.python.org (Paulie Pena)
Date: Mon, 26 Sep 2011 13:40:34 +0000
Subject: [issue12966] cookielib.LWPCookieJar breaks on cookie values with a
	newline
In-Reply-To: <1315854880.61.0.95908383563.issue12966@psf.upfronthosting.co.za>
Message-ID: <1317044434.1.0.946456603157.issue12966@psf.upfronthosting.co.za>


Paulie Pena  added the comment:

RFC 2109's Section 4.1 "Syntax: General" (http://www.ietf.org/rfc/rfc2109.txt) states that the attributes and values should be tokens, which the define as "(informally, a sequence of non-special, non-white space characters) from the HTTP/1.1 specification [RFC 2068]."

The one site that had sent me a cookie with a newline in a value is no longer doing that, but of course, there could be other sites with buggy code for sending cookies.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 16:31:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 26 Sep 2011 14:31:07 +0000
Subject: [issue13013] _ctypes.c: refleak
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1317047467.21.0.8084888352.issue13013@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

If the function is public I guess that some external module might use it, and possibly pass a wrong argument that triggers the leak.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 16:41:06 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 26 Sep 2011 14:41:06 +0000
Subject: [issue13013] _ctypes.c: refleak
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1317048066.76.0.765785685372.issue13013@psf.upfronthosting.co.za>


Meador Inge  added the comment:

> If the function is public I guess that some external module
> might use it

Agreed; That is the only case I could deduce as well, which I hinted at 
in msg144397.  So, I will leave the error check and keep the function
public for now.

I will commit the ref leak fix today.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 18:26:30 2011
From: report at bugs.python.org (Christoph Schindler)
Date: Mon, 26 Sep 2011 16:26:30 +0000
Subject: [issue2683] subprocess.Popen.communicate takes bytes, not str
In-Reply-To: <1209063440.61.0.967116488341.issue2683@psf.upfronthosting.co.za>
Message-ID: <1317054390.37.0.206690766632.issue2683@psf.upfronthosting.co.za>


Christoph Schindler  added the comment:

The doc string refers to "string" instead of "byte string" as well.

----------
nosy: +hop
Added file: http://bugs.python.org/file23245/subprocess_doc_string.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 19:40:33 2011
From: report at bugs.python.org (Carl Meyer)
Date: Mon, 26 Sep 2011 17:40:33 +0000
Subject: [issue13049] distutils2 should not allow packages
Message-ID: <1317058833.63.0.231790801143.issue13049@psf.upfronthosting.co.za>


New submission from Carl Meyer :

As discussed at http://groups.google.com/group/the-fellowship-of-the-packaging/browse_frm/thread/3b7a8ddd307d1020 , distutils2 should not allow a distribution to install files into a top-level package that is already installed from a different distribution.

----------
assignee: tarek
components: Distutils2
messages: 144542
nosy: alexis, carljm, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2 should not allow packages
type: behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 19:41:33 2011
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 26 Sep 2011 17:41:33 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1317058893.75.0.178382666936.issue11457@psf.upfronthosting.co.za>


Larry Hastings  added the comment:

Mark Dickinson wrote:
> I think this could work.

"could"?  Oh ye of little faith!

Attached is a patch against a nice fresh trunk (2b47f0146639) that adds Decimal attributes "ctime", "mtime", and "atime" to the object returned by os.stat().  The functions that consume mtime and atime values (os.utime, os.futimes, os.lutimes, os.futimesat) now also accept Decimal objects for those values.  My smoke-test using os.stat and os.utime works fine, and CPython passes the unit test suite with only the expected skippage.  However, the patch isn't ready to be checked in; I didn't update the documentation, for one.  I'd be happy to post the patch on Rietveld--just ask.

The implementation was complicated by the fact that Decimal is pure Python ;)  I had to do some "build the ship in a bottle" work.  Also, it's possible for os.stat to be called before the Python interpreter is really ready.  So internally it has to gracefully handle an import error on "decimal".

Along the way I noticed some minor resource leaks, both in os.utime:
  * for Windows, if passed a Unicode filename it would leak "obwpath".
  * for non-Windows, if the call to the C function utime() failed
    it would leak "opath".
I fixed these, along with a spelling error.

I also cleared up some sillyness.  When built on non-Windows, extract_time etc. used nine places of precision; on Windows it only used six.  Windows only calls extract_time for os.utime--the other functions that use extract_time aren't available on Windows.  And in the Windows implementation of os.utime, it multiplied the time it got from extract_time by a thousand!  This might even be throwing away some precision--not sure.  Definitely it was cruft.

However, modifying this meant changing the Windows code, which I can't test!  So I'm not 100% certain it's right.


Finally the bad news: this patch contributes a major performance regression on os.stat.  On my laptop, timeit says os.stat takes 10x longer when building the three Decimal fields.  My immediate thought: lazy-create them.  This would mean some major brain surgery; I'd have to make a subtype of PyStructSequence and override... something (tp_getattr? tp_getattro?).  (Though this might also neatly ameliorate the early-startup import problem above.)  I'd also have to hide the exact integers in the object somewhere--but since I'd be subclassing anyway this'd be no big deal.

My second thought: maybe one of the other Decimal constructors is faster?  I'm currently using the "parse a string" form.  My guess is, one of the other forms might be faster but not by an order of magnitude.


Martin van L?wis wrote:
> For example, gcc doesn't support __float128 in 32-bit
> mode on x86.

That was only true for GCC 4.3.  GCC 4.4 and newer support __float128 in 32- and 64-bit modes on Intel.  That release has been out for more than two years.

But consider the matter dropped ;-)

----------
Added file: http://bugs.python.org/file23246/larry.decimal.utime.patch.1.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 20:03:50 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Sep 2011 18:03:50 +0000
Subject: [issue13048] Handling of paths in first argument of imp.find_module()
In-Reply-To: <1316984733.77.0.135974751185.issue13048@psf.upfronthosting.co.za>
Message-ID: <1317060230.58.0.140442597655.issue13048@psf.upfronthosting.co.za>


Brett Cannon  added the comment:

It's probably not a bad thing it's undocumented either since importing by file path was removed in Python 3, so this is another case where imp.find_module() differentiates from __import__.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 20:04:42 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Sep 2011 18:04:42 +0000
Subject: [issue13047] imp.find_module("") and imp.find_module(".")
In-Reply-To: <1316983798.48.0.694425302693.issue13047@psf.upfronthosting.co.za>
Message-ID: <1317060282.16.0.505030517667.issue13047@psf.upfronthosting.co.za>


Brett Cannon  added the comment:

I don't think this is undocumented as much as it's unexpected behavior. I really doubt this functionality was  on purpose.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 20:06:22 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 26 Sep 2011 18:06:22 +0000
Subject: [issue13046] imp.find_module() should not find unimportable modules
In-Reply-To: <1316977431.22.0.335405032353.issue13046@psf.upfronthosting.co.za>
Message-ID: <1317060382.86.0.126476885596.issue13046@psf.upfronthosting.co.za>


Brett Cannon  added the comment:

I'm w/ Ezio on this; imp.find_module() handling modules whose names can't be used by __import__() is fine.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 21:16:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Sep 2011 19:16:48 +0000
Subject: [issue12966] cookielib.LWPCookieJar breaks on cookie values with a
	newline
In-Reply-To: <1315854880.61.0.95908383563.issue12966@psf.upfronthosting.co.za>
Message-ID: <1317064608.68.0.459514785972.issue12966@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

By "it crashes on the invalid line" do you mean Python raises an exception, prints a traceback, and exits? Or does it seqfault, dump core, or the Windows equivavlent?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 21:45:34 2011
From: report at bugs.python.org (Paulie Pena)
Date: Mon, 26 Sep 2011 19:45:34 +0000
Subject: [issue12966] cookielib.LWPCookieJar breaks on cookie values with a
	newline
In-Reply-To: <1315854880.61.0.95908383563.issue12966@psf.upfronthosting.co.za>
Message-ID: <1317066334.89.0.66408998511.issue12966@psf.upfronthosting.co.za>


Paulie Pena  added the comment:

Sorry, by "crash" I did mean that it raised an exception.  My program wasn't expecting cookielib to fail while reading a cookie file that it had written, so I didn't wrap the code to read the cookie file in a try..except.  I would imagine that most people wouldn't.  Do you agree?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 22:40:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Sep 2011 20:40:13 +0000
Subject: [issue12966] cookielib.LWPCookieJar breaks on cookie values with a
	newline
In-Reply-To: <1315854880.61.0.95908383563.issue12966@psf.upfronthosting.co.za>
Message-ID: <1317069613.35.0.447910542034.issue12966@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

It would be better to raise an exception* upon receiving a cookie. On the other hand, I presume cookies are stored in files that any process can mess with, so reading failures are always a possibility. So if you want to catch a (very rare) failure, to do something useful, then you should do so.

*My preference versus silent rejection. But I do not do web programming.

Unless the current doc says something I missed, I think either change from the current 'store anything' policy would be a feature request. This is assuming that current behavior is unchanged from 2.5.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 26 23:13:07 2011
From: report at bugs.python.org (Paulie Pena)
Date: Mon, 26 Sep 2011 21:13:07 +0000
Subject: [issue12966] cookielib.LWPCookieJar breaks on cookie values with a
	newline
In-Reply-To: <1315854880.61.0.95908383563.issue12966@psf.upfronthosting.co.za>
Message-ID: <1317071587.33.0.487251730703.issue12966@psf.upfronthosting.co.za>


Paulie Pena  added the comment:

OK, I'll wrap it in a try-except.  Do you think the documentation should updated to make users aware of this possible problem?

Thanks,
Paulie

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 08:35:39 2011
From: report at bugs.python.org (Crispin Wellington)
Date: Tue, 27 Sep 2011 06:35:39 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1317105339.07.0.713961559193.issue1625@psf.upfronthosting.co.za>


Crispin Wellington  added the comment:

This is all fine and well, but this is clearly a bug and not a feature. Can we please see this bug fix go into 2.7 at some point?

----------
nosy: +Crispin.Wellington

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 14:04:26 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Tue, 27 Sep 2011 12:04:26 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1317125066.3.0.892296375514.issue1625@psf.upfronthosting.co.za>


G?k?en Eraslan  added the comment:

+1. If we think this as a bug, python 2.x users will never be able to extract multiple-stream bz2 files.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 14:05:06 2011
From: report at bugs.python.org (=?utf-8?q?G=C3=B6k=C3=A7en_Eraslan?=)
Date: Tue, 27 Sep 2011 12:05:06 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1317125106.11.0.669654312599.issue1625@psf.upfronthosting.co.za>


G?k?en Eraslan  added the comment:

I mean "as a feature".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 18:16:49 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 27 Sep 2011 16:16:49 +0000
Subject: [issue13049] distutils2 should not allow a distribution to install
	under another dist's directory
In-Reply-To: <1317058833.63.0.231790801143.issue13049@psf.upfronthosting.co.za>
Message-ID: <1317140209.77.0.50895870314.issue13049@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Fixed title ;)  This is still under discussion.

----------
title: distutils2 should not allow packages -> distutils2 should not allow a distribution to install under another dist's directory
versions: +3rd party, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 18:29:01 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 27 Sep 2011 16:29:01 +0000
Subject: [issue13030] Be more generic when identifying the Windows main dir in
	installation doc
In-Reply-To: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za>
Message-ID: <1317140941.23.0.974207538304.issue13030@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

Terry, are you saying that the report is not a bug or that some part of the message is valid and some other part not?  I can?t see clearly what I should do.

Sandro: You can nosy me to all bugs for distutils docs: Doc/distutils, Doc/install, Doc/packaging, Doc/library/packaging.* (and also related docs like site, using, sysconfig)

----------
nosy: +eric.araujo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 21:02:06 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Sep 2011 19:02:06 +0000
Subject: [issue13050] RLock support the context manager protocol but this is
	not documented
Message-ID: <1317150126.74.0.206470385317.issue13050@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
assignee: docs at python
components: Documentation
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: RLock support the context manager protocol but this is not documented

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 21:17:14 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 27 Sep 2011 19:17:14 +0000
Subject: [issue13030] Be more generic when identifying the Windows main dir in
	installation doc
In-Reply-To: <1316727111.41.0.373563358156.issue13030@psf.upfronthosting.co.za>
Message-ID: <1317151034.91.0.698006186866.issue13030@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

I said exactly what I said ;-). Upon looking further (following the links), I see that 'install' refers to the disutils setup program install command option. What you should do is make the doc accurate and clear.

What 'accurate' means is for you to say, but not having used install, the doc is not too clear to me. The table headings 'Standard installation location' (of what?) and 'Default value' (for what program?) both seem a bit ambiguous, or rather they seem reversed to me. I would label the columns 'Default module directory' and 'Standard Python location'.

That said, I hope that the actual default module installation directory for install is the actual site-packages directory on my machine, based on where I actually put python, and not the non-existent standard location, which I did not use but which is what the text seems to say (but which would be a behavior design bug to me).

MARTIN: below is the question for you.

The issue raised by the off-tracker OP, Michael Mol, is a different one about how the .msi installer works and whether this doc is correctly describing how it works. The question is whether the default python install directory built into pythonxy...msi is literally "C:\PythonXY\Lib\site-packages" or whether it is actually "%SYSTEMROOT%\PythonXY\Lib\site-packages". Mr. Mol claims that the latter, or something else (unspecified), is better.

----------
nosy: +loewis

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 23:28:21 2011
From: report at bugs.python.org (Eli Collins)
Date: Tue, 27 Sep 2011 21:28:21 +0000
Subject: [issue12424] distutils2: extension section uses bad environment
	marker separator
In-Reply-To: <1309219966.78.0.835295932694.issue12424@psf.upfronthosting.co.za>
Message-ID: <1317158901.86.0.00162319357917.issue12424@psf.upfronthosting.co.za>


Changes by Eli Collins :


----------
hgrepos: +70

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 23:29:13 2011
From: report at bugs.python.org (Eli Collins)
Date: Tue, 27 Sep 2011 21:29:13 +0000
Subject: [issue12424] distutils2: extension section uses bad environment
	marker separator
In-Reply-To: <1309219966.78.0.835295932694.issue12424@psf.upfronthosting.co.za>
Message-ID: <1317158953.51.0.274435699743.issue12424@psf.upfronthosting.co.za>


Changes by Eli Collins :


Added file: http://bugs.python.org/file23247/9170231ebf14.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 27 23:32:13 2011
From: report at bugs.python.org (Eli Collins)
Date: Tue, 27 Sep 2011 21:32:13 +0000
Subject: [issue12424] distutils2: extension section uses bad environment
	marker separator
In-Reply-To: <1309219966.78.0.835295932694.issue12424@psf.upfronthosting.co.za>
Message-ID: <1317159133.21.0.0763597157164.issue12424@psf.upfronthosting.co.za>


Eli Collins  added the comment:

I've attached a second revision of my patch to fix this issue (9170231ebf14.diff).

Per Eric Araujo's advice, this patch changes _pop_values() to use ";;" as the environment marker separator for all fields in setupcfg's extension sections. I've also updated the documentation and related unittests.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 00:28:23 2011
From: report at bugs.python.org (Eli Collins)
Date: Tue, 27 Sep 2011 22:28:23 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317162503.5.0.262749277469.issue12242@psf.upfronthosting.co.za>


Changes by Eli Collins :


----------
hgrepos: +71

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 00:29:31 2011
From: report at bugs.python.org (Eli Collins)
Date: Tue, 27 Sep 2011 22:29:31 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317162571.15.0.93390227358.issue12242@psf.upfronthosting.co.za>


Changes by Eli Collins :


Added file: http://bugs.python.org/file23248/04610583238f.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 00:31:36 2011
From: report at bugs.python.org (Eli Collins)
Date: Tue, 27 Sep 2011 22:31:36 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317162696.57.0.226743525079.issue12242@psf.upfronthosting.co.za>


Eli Collins  added the comment:

Attached is a diff (04610583238f.diff) containing a second revision of my implementation of this feature. It incorporates suggestions made during code review, as well as adds unittests and documentation of the new features.

This patch retains the same basic behavior as the previous patch, with only a few small changes:

* packaging.config.Config now uses ";;" as the environment marker separator for specific_compile_args and specific_link_args (to match the patch I submitted under issue 12424). 

* BCPPCompiler.get_compiler_version() has been implemented. This was the only compiler lacking an implementation under my previous patch.

* UnixCCompiler.get_compiler_version() has been enhanced to parse more version string formats, to better handle unknown compilers.

Outside of that, this patch adds unittests for all the new functionality; as well as documents CCompiler.get_compiler_version(), the new keywords added to Extension, how they both affect build_ext.

This should cover all the previously identified issues, let me know if there's anything more I can do to improve the patch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 02:47:11 2011
From: report at bugs.python.org (Tycho Andersen)
Date: Wed, 28 Sep 2011 00:47:11 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
Message-ID: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>


New submission from Tycho Andersen :

The attached patch fixes two bugs which manifest as infinite recursion in _insert_printable_char() of Textbox. First, the previous implementation of _insert_printable_char() used recursion to move characters when inserting a character. Thus, any Textpad which had an area greater than the interpreter's maximum recursion limit would crash. A minimal test case is the following:

#!/usr/bin/python
import curses
from curses.textpad import Textbox

def main(stdscr):
    box = Textbox(stdscr, insert_mode=True)
    box.stripspaces = True
    while 1:
        cmd = box.edit()
        if cmd == 'q':
            break

curses.wrapper(main)

Run that script in a terminal with area (i.e. $LINES * $COLUMNS) > 1000 (the default max recursion limit), press any key and be greeted by a stack trace. The patch changes the implementation of _insert_printable_char() to be iterative, thus avoiding the infinite recursion.

Second, when the underlying curses window was resized to be smaller than it was when the Textpad was created, pressing any key would result in infinite recursion (or with the new method, an infinite loop). The patch also changes Textpad so that instead of keeping the underlying window's size as instance attributes of this Textpad, Textpad asks the underlying window its size every time Textpad needs to know, allowing the underlying window to be resized at will.

I've verified this bug is in 2.7.1 and 3.2. Let me know if you need anything else.

----------
components: Library (Lib)
files: textpad_resize.patch
keywords: patch
messages: 144559
nosy: tycho
priority: normal
severity: normal
status: open
title: Infinite recursion in curses.textpad.Textbox
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23249/textpad_resize.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 03:57:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Sep 2011 01:57:25 +0000
Subject: [issue13013] _ctypes.c: refleak
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 1fb5b0cc6367 by Meador Inge in branch '2.7':
Issue #13013: ctypes: Fix a reference leak in PyCArrayType_from_ctype.
http://hg.python.org/cpython/rev/1fb5b0cc6367

New changeset 58a75eeb5c8e by Meador Inge in branch '3.2':
Issue #13013: ctypes: Fix a reference leak in PyCArrayType_from_ctype.
http://hg.python.org/cpython/rev/58a75eeb5c8e

New changeset 1726fa560112 by Meador Inge in branch 'default':
Issue #13013: ctypes: Fix a reference leak in PyCArrayType_from_ctype.
http://hg.python.org/cpython/rev/1726fa560112

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 04:03:31 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 28 Sep 2011 02:03:31 +0000
Subject: [issue13013] _ctypes.c: refleak
In-Reply-To: <1316530091.14.0.467899274194.issue13013@psf.upfronthosting.co.za>
Message-ID: <1317175411.84.0.716273872654.issue13013@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 04:27:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Sep 2011 02:27:28 +0000
Subject: [issue13039] IDLE3 editor: shell-like behaviour on line starting with
	">>>"
In-Reply-To: <1316816819.73.0.347712729805.issue13039@psf.upfronthosting.co.za>
Message-ID: <1317176848.69.0.470141852853.issue13039@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Yes, it is a real nuisance when pasting code that has '>>>'. You have to select and delete to get rid of each. This is related to #1178, but this bug should be fixed if possible even if that were implemented.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 04:29:24 2011
From: report at bugs.python.org (Meador Inge)
Date: Wed, 28 Sep 2011 02:29:24 +0000
Subject: [issue12881] ctypes: segfault with large structure field names
In-Reply-To: <1314935452.01.0.397268917791.issue12881@psf.upfronthosting.co.za>
Message-ID: <1317176964.07.0.992579475936.issue12881@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
assignee:  -> meador.inge
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 04:44:03 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Sep 2011 02:44:03 +0000
Subject: [issue13052] IDLE: replace ending with '\' causes crash
Message-ID: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za>


New submission from Terry J. Reedy :

As reported by R.S.Kachanovsky on the IDLE-sig list, and comfirmed by me with 3.2.2 on Win 7, entering a replace term ending with '\', like 'test\', in the find/replace dialog box causes IDLE to crash, as in do nothing for a couple of seconds and then close all windows.

A find term in either a find or find/replace box with a \ anywhere causes a beep. This means that one cannot search for test containing such, but that is better than crashing (which has the same effect).

----------
components: IDLE
messages: 144562
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: replace ending with '\' causes crash
type: crash
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 14:15:36 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Sep 2011 12:15:36 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1317212136.07.0.431817695109.issue12746@psf.upfronthosting.co.za>


Benjamin Peterson  added the comment:

Not anymore, though. :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 14:41:53 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Sep 2011 12:41:53 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1317213713.16.0.423928579714.issue12746@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 15:05:39 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Sep 2011 13:05:39 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1317215139.79.0.570347801575.issue12746@psf.upfronthosting.co.za>


Benjamin Peterson  added the comment:

Almost, that is. The unicodedata module still needs to use the new PEP 393 API.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 16:38:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Sep 2011 14:38:08 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 83f43b58c988 by Ezio Melotti in branch 'default':
#13012: use splitlines(keepends=True/False) instead of splitlines(0/1).
http://hg.python.org/cpython/rev/83f43b58c988

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 16:40:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Sep 2011 14:40:39 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1317220839.16.0.985677675087.issue13012@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

I applied my patch, including the changes in Lib/collections/__init__.py, the issue can now be closed.

----------
assignee:  -> mark.dickinson
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 16:40:53 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Sep 2011 14:40:53 +0000
Subject: [issue13012] Allow keyword argument in str.splitlines()
In-Reply-To: <1316526247.48.0.14583848283.issue13012@psf.upfronthosting.co.za>
Message-ID: <1317220853.8.0.881320043752.issue13012@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 17:37:28 2011
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 28 Sep 2011 15:37:28 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
Message-ID: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>


New submission from Larry Hastings :

After the great Capsule flame wars of 2011, it became clear that we need documentation on migrating from CObject to Capsules, as CObject is gone as of 3.2.  Nick made me promise to write the documentation, and Raymond steered me in the direction of "cporting.rst" (Porting Extension Modules To Python 3.0).

I already have a patch in reasonable shape.  However, I understand we're doing "forward-porting" (what Monotone calls "daggy fixes").  I think this would be valuable information for 2.7 users.  It includes no code changes (though it does include some sample code).  Would checking it in to the 2.7 head be appropriate?  Once we decide where the checkin should go, I'll produce a patch against that head that will hopefully garner your approval.

----------
assignee: larry
components: Documentation
messages: 144567
nosy: larry, ncoghlan, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add Capsule migration documentation to "cporting"
type: feature request
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 17:47:35 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Sep 2011 15:47:35 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
Message-ID: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>


New submission from Ezio Melotti :

Now that PEP 393 is in and the distinction between narrow and wide doesn't exist anymore, the value of sys.maxunicode should always be 0x10FFFF.

sys.maxunicode currently uses PyUnicode_GetMax (Objects/unicodeobject.c:196) and still returns either 0x10FFFF if  Py_UNICODE_WIDE is defined or 0xFFFF if it's not (and that should now mean that it's defined on Linux where wchar_t is 4 bytes, but not on Windows where it's 2 bytes (isn't this backward incompatible? if so it probably deserves another issue)).

IIUC the difference between narrow and wide is gone for Python users, but it's still there for C users that use the old API, so changing PyUnicode_GetMax will most likely break their code.

I therefore suggest to set sys.maxunicode to 0x10FFFF and to leave PyUnicode_GetMax as is.

C users that switch to the new API should stop using PyUnicode_GetMax and it should be added along with the other deprecated functions in PEP 393.
If sys.maxunicode becomes a constant, it won't be useful to determine if the build is narrow or wide anymore (that won't actually matter anymore, but this was the main use of sys.maxunicode), but it might still be useful to know the value of the highest codepoint.  Therefore I think that sys.maxunicode can still stay around without being deprecated (its documentation should be fixed though).

----------
assignee: ezio.melotti
components: Interpreter Core, Unicode
messages: 144568
nosy: ezio.melotti, haypo, lemburg, loewis
priority: high
severity: normal
stage: test needed
status: open
title: sys.maxunicode value after PEP-393
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 18:09:46 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 28 Sep 2011 16:09:46 +0000
Subject: [issue11473] upload command no longer accepts repository by section
	name
In-Reply-To: <1299882717.19.0.490703720004.issue11473@psf.upfronthosting.co.za>
Message-ID: <1317226186.2.0.698750091686.issue11473@psf.upfronthosting.co.za>


Jason R. Coombs  added the comment:

I now seem to be unable to reproduce the issue. I do keep my .pypirc in a revision control system, so I have reasonable confidence that my .pypirc contained the content that I'm attaching now (passwords scrubbed of course).

One possible factor is that my .pypirc is symlinked from ~/.pypirc to config/python/.pypirc and it's conceivable that Python 3.2.0 has some issues with symlink resolution that caused it to not process the .pypirc properly.

I'm going to install Python 3.2.0 and try to reproduce the issue there.

----------
Added file: http://bugs.python.org/file23250/.pypirc

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 18:36:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Sep 2011 16:36:37 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
In-Reply-To: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>
Message-ID: <1317227797.24.0.807110618069.issue13054@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Attached initial patch that sets the value of sys.maxunicode to 0x10FFFF, adds a test, and document the change in both the sys.rst doc and in the 3.3 whatsnew.

The patch doesn't include any deprecation.  If we decide to deprecate something the PEP and possibly the code should be updated.

----------
keywords: +patch
Added file: http://bugs.python.org/file23251/issue13054.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 18:38:39 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 28 Sep 2011 16:38:39 +0000
Subject: [issue11473] upload command no longer accepts repository by section
	name
In-Reply-To: <1299882717.19.0.490703720004.issue11473@psf.upfronthosting.co.za>
Message-ID: <1317227919.07.0.212839483973.issue11473@psf.upfronthosting.co.za>


Jason R. Coombs  added the comment:

Sure enough. I just confirmed that with Python 3.2.0, if .pypirc is symlinked, distutils behaves as if the .pypirc isn't present at all, but if that same .pypirc is copied, it behaves as expected. If one deletes the .pypirc altogether, it produces the same error.

Furthermore, this issue was fixed before the release of 3.2.2 (probably in 3.2.1).

My guess is that with the PYPIRC_CUSTOM_SERVER, it was somehow not being installed or resolved correctly, so the content was irrelevant.

I suggest we mark this bug as resolved (as the primary cause was due to the file not being read at all), but also apply your patch (which has some other good fixes) without the CUSTOM_SERVER, or with a version of the CUSTOM_SERVER that works.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 18:52:44 2011
From: report at bugs.python.org (etuardu)
Date: Wed, 28 Sep 2011 16:52:44 +0000
Subject: [issue13039] IDLE editor: shell-like behaviour on line starting with
	">>>"
In-Reply-To: <1316816819.73.0.347712729805.issue13039@psf.upfronthosting.co.za>
Message-ID: <1317228764.65.0.103860889081.issue13039@psf.upfronthosting.co.za>


etuardu  added the comment:

Note that this does not affect just pasted code, you can reproduce it typing on a new line three greater-than signs plus a space, and then trying to use backspace. One might want to legitimately do that in a module docstring, e.g.:

"""This module provides this:
>>> foo()
True
"""

----------
title: IDLE3 editor: shell-like behaviour on line starting with ">>>" -> IDLE editor: shell-like behaviour on line starting with ">>>"

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 19:39:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 28 Sep 2011 17:39:58 +0000
Subject: [issue12933] Update or remove claims that distutils requires external
	programs
In-Reply-To: <1315411614.16.0.0292960363033.issue12933@psf.upfronthosting.co.za>
Message-ID: <1317231598.15.0.893612425227.issue12933@psf.upfronthosting.co.za>


?ric Araujo  added the comment:

BTW, one way to confirm this is to use an OS without the tar, gzip, etc. programs, remove the checks in the code that return or skip if tar is not present and run the test suite.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 19:52:52 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 28 Sep 2011 17:52:52 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
In-Reply-To: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>
Message-ID: <1317232372.37.0.68136897795.issue13054@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

Sounds all fine to me.

As the PEP specifies, all deprecation will only be on paper for now, not in the code. Adding PyUnicode_GetMax to the list sounds fine to me as well.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 21:32:02 2011
From: report at bugs.python.org (Ben Gamari)
Date: Wed, 28 Sep 2011 19:32:02 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
Message-ID: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>


New submission from Ben Gamari :

The distutils.LooseVersion constructor currently only calls parse if vstring has a value. Unfortunately, this means that a user passing in vstring="" or vstring=None gets a version object with self.vstring and self.version unset. This wreaks havoc later when the user tries to do anything with their object. I've attached two possible solutions.

The first attempts to fix the issue by raising an exception when an invalid vstring is given. This seems like the most reasonable treatment of this case as there is no reasonable way to fully initialize the object. The second works around the issue, initializing the uninitialized fields with "" in the event of an invalid vstring.

----------
files: distutils-fix.patch
keywords: patch
messages: 144575
nosy: bgamari
priority: normal
severity: normal
status: open
title: Distutils tries to handle null versions but fails
Added file: http://bugs.python.org/file23252/distutils-fix.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 21:32:14 2011
From: report at bugs.python.org (Ben Gamari)
Date: Wed, 28 Sep 2011 19:32:14 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
In-Reply-To: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>
Message-ID: <1317238334.54.0.10334730459.issue13055@psf.upfronthosting.co.za>


Changes by Ben Gamari :


Added file: http://bugs.python.org/file23253/distutils-workaround.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 21:32:35 2011
From: report at bugs.python.org (Ben Gamari)
Date: Wed, 28 Sep 2011 19:32:35 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
In-Reply-To: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>
Message-ID: <1317238355.67.0.792591474279.issue13055@psf.upfronthosting.co.za>


Changes by Ben Gamari :


----------
assignee:  -> tarek
components: +Distutils
nosy: +eric.araujo, tarek
type:  -> crash
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 22:41:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 28 Sep 2011 20:41:32 +0000
Subject: [issue13039] IDLE editor: shell-like behaviour on line starting with
	">>>"
In-Reply-To: <1316816819.73.0.347712729805.issue13039@psf.upfronthosting.co.za>
Message-ID: <1317242492.36.0.178469111654.issue13039@psf.upfronthosting.co.za>


Terry J. Reedy  added the comment:

Right. That is how I reconfirmed that the bug still exists in 3.2.2, and why I said it should be fixed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 22:48:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Sep 2011 20:48:55 +0000
Subject: [issue13039] IDLE editor: shell-like behaviour on line starting with
	">>>"
In-Reply-To: <1316816819.73.0.347712729805.issue13039@psf.upfronthosting.co.za>
Message-ID: <1317242935.59.0.857807126639.issue13039@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Do you want to work on a patch?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 28 23:18:34 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Sep 2011 21:18:34 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
In-Reply-To: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset 606652491366 by Ezio Melotti in branch 'default':
#13054: sys.maxunicode is now always 0x10FFFF.
http://hg.python.org/cpython/rev/606652491366

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 01:22:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Sep 2011 23:22:45 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
In-Reply-To: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>
Message-ID: <1317252165.91.0.249039960249.issue13054@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Attached a second patch that fixes checks like:
if sys.maxunicode == 65535:
    ...

There are a couple of places (e.g. test_bigmem) where I'm not sure what the best fix is, so I added a couple of XXX in the patch.  If you have any suggestion please comment either here on in the review page.

----------
Added file: http://bugs.python.org/file23254/issue13054-2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 01:28:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 28 Sep 2011 23:28:19 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
In-Reply-To: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>
Message-ID: <1317252499.18.0.979656468844.issue13054@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

I added PyUnicode_GetMax to the list of deprecated functions in PEP 393 in http://hg.python.org/peps/rev/9a154edf18e6.
(I'm also adding Antoine to the nosy because he might know something about test_bigmem.)

----------
nosy: +pitrou
stage: test needed -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 02:00:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 00:00:36 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
In-Reply-To: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>
Message-ID: <1317254436.75.0.089184644016.issue13055@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
stage:  -> test needed
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 02:01:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 00:01:41 +0000
Subject: [issue12933] Update or remove claims that distutils requires external
	programs
In-Reply-To: <1315411614.16.0.0292960363033.issue12933@psf.upfronthosting.co.za>
Message-ID: <1317254501.82.0.125139291681.issue12933@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 02:12:04 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 00:12:04 +0000
Subject: [issue13053] Add Capsule migration documentation to "cporting"
In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za>
Message-ID: <1317255124.9.0.171002441506.issue13053@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

I think it's fine to include it in 2.7.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 03:04:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 01:04:47 +0000
Subject: [issue13052] IDLE: replace ending with '\' causes crash
In-Reply-To: <1317177843.04.0.691154940707.issue13052@psf.upfronthosting.co.za>
Message-ID: <1317258287.26.0.710714873316.issue13052@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

The problem is in Lib/idlelib/ReplaceDialog.py:141:
m = prog.match(chars, col)
if not prog:
    return False
new = m.expand(self.replvar.get())

where
prog = re.compile('foo')  # i.e. text in the find box
chars = '>>> "foo"\n'  # i.e. the text in the IDLE window
col = 5
self.replvar.get() = 'bar\'  # i.e. the var with the trailing \

m.expand() searches for groups to expand, like \1 and \2 to refer to the first and second matching group, and fails with:

Traceback (most recent call last):
  File "/home/wolf/dev/py/py3k/Lib/sre_parse.py", line 194, in __next
    c = self.string[self.index + 1]
IndexError: string index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/wolf/dev/py/py3k/Lib/re.py", line 278, in _expand
    template = sre_parse.parse_template(template, pattern)
  File "/home/wolf/dev/py/py3k/Lib/sre_parse.py", line 729, in parse_template
    this = sget()
  File "/home/wolf/dev/py/py3k/Lib/sre_parse.py", line 210, in get
    self.__next()
  File "/home/wolf/dev/py/py3k/Lib/sre_parse.py", line 196, in __next
    raise error("bogus escape (end of line)")
sre_constants.error: bogus escape (end of line)

Using things like foo\5bar also results in a crash because the group \5 is not found.

I'm not sure what the expected behavior should be.  If numeric/named backreferences are not supposed to be supported, I guess a re.escape() might solve the problem.  If they are supported the last line should be wrapped in a try/except that looks for sre_constants.error errors and possibly IndexErrors too (this might actually be fixed in sre_parse.py).

BTW, I think that "if not prog" in the snippet I pasted should be "if not m".  Pattern objects are always True (I assume prog is always a pattern object).

Do you want to work on a patch?

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 03:38:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 01:38:20 +0000
Subject: [issue13056] test_multibytecodec.py:TestStreamWriter is skipped after
	PEP393
Message-ID: <1317260300.62.0.299015504355.issue13056@psf.upfronthosting.co.za>


New submission from Ezio Melotti :

The test at Lib/test/test_multibytecodec.py:178 checks for len('\U00012345') == 2, and with PEP393 this is always False.
I tried to run the tests with a few changes and they seem to work, but the code doesn't raise any exception on c.reset():

---->8-------->8-------->8-------->8----
import io, codecs
s = io.BytesIO()
c = codecs.getwriter('gb18030')(s)
c.write('123'); s.getvalue()
c.write('\U00012345'); s.getvalue()
c.write('\U00012345' + '\uac00\u00ac'); s.getvalue()
c.write('\uac00'); s.getvalue()
c.reset()
s.getvalue()
---->8-------->8-------->8-------->8----

Result:
>>> import io, codecs
>>> s = io.BytesIO()
>>> c = codecs.getwriter('gb18030')(s)
>>> c.write('123'); s.getvalue()
b'123'
>>> c.write('\U00012345'); s.getvalue()
b'123\x907\x959'
>>> # '\U00012345'[0] is the same of '\U00012345' now
>>> c.write('\U00012345' + '\uac00\u00ac'); s.getvalue()
b'123\x907\x959\x907\x959\x827\xcf5\x810\x851'
>>> c.write('\uac00'); s.getvalue()
b'123\x907\x959\x907\x959\x827\xcf5\x810\x851\x827\xcf5'
>>> c.reset()  # is this supposed to raise an error?
>>> s.getvalue()
b'123\x907\x959\x907\x959\x827\xcf5\x810\x851\x827\xcf5'

Victor suggested to wait until multibytecodec gets ported to the new API before fixing this.

----------
components: Tests
messages: 144583
nosy: ezio.melotti, haypo, loewis
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multibytecodec.py:TestStreamWriter is skipped after PEP393
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 03:47:23 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 01:47:23 +0000
Subject: [issue13056] test_multibytecodec.py:TestStreamWriter is skipped after
	PEP393
In-Reply-To: <1317260300.62.0.299015504355.issue13056@psf.upfronthosting.co.za>
Message-ID: <1317260843.52.0.302665568725.issue13056@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
components: +Unicode

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 04:38:37 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Thu, 29 Sep 2011 02:38:37 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
Message-ID: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>


New submission from Wong Wah Meng :

Resending as my old alternative email ID wasn't registered under my account. 
===========================================================================
Hello there,

I included --with-threads option into the configure script calling, which it failed to add the -D_REENTRANT into Makefile. So I manually added this into OPT of the Makefile. I ran make again and generated a new python binary. However, the new binary is still not able to start a new thread from the thread module. 

I reviewed the config.log file, I think this failure has caused the build with threads failed. Cthreads.h header file is missing. Should this be included in my HP UX Compiler or it comes from python source? In python source I only found pythread.h. Anyway, I am only guessing what is wrong. 

Hope to hear some feedback here, whether this is something missing or a bug. 

configure:8407: checking for --with-threads
configure:8427: result: yes
configure:8484: checking for _POSIX_THREADS in unistd.h
configure:8503: result: yes
configure:8508: checking cthreads.h usability
configure:8508: cc +DD64 -I/home/r32813/local/include -c -g  conftest.c >&5
"conftest.c", line 128: error #3696-D: cannot open source file "cthreads.h"
  #include 
                       ^
1 error detected in the compilation of "conftest.c".

configure:8508: result: no
configure:8508: checking for cthreads.h
configure:8508: result: no
configure:8521: checking mach/cthreads.h usability
configure:8521: cc +DD64 -I/home/r32813/local/include -c -g  conftest.c >&5
"conftest.c", line 128: error #3696-D: cannot open source file "mach/cthreads.h"
  #include 
                            ^

1 error detected in the compilation of "conftest.c".
configure:8521: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define _GNU_SOURCE 1

configure:8521: result: no
configure:8521: checking for mach/cthreads.h
configure:8521: result: no
configure:8533: checking for --with-pth
configure:8548: result: no
configure:8556: checking for pthread_create in -lpthread
configure:8572: cc +DD64 -I/home/r32813/local/include -o conftest -g  -L/home/r32813/local/lib -L/home/r32813/Build/2.7.1/Python-2.7.1 conftest.c -l
nsl -lrt -ldld -ldl  -lpthread >&5

Regards,
Wah Meng
Genesis Wafermap Support Ticket: 
To report a problem: http://dyno.freescale.net/Question/QuestionMain3.asp?location=zmy02&category=&tickettype=6820
To request a service: http://dyno.freescale.net/Question/Questionmain3.asp?location=74&category=2&tickettype=6819
Or if it is related to EWM or DSA: http://dyno.freescale.net/Question/Questionmain3.asp?location=ZMY02&tickettype=6539

----------
messages: 144584
nosy: wah meng
priority: normal
severity: normal
status: open
title: Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 06:04:23 2011
From: report at bugs.python.org (Eli Collins)
Date: Thu, 29 Sep 2011 04:04:23 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317269063.17.0.983817220714.issue12242@psf.upfronthosting.co.za>


Changes by Eli Collins :


Added file: http://bugs.python.org/file23255/ba08e4a70631.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 06:06:01 2011
From: report at bugs.python.org (Eli Collins)
Date: Thu, 29 Sep 2011 04:06:01 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317269161.84.0.111109332155.issue12242@psf.upfronthosting.co.za>


Eli Collins  added the comment:

Attached is a diff (ba08e4a70631.diff) containing a third revision of my patch. This hopefully addresses all the issues brought up in the code review of the second revision, and changes little else.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 09:30:55 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Sep 2011 07:30:55 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <1317281455.02.0.712797109658.issue13057@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

> However, the new binary is still not able to start a new thread from the thread module. 

Traceback?


mach/cthreads.h is only relevant for Hurd, as far as I can see. 


> configure:8572: cc +DD64 -I/home/r32813/local/include -o conftest -g
> -L/home/r32813/local/lib -L/home/r32813/Build/2.7.1/Python-2.7.1
> conftest.c -l nsl -lrt -ldld -ldl  -lpthread >&5

Result of this test?

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 11:27:49 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Thu, 29 Sep 2011 09:27:49 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <1317281455.02.0.712797109658.issue13057@psf.upfronthosting.co.za>
Message-ID: <02EA6D704E30CE499C5071776509A925F5A1D3@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

Traceback?

$ python
Python 2.7.1 (r271:86832, Sep 28 2011, 17:31:02) [C] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>> import thread
>>> def testing():
...    print "Hello World"
... 
>>> thread.start_new_thread(testing, ())  
Traceback (most recent call last):
  File "", line 1, in 
thread.error: can't start new thread
>>>

mach/cthreads.h is only relevant for Hurd, as far as I can see. 

I am not sure what Hurd is. So I should not be looking at this one I guess. 

> configure:8572: cc +DD64 -I/home/r32813/local/include -o conftest -g
> -L/home/r32813/local/lib -L/home/r32813/Build/2.7.1/Python-2.7.1
> conftest.c -l nsl -lrt -ldld -ldl  -lpthread >&5

Result of this test?

configure:8556: checking for pthread_create in -lpthread
configure:8572: cc +DD64 -I/home/r32813/local/include -o conftest -g  -L/home/r32813/local/lib -L/home/r32813/Build/2.7.1/Python-2.7.1 conftest.
c -lnsl -lrt -ldld -ldl  -lpthread >&5
"conftest.c", line 97: warning #2223-D: function "exit" declared implicitly
  void * start_routine (void *arg) { exit (0); }
                                     ^

"conftest.c", line 102: error #2020: identifier "NULL" is undefined
  pthread_create (NULL, NULL, start_routine, NULL)
                  ^

1 error detected in the compilation of "conftest.c".
configure:8572: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define _GNU_SOURCE 1
| #define _NETBSD_SOURCE 1
| #define __BSD_VISIBLE 1
| #define _BSD_TYPES 1
----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 11:52:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 09:52:23 +0000
Subject: [issue11457] Expose nanosecond precision from system calls
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1317289943.64.0.192897852761.issue11457@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
stage:  -> test needed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 13:29:44 2011
From: report at bugs.python.org (Thomas Jarosch)
Date: Thu, 29 Sep 2011 11:29:44 +0000
Subject: [issue13058] Fix file descriptor leak on error
Message-ID: <1317295783.94.0.921063756825.issue13058@psf.upfronthosting.co.za>


New submission from Thomas Jarosch :

Hi,

attached patch fixes a file descriptor leak on error.

Best regards,
Thomas Jarosch

----------
components: Extension Modules
files: cpython-fix-file-descriptor-leak.patch
keywords: patch
messages: 144588
nosy: thomas.jarosch
priority: normal
severity: normal
status: open
title: Fix file descriptor leak on error
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file23256/cpython-fix-file-descriptor-leak.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 14:48:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 12:48:05 +0000
Subject: [issue13059] Sporadic test_multiprocessing failure: IOError("bad
	message length") in recv_bytes()
Message-ID: <1317300485.05.0.349182962077.issue13059@psf.upfronthosting.co.za>


New submission from STINNER Victor :

[ 62/359] test_multiprocessing
Warning -- threading._dangling was modified by test_multiprocessing
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing
test test_multiprocessing crashed -- Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/regrtest.py", line 1163, in runtest_inner
    indirect_test()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_multiprocessing.py", line 2349, in test_main
    ManagerMixin.pool = ManagerMixin.manager.Pool(4)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", line 670, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", line 568, in _create
    conn = self._Client(self._address, authkey=self._authkey)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py", line 507, in Client
    answer_challenge(c, authkey)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py", line 734, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py", line 243, in recv_bytes
    self._bad_message_length()
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py", line 175, in _bad_message_length
    raise IOError("bad message length")
IOError: bad message length

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/828/steps/test/logs/stdio

----------
components: Library (Lib)
messages: 144589
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Sporadic test_multiprocessing failure: IOError("bad message length") in recv_bytes()
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 17:16:50 2011
From: report at bugs.python.org (Arne Babenhauserheide)
Date: Thu, 29 Sep 2011 15:16:50 +0000
Subject: [issue13060] make round() floating-point errors less hurtful
Message-ID: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>


New submission from Arne Babenhauserheide :

Hi, 

I just stumbled over round() errors. I read the FAQ?, and even though the FAQ states that this is no bug, its implementation is less than ideal. 

To illustrate: 

>>> round(0.5, 1)
0.0

and 

>>> round(5, -1)
0

This is mathematically wrong and hits for comparisions which humans put in. 

As alternate I use the following hack myself where ever I have to round numbers: 

def roundexact(a, *args): 
...  return round(a+0.000000000000001*max(1.0, (2*a)//10), *args)

This has correct behavior for *5 on my hardware: 

>>> roundexact(0.5, 0)
1.0

Its errors only appear in corner cases: 

>>> roundexact(0.4999999999999999, 0)
0.0
>>> roundexact(0.49999999999999998, 0)
1.0

This implementation shields me from implementation details of my hardware in all but very few extreme cases, while the current implementation of round() exhibits the hardware-imposed bugs in cases which actually matter to humans.

Maybe round could get a keyword argument roundup5 or such, which exhibits the behavior that any *5 number is rounded up.

Note: The decimal module is no alternative, because it is more than factor 100 slower than floats (at least for simple computations): 

>>> from timeit import timeit
>>> timeit("float(1.0)+float(0.1)")
0.30365920066833496

>>> timeit("Decimal(1.0)+Decimal(0.1)", setup="from decimal import Decimal, getcontext; getcontext().prec=17")
49.96972298622131

?: http://docs.python.org/library/functions.html?highlight=round#round

----------
components: Interpreter Core
messages: 144590
nosy: ArneBab
priority: normal
severity: normal
status: open
title: make round() floating-point errors less hurtful
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 17:19:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Sep 2011 15:19:41 +0000
Subject: [issue13060] make round() floating-point errors less hurtful
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317309581.35.0.848428464746.issue13060@psf.upfronthosting.co.za>


R. David Murray  added the comment:

Note that a C accelerator for Decimal is in the works.

----------
nosy: +mark.dickinson, r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 17:20:08 2011
From: report at bugs.python.org (Arne Babenhauserheide)
Date: Thu, 29 Sep 2011 15:20:08 +0000
Subject: [issue13060] make round() floating-point errors less hurtful
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317309608.43.0.417406794076.issue13060@psf.upfronthosting.co.za>


Arne Babenhauserheide  added the comment:

Better comparision of decimal and float: 

>>> timeit("a+a", setup="from decimal import Decimal, getcontext; getcontext().prec=17; a = Decimal(1.0)")
21.125790119171143
>>> timeit("a+a", setup="a = float(1.0)")
0.05324697494506836

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 17:25:32 2011
From: report at bugs.python.org (Arne Babenhauserheide)
Date: Thu, 29 Sep 2011 15:25:32 +0000
Subject: [issue13060] make round() floating-point errors less hurtful
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317309932.3.0.514429978926.issue13060@psf.upfronthosting.co.za>


Arne Babenhauserheide  added the comment:

If the C accelerator for decimal gets decimal performance close to floats (which I doubt, because it has to do much more), it could be very useful for me. What is its estimated time to completion?

Even when it is finished, it does not change the problem that round(0.5, 0) gives mathematically wrong results, so python requires hacks to be correct in this very simple case - instead of being right for most of the simple cases and only get it wrong in corner cases.

My hack isn?t really clean, though, because it depends on the internal representation of floats in the hardware. A real fix would have to get the real size of floats and adjust the added value accordingly.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 17:31:29 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Sep 2011 15:31:29 +0000
Subject: [issue13060] make round() floating-point errors less hurtful
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317310289.41.0.380630352334.issue13060@psf.upfronthosting.co.za>


R. David Murray  added the comment:

It seems to me that saying "floating point" and "mathematically correct" in the same breath is...optimistic :)  But that's why I added Mark to nosy, he knows far more about this stuff than I do.

As far as I know the accelerator is feature complete at this point.  I think the goal is to ship it with 3.3, but I'm not sure where we are at in the process of making that a reality.

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 17:35:56 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Sep 2011 15:35:56 +0000
Subject: [issue13060] make round() floating-point errors less hurtful
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317310556.13.0.488632795491.issue13060@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> This is mathematically wrong ...

No, it's not 'mathematically wrong'.  There are many different rounding conventions in use, and no single universally agreed convention for rounding halfway cases.  Python chooses to use unbiased rounding[1] here, which matches the rounding used for all other basic arithmetic operations.

Other comments:

(1) I agree that round-half-up might be a useful convention to have available.  But...

(2) Depending on any sort of predictable rounding behaviour for *decimal* halfway cases when using *binary* floats is fraught with peril.  If you really care about these halfway cases going in a particular direction (whether it's away from zero, towards +infinity, towards even, towards odd, etc.) then you should really be using Decimal.







[1] http://en.wikipedia.org/wiki/Rounding#Round_half_to_even

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 17:40:15 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Sep 2011 15:40:15 +0000
Subject: [issue13060] make round() floating-point errors less hurtful
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317310815.4.0.783625582964.issue13060@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
type:  -> feature request
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 17:44:57 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Sep 2011 15:44:57 +0000
Subject: [issue13060] make round() floating-point errors less hurtful
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317311097.29.0.629313761912.issue13060@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

Classifying this as a feature request:  the behaviour of round isn't going to change here, but there might be community support for adding a mechanism for round to allow other rounding modes.  It might be worth taking this to the python-ideas mailing list to hash out what that mechanism should be (extra keyword to round, ...).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 17:57:04 2011
From: report at bugs.python.org (Arne Babenhauserheide)
Date: Thu, 29 Sep 2011 15:57:04 +0000
Subject: [issue13060] allow other rounding modes in round()
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317311824.47.0.814324482098.issue13060@psf.upfronthosting.co.za>


Arne Babenhauserheide  added the comment:

I did not know about rounding to even, so maybe there should be a warning in the 2.7 documentation, that the behavior changed in python 3 (I just checked that: python2.7 is in line with the documentation). 

The first time I stumbled over these issues was when implementing a game, where I wanted to map pixels to hexfields, where I had to get the borderline cases right: https://bitbucket.org/ArneBab/hexbattle/src/38ad49c04836/hexgrid.py#cl-24

This likely won?t hit me in the game, but it really hurts in the doctests.

PS: I like the naming as ?allow other rounding modes?, so I changed the title of the bug. I hope that?s OK.

PPS: Thank you for all your replies! The bugtracker feels really welcoming and helpful, even when reporting something as a bug, which is just a difference in goal definition. I hope it will turn out to be useful for the community!

----------
title: make round() floating-point errors less hurtful -> allow other rounding modes in round()

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 18:11:21 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Sep 2011 16:11:21 +0000
Subject: [issue13060] allow other rounding modes in round()
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317312681.57.0.292558115154.issue13060@psf.upfronthosting.co.za>


Mark Dickinson  added the comment:

> maybe there should be a warning in the 2.7 documentation

Well, such a warning really belongs in the Python 3 documentation rather than the Python 2 documentation.  (Or at least, AFAIK that's the convention that's been followed to date:  the Python 2 docs don't 'know' about Python 3 in general.)

There's a note in the 'What's new in Python 3' documentation that covers this and other changes in round:

http://docs.python.org/dev/whatsnew/3.0.html#builtins

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 19:14:19 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Sep 2011 17:14:19 +0000
Subject: [issue13060] allow other rounding modes in round()
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317316459.16.0.909290734396.issue13060@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

> If the C accelerator for decimal gets decimal performance close to
> floats (which I doubt, because it has to do much more), it could be
> very useful for me. What is its estimated time to completion?


It is finished and awaiting review (See #7652). The version in

   http://hg.python.org/features/cdecimal#py3k-cdecimal

is the same as the version that will be released as cdecimal-2.3
in a couple of weeks.

Benchmarks for cdecimal-2.2 are over here:

http://www.bytereef.org/mpdecimal/benchmarks.html#pi-64-bit


Typically cdecimal is 2-3 times slower than floats. With
further aggressive optimizations one *might* get that down
to 1.5-2 times for a fixed width Decimal64 type, but this is
pure speculation at this point.

If you look at http://www.bytereef.org/mpdecimal/benchmarks.html#mandelbrot-64-bit ,
you'll see that the Intel library performs very well for that specific
type. Exact calculations are performed in binary, then converted to
decimal for rounding. Note that this strategy _only_ works for
relatively low precisions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 19:15:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 17:15:46 +0000
Subject: [issue11457] os.stat(): add new fields to get timestamps as Decimal
	objects with nanosecond resolution
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1317316546.1.0.779612223455.issue11457@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: Expose nanosecond precision from system calls -> os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 19:27:44 2011
From: report at bugs.python.org (Joshua Bleecher Snyder)
Date: Thu, 29 Sep 2011 17:27:44 +0000
Subject: [issue13061] Decimal module yields incorrect results when Python
	compiled with llvm
Message-ID: <1317317264.78.0.478675633552.issue13061@psf.upfronthosting.co.za>


New submission from Joshua Bleecher Snyder :

When Python is compiled on OS X with llvm, the decimal module behaves erratically (simple calculations are wrong, most doctests fail). This was originally reported here:

http://stackoverflow.com/questions/7590137/dividing-decimals-yields-invalid-results-in-python-2-5-to-2-7

and the compiler dependency was tracked down here:

https://trac.macports.org/ticket/31444

Although it looks like MacPorts is going to force use of gcc, it'd still be better for Python to behave correctly when compiled with llvm.

Possibly related to http://bugs.python.org/issue11149?

----------
assignee: ronaldoussoren
components: Build, Installation, Library (Lib), Macintosh
messages: 144604
nosy: josharian, ronaldoussoren
priority: normal
severity: normal
status: open
title: Decimal module yields incorrect results when Python compiled with llvm
type: behavior
versions: 3rd party, Python 2.6, Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 19:43:10 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Sep 2011 17:43:10 +0000
Subject: [issue13062] Introspection generator and function closure state
Message-ID: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>


New submission from Nick Coghlan :

Based on the python-ideas thread about closures, I realised there are two features the inspect module could offer to greatly simplify some aspects of testing closure and generator behaviour:

  inspect.getclosure(func)
    Returns a dictionary mapping closure references from the supplied function to their current values.

  inspect.getgeneratorlocals(generator)
    Returns the same result as would be reported by calling locals() in the generator's frame of execution

The former would just involve syncing up the names on the code object with the cell references on the function object, while the latter would be equivalent to doing generator.gi_frame.f_locals with some nice error checking for when the generator's frame is already gone (or the supplied object isn't a generator iterator).

----------
messages: 144606
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Introspection generator and function closure state
type: feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 19:47:08 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Sep 2011 17:47:08 +0000
Subject: [issue11457] os.stat(): add new fields to get timestamps as Decimal
	objects with nanosecond resolution
In-Reply-To: <1299715528.65.0.317038011667.issue11457@psf.upfronthosting.co.za>
Message-ID: <1317318428.24.0.759076196311.issue11457@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

> BTW, what is the status of cdecimal?

I just wrote the same in another issue, but not everyone is subscribed
to that:

I think cdecimal is finished and production ready. The version in

http://hg.python.org/features/cdecimal#py3k-cdecimal

is the same as what will be released as cdecimal-2.3 in a couple of
weeks. cdecimal-2.3 has a monumental test suite against *both*
decimal.py and decNumber. The test suite no longer finds any
kind of (unknown) divergence between decimal.py, cdecimal and
decNumber.

Tests for cdecimal-2.3 have been running on 6 cores for more
than half a year.

In short, review would be highly welcome. ;)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 19:48:55 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Sep 2011 17:48:55 +0000
Subject: [issue13058] Fix file descriptor leak on error
In-Reply-To: <1317295783.94.0.921063756825.issue13058@psf.upfronthosting.co.za>
Message-ID: 


Roundup Robot  added the comment:

New changeset dec00ae64ca8 by Charles-Fran?ois Natali in branch '2.7':
Issue #13058: ossaudiodev: fix a file descriptor leak on error. Patch by Thomas
http://hg.python.org/cpython/rev/dec00ae64ca8

New changeset 160b52c9e8b3 by Charles-Fran?ois Natali in branch '3.2':
Issue #13058: ossaudiodev: fix a file descriptor leak on error. Patch by Thomas
http://hg.python.org/cpython/rev/160b52c9e8b3

New changeset d8dc24c4e83d by Charles-Fran?ois Natali in branch 'default':
Issue #13058: ossaudiodev: fix a file descriptor leak on error. Patch by Thomas
http://hg.python.org/cpython/rev/d8dc24c4e83d

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 19:54:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 29 Sep 2011 17:54:12 +0000
Subject: [issue13058] Fix file descriptor leak on error
In-Reply-To: <1317295783.94.0.921063756825.issue13058@psf.upfronthosting.co.za>
Message-ID: <1317318852.7.0.657118652053.issue13058@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

Patch applied, thanks!

----------
nosy: +neologix
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 20:04:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 18:04:50 +0000
Subject: [issue13060] allow other rounding modes in round()
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317319490.97.0.969361799341.issue13060@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 20:06:26 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 18:06:26 +0000
Subject: [issue12746] normalization is affected by unicode width
In-Reply-To: <1313208721.39.0.302717803099.issue12746@psf.upfronthosting.co.za>
Message-ID: <1317319586.11.0.1410258868.issue12746@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

Issue fixed in Python 3.3 by Martin, changesets 40cf7204ca2b and 50f008019213.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 20:13:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 18:13:04 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
In-Reply-To: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>
Message-ID: <1317319984.77.0.0420675637446.issue13054@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

As said on IRC, unicodesize and character_size should be 1 before the test is something like 'x'*1. Or you can just remove this constant, it's not very useful to have a constant equal to 1 :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 20:29:14 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 29 Sep 2011 18:29:14 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317320954.24.0.0935986935995.issue13062@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
components: +Library (Lib)
stage:  -> needs patch
versions: +Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 20:29:37 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 29 Sep 2011 18:29:37 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317320977.44.0.782751847995.issue13062@psf.upfronthosting.co.za>


Changes by Meador Inge :


----------
nosy: +meador.inge

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:00:42 2011
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 29 Sep 2011 19:00:42 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317322842.92.0.378117016545.issue13062@psf.upfronthosting.co.za>


Changes by Yury Selivanov :


----------
nosy: +Yury.Selivanov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:07:14 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 19:07:14 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
Message-ID: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>


New submission from STINNER Victor :

Re-running test 'test_concurrent_futures' in verbose mode
test_killed_child (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 5.79s ok
test_map (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 3.63s ok
test_map_exception (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 4.05s ok
test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 9.64s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 3.60s ok
test_submit (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 3.63s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 4.09s ok
test_map (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.13s ok
test_map_exception (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.12s ok
test_map_submits_without_iteration (test.test_concurrent_futures.ThreadPoolExecutorTest)
Tests verifying issue 11777. ... 0.14s ok
test_map_timeout (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 6.11s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_submit (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_submit_keyword (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_all_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... 3.74s ok
test_first_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... 5.18s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... 5.02s ok
test_first_exception (test.test_concurrent_futures.ProcessPoolWaitTests) ... 6.57s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ProcessPoolWaitTests) ... 6.37s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ProcessPoolWaitTests) ... 5.15s ok
test_timeout (test.test_concurrent_futures.ProcessPoolWaitTests) ... 10.94s ok
test_all_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 0.12s ok
test_first_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.62s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.61s ok
test_first_exception (test.test_concurrent_futures.ThreadPoolWaitTests) ... 3.12s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 2.10s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.60s ok
test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests) ... 6.12s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... 3.62s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... 5.65s ok
test_no_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... 0.12s ok
test_zero_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... 2.11s ok
test_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_failed (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_successful (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_raises (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_exception (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_result (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_repr (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_running (test.test_concurrent_futures.FutureTests) ... ok
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... 3.58s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... 3.92s ok
test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... 5.60s FAIL
test_processes_terminate (test.test_concurrent_futures.ProcessPoolShutdownTest) ... 3.67s ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... 0.01s ok
test_context_manager_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.02s ok
test_del_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.03s ok
test_interpreter_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 1.68s ok
test_run_after_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.00s ok
test_threads_terminate (test.test_concurrent_futures.ThreadPoolShutdownTest) ... Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\queues.py", line 267, in _feed
    send(obj)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 231, in send
    self._send_bytes(memoryview(buf))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 299, in _send_bytes
    overlapped = win32.WriteFile(self._handle, buf, overlapped=True)
IOError: [Errno 232] The pipe is being closed
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\queues.py", line 267, in _feed
    send(obj)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 231, in send
    self._send_bytes(memoryview(buf))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 299, in _send_bytes
    overlapped = win32.WriteFile(self._handle, buf, overlapped=True)
IOError: [Errno 232] The pipe is being closed
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\queues.py", line 267, in _feed
    send(obj)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 231, in send
    self._send_bytes(memoryview(buf))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 299, in _send_bytes
    overlapped = win32.WriteFile(self._handle, buf, overlapped=True)
IOError: [Errno 232] The pipe is being closed
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\queues.py", line 267, in _feed
    send(obj)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 231, in send
    self._send_bytes(memoryview(buf))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\multiprocessing\connection.py", line 299, in _send_bytes
    overlapped = win32.WriteFile(self._handle, buf, overlapped=True)
IOError: [Errno 232] The pipe is being closed
Warning -- threading._dangling was modified by test_concurrent_futures
test test_concurrent_futures failed
0.01s ok

======================================================================
FAIL: test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_concurrent_futures.py", line 109, in test_interpreter_shutdown
    self.assertFalse(err)
AssertionError: b'Traceback (most recent call last):\n  File "D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\multiprocessing\\queues.py", line 267, in _feed\n    send(obj)\n  File "D:\\cygwin\\home\\db3l\\buildarea\\3.x.bolen-windows\\build\\lib\\multiprocessing\\connection.py", line 231, in send' is not false

----------------------------------------------------------------------
Ran 59 tests in 133.632s

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/5243/steps/test/logs/stdio

----------
components: Library (Lib)
messages: 144612
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:07:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 19:07:34 +0000
Subject: [issue13063] test_concurrent_futures failures on Windows:
	IOError('[Errno 232] The pipe is being closed') on _send_bytes()
In-Reply-To: <1317323234.29.0.73593324718.issue13063@psf.upfronthosting.co.za>
Message-ID: <1317323254.27.0.26220733333.issue13063@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

See also issue #13059.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:07:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 19:07:40 +0000
Subject: [issue13059] Sporadic test_multiprocessing failure: IOError("bad
	message length") in recv_bytes()
In-Reply-To: <1317300485.05.0.349182962077.issue13059@psf.upfronthosting.co.za>
Message-ID: <1317323260.95.0.554571758177.issue13059@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

See also issue #13063.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:12:33 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 29 Sep 2011 19:12:33 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317323553.6.0.180288234079.issue13062@psf.upfronthosting.co.za>


Changes by Eric Snow :


----------
nosy: +eric.snow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:17:28 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Sep 2011 19:17:28 +0000
Subject: [issue13061] Decimal module yields incorrect results when Python
	compiled with llvm
In-Reply-To: <1317317264.78.0.478675633552.issue13061@psf.upfronthosting.co.za>
Message-ID: <1317323848.85.0.891020125538.issue13061@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

> Possibly related to http://bugs.python.org/issue11149?

Maybe I missed it in the links you gave, but that is easily
settled by compiling with and without -fwrapv.

----------
nosy: +skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:17:32 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 19:17:32 +0000
Subject: [issue3130] In some UCS4 builds,
	sizeof(Py_UNICODE) could end up being more than 4.
In-Reply-To: <1213695549.9.0.858416360908.issue3130@psf.upfronthosting.co.za>
Message-ID: <1317323852.7.0.63229438099.issue3130@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

The PEP 393 has been accepted: strings are now stored as PyUCS1*, PyUCS2* or PyUCS4*. The Py_UNICODE type still exist but is deprecated, and only used in the legacy API. Py_UNICODE is now always the wchar_t type, it cannot be unsigned int anymore. I hope that no platform chose to use wchar_t larger than 32 bits. Let' close this issue.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.3 -Python 2.6, Python 3.0

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:18:01 2011
From: report at bugs.python.org (Arne Babenhauserheide)
Date: Thu, 29 Sep 2011 19:18:01 +0000
Subject: [issue13060] allow other rounding modes in round()
In-Reply-To: <1317309410.46.0.106397423857.issue13060@psf.upfronthosting.co.za>
Message-ID: <1317323881.88.0.563560010014.issue13060@psf.upfronthosting.co.za>


Arne Babenhauserheide  added the comment:

cdecimal sounds great! when is it scheduled for inclusion?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:30:06 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 29 Sep 2011 19:30:06 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1317324606.74.0.832342205093.issue7652@psf.upfronthosting.co.za>


Changes by Eric Snow :


----------
nosy: +eric.snow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:37:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 29 Sep 2011 19:37:55 +0000
Subject: [issue13054] sys.maxunicode value after PEP-393
In-Reply-To: <1317224855.38.0.863349241023.issue13054@psf.upfronthosting.co.za>
Message-ID: <1317325075.95.0.46211850795.issue13054@psf.upfronthosting.co.za>


Antoine Pitrou  added the comment:

I think there's no point in deprecating a function (or data) with a perfectly valid definition.
As for test_bigmem, better keep character_size hardwired to 1 (if all tests really use only ASCII chars, which I'm not sure they do).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:38:11 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 19:38:11 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1317325091.26.0.265860437493.issue8654@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

The PEP 393 has been accepted. There is no more narrow or wide build, Py_UNICODE is now always wchar_t.

We have also a stable ABI which doesn't depend on the internal stucture of Unicode strings.

In Python 3.2, the name of dynamic libraries is also different if the module was compiled in narrow or wide mode. See the PEP 3149.

I think that it is enough. Can we close the issue?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:39:30 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 29 Sep 2011 19:39:30 +0000
Subject: [issue8654] Improve ABI compatibility between UCS2 and UCS4 builds
In-Reply-To: <1273258965.02.0.175407225836.issue8654@psf.upfronthosting.co.za>
Message-ID: <1317325170.94.0.820998090966.issue8654@psf.upfronthosting.co.za>


Daniel Stutzbach  added the comment:

Gladly. :-)

----------
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:42:56 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Thu, 29 Sep 2011 19:42:56 +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: <1317325376.31.0.678480783724.issue4489@psf.upfronthosting.co.za>


Ross Lagerwall  added the comment:

Updated patch based on Eric's comments:
 Store _supports_safe_rmdir at the module level.
 Move imports up to module level
 Skip test on non-threading build

----------
Added file: http://bugs.python.org/file23261/i4489_v4.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:45:30 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Sep 2011 19:45:30 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <1317325530.84.0.822322744211.issue13057@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

To me this looks like stdio.h should be included as well. Could
you try the patch?

----------
keywords: +patch
Added file: http://bugs.python.org/file23262/issue-13057.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:45:45 2011
From: report at bugs.python.org (Joshua Bleecher Snyder)
Date: Thu, 29 Sep 2011 19:45:45 +0000
Subject: [issue13061] Decimal module yields incorrect results when Python
	compiled with llvm
In-Reply-To: <1317317264.78.0.478675633552.issue13061@psf.upfronthosting.co.za>
Message-ID: <1317325545.27.0.939472210566.issue13061@psf.upfronthosting.co.za>


Joshua Bleecher Snyder  added the comment:

>> Possibly related to http://bugs.python.org/issue11149?

> Maybe I missed it in the links you gave, but that is easily
> settled by compiling with and without -fwrapv.

Apologies -- I didn't do enough homework on this one. Yes, I can confirm that compiling with -fwrapv solves this issue. Not sure whether that makes this bug a straight duplicate of http://bugs.python.org/issue11149...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:49:55 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 19:49:55 +0000
Subject: [issue2799] Remove _PyUnicode_AsString(),
	rework _PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()
In-Reply-To: <1210329112.66.0.505096173761.issue2799@psf.upfronthosting.co.za>
Message-ID: <1317325795.36.0.924871283987.issue2799@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

The PEP 393 changed the API:

#define _PyUnicode_AsString PyUnicode_AsUTF8
#define _PyUnicode_AsStringAndSize PyUnicode_AsUTF8AndSize

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 21:52:00 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Sep 2011 19:52:00 +0000
Subject: [issue13061] Decimal module yields incorrect results when Python
	compiled with llvm
In-Reply-To: <1317317264.78.0.478675633552.issue13061@psf.upfronthosting.co.za>
Message-ID: <1317325920.66.0.800147461811.issue13061@psf.upfronthosting.co.za>


Changes by Ned Deily :


----------
nosy: +ned.deily

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:03:47 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 20:03:47 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1317326627.83.0.21763814422.issue1943@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

The PEP 393 is based on the idea proposed in this issue (use only one memory block, not two), but also enhanced it to reduce more the memory using other technics:

 - use a different character type depending on the maximum character,
 - use a shorter structure for ASCII only strings

The PEP 393 has been accepted and merged into Python 3.3. So I consider this issue as done.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:06:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 20:06:08 +0000
Subject: [issue7330] PyUnicode_FromFormat: implement width and precision for
	%s, %S, %R, %V, %U, %A
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1317326768.85.0.764648238905.issue7330@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

Hum, the issue is still open, I will try to review it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:10:05 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 20:10:05 +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: <1317327005.15.0.408024800347.issue11574@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: Unicode Fallback Encoding on Python 3.3 -> TextIOWrapper: Unicode Fallback Encoding on Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:13:29 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 20:13:29 +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: <1317327209.86.0.471442361734.issue12632@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: Windows GPF with Code Page 65001 -> Python 3 doesn't support cp65001 as the OEM code page

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:13:59 2011
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 29 Sep 2011 20:13:59 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317327239.67.0.862524105834.issue12242@psf.upfronthosting.co.za>


Roumen Petrov  added the comment:

What is result is i use GNU compiler by example with name arm-linux-androideabi-gcc  ?

----------
nosy: +rpetrov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:20:00 2011
From: report at bugs.python.org (Eli Collins)
Date: Thu, 29 Sep 2011 20:20:00 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317327600.7.0.80930207303.issue12242@psf.upfronthosting.co.za>


Changes by Eli Collins :


Added file: http://bugs.python.org/file23263/ca53ff77ce6f.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:21:51 2011
From: report at bugs.python.org (Eli Collins)
Date: Thu, 29 Sep 2011 20:21:51 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317327711.02.0.801177112306.issue12242@psf.upfronthosting.co.za>


Eli Collins  added the comment:

Attached is a fourth revision (ca53ff77ce6f.diff). This covers the typos identified in the last review, but I'm submitting a new patch because I  ran a quick proofreading regexp, and identified a few more formatting mistakes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:24:00 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 20:24:00 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1317327840.58.0.587426968116.issue10542@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

The PEP 393 has been accepted and merge into Python 3.3. Python 3.3 doesn't need the Py_UNICODE_NEXT macro anymore. But my macros (unicode_macros.patch) are still useful.

----------
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:25:01 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 20:25:01 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1317327901.17.0.104520839786.issue10521@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

This issue has been fixed in Python 3.3 thanks to the PEP 393.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:27:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 20:27:14 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>
Message-ID: <1317328034.99.0.648302692973.issue10542@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Py_UNICODE_NEXT has been removed from 3.3 but it's still available and used in 2.7/3.2 (even if it's private).  In order to fix #10521 on 2.7/3.2 the _Py_UNICODE_PUT_NEXT macro attached to this patch is required.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:28:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 20:28:19 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1317328099.1.0.357889586701.issue10521@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

It can still be fixed on 2.7/3.2 though.

----------
versions: +Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:31:15 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 20:31:15 +0000
Subject: [issue12819] PEP 393 - Flexible Unicode String Representation
In-Reply-To: <1314039095.43.0.38343392107.issue12819@psf.upfronthosting.co.za>
Message-ID: <1317328275.76.0.374976966071.issue12819@psf.upfronthosting.co.za>


STINNER Victor  added the comment:

PEP 393 has been accepted and merged into Python 3.3.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:32:10 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 20:32:10 +0000
Subject: [issue12819] PEP 393 - Flexible Unicode String Representation
In-Reply-To: <1314039095.43.0.38343392107.issue12819@psf.upfronthosting.co.za>
Message-ID: <1317328330.6.0.545866247109.issue12819@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
stage: patch review -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:32:23 2011
From: report at bugs.python.org (Eli Collins)
Date: Thu, 29 Sep 2011 20:32:23 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317328343.55.0.0676686977721.issue12242@psf.upfronthosting.co.za>


Eli Collins  added the comment:

> What is result is i use GNU compiler by example with name arm-linux-androideabi-gcc  ?

If the executable is named "arm-linux-androideabi-gcc", the code would currently call "arm-linux-androideabi-gcc --version". If that resulted in (for example) "arm-linux-androideabi-gcc (Some/Platform 4.5.2-1) 4.5.2", then the version string returned for regexp matching would be "arm-linux-androideabi-gcc 4.5.2".

While the patch was getting close to finished, if it seems like a useful idea to people, I could add a "--get-compiler-info" command to build_ext which would return the name of the active compiler, and the output of get_compiler_version().

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:40:31 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 29 Sep 2011 20:40:31 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317328831.51.0.156802651703.issue13062@psf.upfronthosting.co.za>


Meador Inge  added the comment:

I'll take a shot and writing a patch for this one.  Nick, are the 
elements in 'co_freevars' and '__closures__' always expected to match
up?  In other words, is the 'closure' function below always expected to 
work (simplified; no error checking):

>>> def make_adder(x):
...     def add(y):
...         return x + y
...     return add
... 
>>> def curry(func, arg1):
...     return lambda arg2: func(arg1, arg2)
... 
>>> def less_than(a, b):
...     return a < b
... 
>>> greater_than_five = curry(less_than, 5)
>>> def closure(func):
...     vars = [var for var in func.__code__.co_freevars]
...     values = [cell.cell_contents for cell in func.__closure__]
...     return dict(zip(vars, values))
...
>>> inc = make_adder(1)
>>> print(closure(inc))
{'x': 1}
>>> print(closure(greater_than_five))
{'arg1': 5, 'func': }

?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:41:39 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 29 Sep 2011 20:41:39 +0000
Subject: [issue13061] Decimal module yields incorrect results when Python
	compiled with llvm
In-Reply-To: <1317317264.78.0.478675633552.issue13061@psf.upfronthosting.co.za>
Message-ID: <1317328899.17.0.601631314072.issue13061@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

It's more a straight duplicate of #12973, but the underlying cause
(signed integer overflow) is the same. For people who are finding
this via a search engine: A lot of bugs have been fixed in #12973,
but even if the test suite passes without -fwrapv it is *still* recommended to use -fwrapv.


Could anyone test if the attached patch works for llvm-gcc?

----------
keywords: +patch
Added file: http://bugs.python.org/file23265/llvm-gcc-fwrapv.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:54:04 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 29 Sep 2011 20:54:04 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317329644.79.0.613051731515.issue13062@psf.upfronthosting.co.za>


Eric Snow  added the comment:

See:
http://hg.python.org/cpython/file/default/Include/funcobject.h#l34
http://hg.python.org/cpython/file/default/Objects/funcobject.c#l454


   454 /* func_new() maintains the following invariants for closures.  The
   455    closure must correspond to the free variables of the code object.
   456 
   457    if len(code.co_freevars) == 0:
   458        closure = NULL
   459    else:
   460        len(closure) == len(code.co_freevars)
   461    for every elt in closure, type(elt) == cell
   462 */

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 22:55:36 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 29 Sep 2011 20:55:36 +0000
Subject: [issue13061] Decimal module yields incorrect results when Python
	compiled with llvm
In-Reply-To: <1317317264.78.0.478675633552.issue13061@psf.upfronthosting.co.za>
Message-ID: <1317329736.95.0.551034140643.issue13061@psf.upfronthosting.co.za>


Changes by Mark Dickinson :


----------
nosy: +mark.dickinson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 23:09:08 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Sep 2011 21:09:08 +0000
Subject: [issue13064] Port codecs and error handlers to the new Unicode API
Message-ID: <1317330548.17.0.268887391547.issue13064@psf.upfronthosting.co.za>


New submission from STINNER Victor :

We really need a new API for error handlers, using Python objects instead of Py_UNICODE* strings, and using code point indexes instead of UTF-16 unit indexes (index in the Py_UNICODE* object). It's also inefficient to encode to Py_UNICODE at the first encode/decode error.

I added private APIs, we may make them public:

 * _PyUnicode_AsASCIIString()
 * _PyUnicode_AsLatin1String()
 * _PyUnicode_AsUTF8String()

--

Martin answered me by mail:

Would you like to work on this? Some thoughts:

- encoding error handlers are easier than decoding, since the encoding
  error API uses Py_UNICODE* for almost no good reason (except to pass
  substrings into the exception object, which is better done with
  PyUnicode_Substring). Decoding has the issue that the error handler
  may produce a replacement string which then needs to be inserted into
  the output.

- for decoding, I suggest to duplicate the error handling utility
  function, into one that operates on Unicode objects only. Then port
  one codec at a time, and ultimately remove the then-unused Py_UNICODE
  function.

- adding an error handler result into a string may cause widening of the
  string. I can see two approaches:

  a) write decoders in Py_UCS4. This is perhaps best for the rarely-used
     codecs, such as UTF-7.
  b) write the codecs so that they do incremental widening. Start off
     with a Py_UCS1 buffer, and check each decoded character whether it
     is out of range. When you get an error handler result, check
     maxchar and widen the result accordingly.
  c) in principle, there is a third approach: run over the string once,
     collect all error handler results. Then allocate the output string,
     decode again, pasting the replacement strings into the output
     interleaved with regular decoded chars. This seems too complicated
     to implement.

----------
components: Unicode
messages: 144639
nosy: haypo
priority: normal
severity: normal
status: open
title: Port codecs and error handlers to the new Unicode API
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 23:11:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 21:11:46 +0000
Subject: [issue13064] Port codecs and error handlers to the new Unicode API
In-Reply-To: <1317330548.17.0.268887391547.issue13064@psf.upfronthosting.co.za>
Message-ID: <1317330706.06.0.0648528466253.issue13064@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 23:14:23 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Sep 2011 21:14:23 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317330863.87.0.76984913408.issue13062@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

Yep, that looks right to me. The eval loop then references those cells from the frame object during execution.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 29 23:18:51 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 29 Sep 2011 21:18:51 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317331131.14.0.42191726496.issue13062@psf.upfronthosting.co.za>


Nick Coghlan  added the comment:

Huh, I didn't actually realise getclosure() could be written as a one liner until seeing Meador's version above:

  {var : cell.cell_contents for var, cell in zip(func.__code__.co_freevars, func.__closure__)}

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:18:08 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:18:08 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1317334688.44.0.476609284698.issue2771@psf.upfronthosting.co.za>


Victor Semionov  added the comment:

Testing.

----------
nosy: +vsemionov

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:19:22 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:19:22 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1317334762.33.0.989114165197.issue2771@psf.upfronthosting.co.za>


Victor Semionov  added the comment:

testing

----------
Added file: http://bugs.python.org/file23266/test.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:20:17 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:20:17 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1317334817.06.0.368441801329.issue2771@psf.upfronthosting.co.za>


Victor Semionov  added the comment:

adsfaf

----------
hgrepos: +78

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:20:30 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:20:30 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1317334830.98.0.287562891693.issue2771@psf.upfronthosting.co.za>


Changes by Victor Semionov :


----------
hgrepos:  -78

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:22:23 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 22:22:23 +0000
Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only)
In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za>
Message-ID: <1317334943.53.0.994493672259.issue11489@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

RFC 4627 doesn't say much about lone surrogates:
   A string is a sequence of zero or more Unicode characters [UNICODE].
   [...]

   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).

   Any character may be escaped.  If the character is in the Basic
   Multilingual Plane (U+0000 through U+FFFF), then it may be
   represented as a six-character sequence: a reverse solidus, followed
   by the lowercase letter u, followed by four hexadecimal digits that
   encode the character's code point.  The hexadecimal letters A though
   F can be upper or lowercase.  So, for example, a string containing
   only a single reverse solidus character may be represented as
   "\u005C".
   [...]

   To escape an extended character that is not in the Basic Multilingual
   Plane, the character is represented as a twelve-character sequence,
   encoding the UTF-16 surrogate pair.  So, for example, a string
   containing only the G clef character (U+1D11E) may be represented as
   "\uD834\uDD1E".


Raymond> JSON is UTF-8 by definition and it is a useful feature that invalid UTF-8 won't load.

Even if the input strings are not encodable in UTF-8 because they contain lone surrogates, they can still be converted to an \uXXXX escape, and the resulting JSON document will be valid UTF-8.
AFAIK json always uses \uXXXX, so it doesn't produce invalid UTF-8 documents.

While decoding, both json.loads('"\xed\xa0\x80"') and json.loads('"\ud800"') result in u'\ud800', but the first is not a valid UTF-8 document because it contains an invalid UTF-8 byte sequence that represent a lone surrogate, whereas the second one contains only ASCII bytes and it's therefore valid.
Python 2.7 should probably reject '"\xed\xa0\x80"', but since its UTF-8 codec is somewhat permissive already, I'm not sure it makes much sense changing the behavior now.  Python 3 doesn't have this problem because it works only with unicode strings, so you can't pass invalid UTF-8 byte sequences.

OTOH the Unicode standard says that lone surrogates shouldn't be passed around, so we might decide to replace them with the replacement char U+FFFD, raise an error, or even provide a way to decide what should be done with them (something like the errors argument of codecs).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:25:52 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:25:52 +0000
Subject: [issue13065] test
Message-ID: <1317335152.37.0.143552991068.issue13065@psf.upfronthosting.co.za>


New submission from Victor Semionov :

ignore me

----------
messages: 144647
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:26:51 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:26:51 +0000
Subject: [issue13065] test
In-Reply-To: <1317335152.37.0.143552991068.issue13065@psf.upfronthosting.co.za>
Message-ID: <1317335211.42.0.459785159742.issue13065@psf.upfronthosting.co.za>


Changes by Victor Semionov :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:27:34 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:27:34 +0000
Subject: [issue13066] test
Message-ID: <1317335254.91.0.776015122181.issue13066@psf.upfronthosting.co.za>


New submission from Victor Semionov :

ignore me

----------
components: IO, Interpreter Core
messages: 144648
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:27:57 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:27:57 +0000
Subject: [issue13066] test
In-Reply-To: <1317335254.91.0.776015122181.issue13066@psf.upfronthosting.co.za>
Message-ID: <1317335277.66.0.685058968182.issue13066@psf.upfronthosting.co.za>


Changes by Victor Semionov :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:29:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 22:29:13 +0000
Subject: [issue13065] test
In-Reply-To: <1317335152.37.0.143552991068.issue13065@psf.upfronthosting.co.za>
Message-ID: <1317335353.45.0.476751850556.issue13065@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:29:31 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 22:29:31 +0000
Subject: [issue13066] test
In-Reply-To: <1317335254.91.0.776015122181.issue13066@psf.upfronthosting.co.za>
Message-ID: <1317335371.3.0.913529166059.issue13066@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:30:06 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:30:06 +0000
Subject: [issue13067] test
Message-ID: <1317335405.74.0.519394753326.issue13067@psf.upfronthosting.co.za>


New submission from Victor Semionov :

ignore me

----------
components: IO, Interpreter Core
files: backtrace
messages: 144651
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file23269/backtrace

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:30:33 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:30:33 +0000
Subject: [issue13067] test
In-Reply-To: <1317335405.74.0.519394753326.issue13067@psf.upfronthosting.co.za>
Message-ID: <1317335433.31.0.502801269026.issue13067@psf.upfronthosting.co.za>


Changes by Victor Semionov :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:31:14 2011
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Sep 2011 22:31:14 +0000
Subject: [issue13061] Decimal module yields incorrect results when Python
	compiled with llvm
In-Reply-To: <1317317264.78.0.478675633552.issue13061@psf.upfronthosting.co.za>
Message-ID: <1317335474.41.0.436825553384.issue13061@psf.upfronthosting.co.za>


Ned Deily  added the comment:

There is some confusion here, I think. As best as I can tell, the original problem reported in the Stackoverflow question and to MacPorts involved using the clang compiler, not llvm-gcc and the Decimal problem reported here was only ever a problem when using clang.  It's not an issue when using Apple's llvm-gcc compiler because the pre-#11149 configure test works properly with llvm-gcc.  That test looks for "-fwrapv" in the compiler help string:

$ llvm-gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ llvm-gcc -v --help 2>/dev/null | grep -- -fwrapv
  -fwrapv                     Assume signed arithmetic overflow wraps around
$ gcc-4.2 --version
i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-4.2 -v --help 2>/dev/null | grep -- -fwrapv
  -fwrapv                     Assume signed arithmetic overflow wraps around
$ clang --version
Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.1.0
Thread model: posix
$ clang -v --help 2>/dev/null | grep -- -fwrapv

The above was using the 3 Apple-supplied compilers with the OS X 10.7 (Lion) version of Xcode 4.1 (Build version 4B110).  The 10.6 compiler versions should work the same way.

So this issue should be closed as a duplicate of Issue11149.  I'm setting it to pending and will close it if there are no objections.

----------
resolution:  -> duplicate
status: open -> pending
superseder:  -> [PATCH] Configure should enable -fwrapv for clang

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:31:24 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:31:24 +0000
Subject: [issue13068] test
Message-ID: <1317335484.04.0.337799871347.issue13068@psf.upfronthosting.co.za>


New submission from Victor Semionov :

ignore me

----------
messages: 144654
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
type: crash

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:31:45 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:31:45 +0000
Subject: [issue13068] test
In-Reply-To: <1317335484.04.0.337799871347.issue13068@psf.upfronthosting.co.za>
Message-ID: <1317335505.87.0.30826056748.issue13068@psf.upfronthosting.co.za>


Changes by Victor Semionov :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:39:24 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 22:39:24 +0000
Subject: [issue13069] test
Message-ID: <1317335964.94.0.450772671281.issue13069@psf.upfronthosting.co.za>


New submission from Ezio Melotti :

Testing issue creation

----------
hgrepos: 83
messages: 144655
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: test

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:41:14 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 22:41:14 +0000
Subject: [issue13069] test
In-Reply-To: <1317335964.94.0.450772671281.issue13069@psf.upfronthosting.co.za>
Message-ID: <1317336074.25.0.994489237609.issue13069@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:42:47 2011
From: report at bugs.python.org (Victor Semionov)
Date: Thu, 29 Sep 2011 22:42:47 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
Message-ID: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>


New submission from Victor Semionov :

Hello,

I'm developing a multi-threaded TCP server and have been seeing segmentation faults on 3.2 on Linux and 3.2.2 on Windows. This happens when using only pure-Python libraries, so I believe the problem is in the interpreter. The issue is very easy to reproduce with my code, but I think it is obscure, because I have not been able to reproduce it with a smaller program.

Here's what happens. The server accepts TCP connections, and creates a thread for every new connection. When the client sends a request, the server initiates its own TCP connection to a database. If any socket IO operation fails by raising a socket error (e.g. the database is down), those errors are caught by the calling code, and it gracefully terminates the thread. However, when the next client connects and sends a request, even if the server-initiated connections are successfully established, the interpreter crashes a bit later during the processing of the client's request (I think during IO operations).

Strangely, this does not occur if the thread recovers and does not terminate after catching an exception (as the case with failed redis connections). Also, I was able to port my program to python 2.7, and it did not crash.

To reproduce, you will need pg8000, which is a pure-python dbapi driver. You will need to get my program, wordbase, from the mercurial repository at https://bitbucket.org/vsemionov/wordbase (changeset 31c6554e67ee) and edit src/wordbase/db/pgsql.py. Change "import psycopg2 as dbapi" to "import pg8000.dbapi as dbapi". This is just to ensure that no C-based library is used. Steps to reproduce:
0. Ensure postgres is not running
1. Start wordbase with src/wordbase/wordbase.py -f . Use the path to the provided sample conf file at src/wordbase/wordbase.conf. By default you'll need to be root, in order to be able to create a log file.
2. Connect a client with "telnet localhost 2628" and enter "d hello". This should fail with status 420. Reconnect and repeat the same step a couple of times. The interpreter usually crashes after repeating this step.

I'm providing the interpreter's backtrace, which is obtained from Python 3.2 on Linux. It is attached in a separate file.

If you need any other information, please let me know.

Best regards,
Victor Semionov

----------
components: IO, Interpreter Core
files: backtrace
messages: 144656
nosy: vsemionov
priority: normal
severity: normal
status: open
title: segmentation fault in pure-python multi-threaded server
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file23270/backtrace

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:53:34 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 22:53:34 +0000
Subject: [issue13068] test
In-Reply-To: <1317335484.04.0.337799871347.issue13068@psf.upfronthosting.co.za>
Message-ID: <1317336814.46.0.242177910717.issue13068@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 00:53:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 22:53:50 +0000
Subject: [issue13067] test
In-Reply-To: <1317335405.74.0.519394753326.issue13067@psf.upfronthosting.co.za>
Message-ID: <1317336830.59.0.0082609915561.issue13067@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 01:05:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 29 Sep 2011 23:05:12 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1317337512.77.0.837458267324.issue3232@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 02:05:22 2011
From: report at bugs.python.org (jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal)
Date: Fri, 30 Sep 2011 00:05:22 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
Message-ID: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>


New submission from jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal :

I have tried all ways of opening IDLE and have uninstalled and reinstalled Python, but when I try to open it it crashes before anything happens

----------
components: IDLE
messages: 144657
nosy: jfalskfjdsl;akfdjsa;l.laksfj;aslkfdj;sal
priority: normal
severity: normal
status: open
title: IDLE refuses to open on windows 7
type: crash
versions: Python 3.2

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 02:09:50 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Sep 2011 00:09:50 +0000
Subject: [issue13072] Getting a buffer from a Unicode array uses invalid format
Message-ID: <1317341390.65.0.255779328054.issue13072@psf.upfronthosting.co.za>


New submission from STINNER Victor :

In Python 3.2, when you get a buffer from array.array('u'), "u" is used as buffer format. The format is supposed to be a format from the struct module, and "u" is an invalid struct format. "w" is used on wide mode.

I just upgraded the array module to use the new Unicode API (PEP 393). The array now uses a Py_UCS4 buffer. I used "I" or "L" format depending on the size of int and long C types.

It would be better to use a format for a Py_UCS4 string, but struct doesn't support such type.

For Python 2.7 and 3.2, I don't know if it is really a bug or not.

----------
components: Library (Lib)
messages: 144658
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Getting a buffer from a Unicode array uses invalid format
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 02:29:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 00:29:07 +0000
Subject: [issue13071] IDLE refuses to open on windows 7
In-Reply-To: <1317341122.37.0.866117748717.issue13071@psf.upfronthosting.co.za>
Message-ID: <1317342547.81.0.590429497271.issue13071@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Try to open cmd (win+r -> type 'cmd' -> press enter), cd in the Python directory and do "python.exe Lib\idlelib\idle.py".
If that doesn't work it should give you a traceback.  Once you get the traceback copy/paste it here, so we can figure out what's going on.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 05:33:25 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 03:33:25 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <1317325530.84.0.822322744211.issue13057@psf.upfronthosting.co.za>
Message-ID: <02EA6D704E30CE499C5071776509A925F5A720@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

Hello Stefan,

Hmm..... how do I apply the patch? I download the issue-13057.diff file and then.....? 

Regards,
Wah Meng

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 05:36:43 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 03:36:43 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <1313102254.23.0.17412568785.issue12737@psf.upfronthosting.co.za>
Message-ID: <1317353803.72.0.585410325489.issue12737@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

After PEP 393 the result is still the same (I attached a slightly improved version of the script):

titlecase of  'deme un cafe'  should be  'Deme Un Cafe'  not  'DeMe Un Cafe'
titlecase of  'istanbul'  should be  'Istanbul'  not  'IStanbul'
titlecase of  '? ??? ??????'  should be  '? ??? ??????'  not  '?? ??? ??????'
failed 3 out of 6 tests

Martin, do you think that str.title() should follow the Unicode standard?
Should string methods work with all the normalizations or just with NFC?

----------
Added file: http://bugs.python.org/file23271/titletest.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 06:04:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 04:04:16 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <1317355456.14.0.239502833388.issue13057@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

"patch -p1 < issue-13057.diff" in the directory where configure is should do the trick.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 06:05:13 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 04:05:13 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1317355513.26.0.479319861228.issue12731@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

The failing re tests after PEP 393 are:
FAIL lib re found non alphanumeric string  'cafe'
FAIL lib re found non alphanumeric string  '?'
FAIL lib re found non alphanumeric string  ''
FAIL lib re found non alphanumeric string  ''
FAIL lib re found non alphanumeric string  'connector?punctuation'
FAIL lib re found non alphanumeric string  '?_???_??????'
FAIL lib re found non alphanumeric string  '????????????????????????'
FAIL lib re found all alphanumeric string  '???'
FAIL lib re found all alphanumeric string  '???'
FAIL lib re found all alphanumeric string  '???'
FAIL lib re found all alphanumeric string  '?'

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 06:16:02 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 04:16:02 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <1317355456.14.0.239502833388.issue13057@psf.upfronthosting.co.za>
Message-ID: <02EA6D704E30CE499C5071776509A925F5A7BF@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

I tried.... here is the outcome. It says it can't find a patch??

$ cat issue-13057.diff
diff -r f612b783bc17 configure
--- a/configure Thu Sep 29 07:52:46 2011 +0800
+++ b/configure Thu Sep 29 21:39:32 2011 +0200
@@ -8619,6 +8619,7 @@
     cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 #include 
+#include 

 void * start_routine (void *arg) { exit (0); }
 int

$ patch -p1 < issue-13057.diff
Hmm...  I can't seem to find a patch in there anywhere.
$ pwd
/home/r32813/Build/2.7.1/Python-2.7.1
$

Regards,
Wah Meng

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 06:20:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 04:20:40 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <1317356440.8.0.456297131472.issue13057@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

If that's a Mercurial clone of Python you can try "hg import --no-commit issue-13057.diff".  Otherwise you could just edit configure manually -- the attached patch is trivial.  You could also install "patch".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 06:38:17 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 04:38:17 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <1317356440.8.0.456297131472.issue13057@psf.upfronthosting.co.za>
Message-ID: <02EA6D704E30CE499C5071776509A925F5A7D9@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

Mercurial clone of python? Haha I am not sure what that is. My unix also won't recognize "hg", and will ignore "import --no-commit issue-13057.diff".

I went ahead to edit configure file. Partially understanding the content of .diff file, I edited the configure and here is the difference...

I will try to rebuild now...

$ diff configure.original configure
8619a8620,8624
>  #include 
>  +#include 
> 
>   void * start_routine (void *arg) { exit (0); }
>    int
$ 

Regards,
Wah Meng

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 07:23:51 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 05:23:51 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <02EA6D704E30CE499C5071776509A925F5A87E@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

Hello,

I tried rebuild but it is still the same. :( Attached is the extract of the modified configure file, with line number at the side (from VI editor). Basically my changes are added as from line 8620 through 8624. I am not sure if this is meant to be, just my best guess from the patch file. Appreciate your advice. 

  8612  $as_echo_n "checking for pthread_create in -lpthreads... " >&6; }
  8613  if test "${ac_cv_lib_pthreads_pthread_create+set}" = set; then :
  8614    $as_echo_n "(cached) " >&6
  8615  else
  8616    ac_check_lib_save_LIBS=$LIBS
  8617  LIBS="-lpthreads  $LIBS"
  8618  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
  8619  /* end confdefs.h.  */
  8620   #include 
  8621   +#include 
  8622
  8623    void * start_routine (void *arg) { exit (0); }
  8624     int
  8625
  8626  /* Override any GCC internal prototype to avoid an error.
  8627     Use char because int might match the return type of a GCC
  8628     builtin and then its argument prototype would still apply.  */
  8629  #ifdef __cplusplus
  8630  extern "C"
  8631  #endif

Regards,
Wah Meng
Genesis Wafermap Support Ticket: 
To report a problem: http://dyno.freescale.net/Question/QuestionMain3.asp?location=zmy02&category=&tickettype=6820
To request a service: http://dyno.freescale.net/Question/Questionmain3.asp?location=74&category=2&tickettype=6819
Or if it is related to EWM or DSA: http://dyno.freescale.net/Question/Questionmain3.asp?location=ZMY02&tickettype=6539

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 07:29:29 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 05:29:29 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <1317360569.31.0.926246580939.issue13057@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

You just have to add:
#include 

just after:
#include 

The + in the diff only means that the line was added and shouldn't be included in the file.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 07:41:45 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 05:41:45 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <1317360569.31.0.926246580939.issue13057@psf.upfronthosting.co.za>
Message-ID: <02EA6D704E30CE499C5071776509A925F5A8BC@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

Thank goodness. Let me try. 

Regards,
Wah Meng
Genesis Wafermap Support Ticket: 
To report a problem: http://dyno.freescale.net/Question/QuestionMain3.asp?location=zmy02&category=&tickettype=6820
To request a service: http://dyno.freescale.net/Question/Questionmain3.asp?location=74&category=2&tickettype=6819
Or if it is related to EWM or DSA: http://dyno.freescale.net/Question/Questionmain3.asp?location=ZMY02&tickettype=6539

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 07:45:02 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 05:45:02 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <02EA6D704E30CE499C5071776509A925F5A8CA@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

Sorry, there a more than one entry of "#include " in configure file. So do I inject everywhere? 

Regards,
Wah Meng
Genesis Wafermap Support Ticket: 
To report a problem: http://dyno.freescale.net/Question/QuestionMain3.asp?location=zmy02&category=&tickettype=6820
To request a service: http://dyno.freescale.net/Question/Questionmain3.asp?location=74&category=2&tickettype=6819
Or if it is related to EWM or DSA: http://dyno.freescale.net/Question/Questionmain3.asp?location=ZMY02&tickettype=6539

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 07:46:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 05:46:00 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <1317361560.34.0.407038748832.issue13057@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

After the one at line 8620.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 08:04:27 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 06:04:27 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <02EA6D704E30CE499C5071776509A925F5A8E8@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

Wow..... I added it everywhere in the file. I love you!! (Ermm... I mean, literally)

It can work now. :). I will move on to migrate my application with this new python. Hopefully I don't see other modules breaking. 

Thanks for the GREAT helps!!! :) 

$ python
Python 2.7.1 (r271:86832, Sep 27 2011, 15:19:26) [C] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>> import thread
>>> def test():
...   print "Hello World"
... 
>>> thread.start_new_thread(test,())
2
>>> Hello World

Regards,
Wah Meng
Genesis Wafermap Support Ticket: 
To report a problem: http://dyno.freescale.net/Question/QuestionMain3.asp?location=zmy02&category=&tickettype=6820
To request a service: http://dyno.freescale.net/Question/Questionmain3.asp?location=74&category=2&tickettype=6819
Or if it is related to EWM or DSA: http://dyno.freescale.net/Question/Questionmain3.asp?location=ZMY02&tickettype=6539

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 08:08:11 2011
From: report at bugs.python.org (Arnaud Fontaine)
Date: Fri, 30 Sep 2011 06:08:11 +0000
Subject: [issue12776] argparse: type conversion function should be called only
	once
In-Reply-To: <1313657878.1.0.958946060112.issue12776@psf.upfronthosting.co.za>
Message-ID: <1317362891.04.0.824415535631.issue12776@psf.upfronthosting.co.za>


Arnaud Fontaine  added the comment:

Any news about applying these patches?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 08:10:17 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 30 Sep 2011 06:10:17 +0000
Subject: [issue12797] io.FileIO and io.open should support openat
In-Reply-To: <1313874003.0.0.755289779326.issue12797@psf.upfronthosting.co.za>
Message-ID: <1317363017.16.0.548918099268.issue12797@psf.upfronthosting.co.za>


Ross Lagerwall  added the comment:

Attached is a patch which adds dirfd= as a keyword argument.

----------
keywords: +patch
Added file: http://bugs.python.org/file23272/i12797.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 08:33:14 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 30 Sep 2011 06:33:14 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <1317364394.66.0.837213000114.issue13057@psf.upfronthosting.co.za>


Georg Brandl  added the comment:

Could you please stop putting these unrelated links into your posts? It is really annoying. Thanks.

----------
nosy: +georg.brandl

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 10:09:03 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 30 Sep 2011 08:09:03 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
Message-ID: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>


New submission from Petri Lehtinen :

The argument is essential to avoid slowdown with delayed ACKs and the Nagle algorithm, so it should be documented. It was added when fixing issue 4336. I believe that it's new in Python 2.7.

----------
assignee: docs at python
components: Documentation
messages: 144676
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
stage: needs patch
status: open
title: message_body argument of HTTPConnection.endheaders is undocumented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 10:15:34 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 30 Sep 2011 08:15:34 +0000
Subject: [issue13074] Improve documentation of locale encoding functions
Message-ID: <1317370534.21.0.426762958064.issue13074@psf.upfronthosting.co.za>


New submission from Geoffrey Bache :

The locale module provides locale.getdefaultlocale and locale.getpreferredencoding. The encodings returned by each are generally subtly different ('ISO8859-1' vs 'ISO-8859-1'), but the difference between these methods is not explained. 

A comment by Martin von L?wis from 2003 in http://bugs.python.org/issue813449 indicates that "getdefaultlocale should not be used in new code", if this is really the case then this should be in the docs. 

Anyone reading the docs from the top will currently encounter getdefaultlocale first and believe that this is the way to get the encoding.

----------
assignee: docs at python
components: Documentation
messages: 144677
nosy: docs at python, gjb1002
priority: normal
severity: normal
status: open
title: Improve documentation of locale encoding functions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 10:18:33 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 08:18:33 +0000
Subject: [issue13074] Improve documentation of locale encoding functions
In-Reply-To: <1317370534.21.0.426762958064.issue13074@psf.upfronthosting.co.za>
Message-ID: <1317370713.96.0.429324428001.issue13074@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 10:44:46 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 08:44:46 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <1317364394.66.0.837213000114.issue13057@psf.upfronthosting.co.za>
Message-ID: <02EA6D704E30CE499C5071776509A925F5A9CC@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

I put up an issue the python I build is not able to run thread.start_new_thread. Someone replied to me that there is a bug in configure file and I follow the patch and rebuild my python, my thread is working after the patch is applied. I ended that issue discussion with thanks to the person who answered me and helped me. 

Sorry which one is unrelated?

Regards,
Wah Meng

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 10:59:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 08:59:11 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317373151.27.0.18276033418.issue12753@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

The attached patch changes Tools/unicode/makeunicodedata.py to create a list of names and codepoints taken from http://www.unicode.org/Public/6.0.0/ucd/NameAliases.txt and adds it to Modules/unicodename_db.h.
During the lookup the _getcode function at Modules/unicodedata.c:1055 loops over the 11 aliases and checks if any of those match.
The patch also includes tests for both unicodedata.lookup and \N{}.

I'm not sure this is the best way to implement this, and someone will probably want to review and tweak both the approach and the C code, but it works fine:
>>> "\N{LATIN CAPITAL LETTER GHA}"
'?'
>>> import unicodedata
>>> unicodedata.lookup("LATIN CAPITAL LETTER GHA")
'?'
>>> "\N{LATIN CAPITAL LETTER OI}"
'?'
>>> unicodedata.lookup("LATIN CAPITAL LETTER OI")
'?'

The patch doesn't include changes for NamedSequences.txt.

----------
keywords: +patch
nosy: +lemburg, loewis
Added file: http://bugs.python.org/file23273/issue12753.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 11:01:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 09:01:20 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317373280.19.0.837241202423.issue12753@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
assignee:  -> ezio.melotti
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 11:21:25 2011
From: report at bugs.python.org (Elmar Zander)
Date: Fri, 30 Sep 2011 09:21:25 +0000
Subject: [issue13075] PEP-0001 contains dead links
Message-ID: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>


New submission from Elmar Zander :

The links in section "Resources" of PEP-0001 are all dead. They point to www.python.org/dev/ and all return a 404. Most of them can still be found via google archive.org, but that's not really how it should be. Maybe some of them are already superseded, but even then I think they have at least historical value and should be kept on python.org.

----------
assignee: docs at python
components: Documentation
messages: 144680
nosy: docs at python, ezander
priority: normal
severity: normal
status: open
title: PEP-0001 contains dead links

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 11:23:50 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 30 Sep 2011 09:23:50 +0000
Subject: [issue13073] message_body argument of HTTPConnection.endheaders is
	undocumented
In-Reply-To: <1317370143.22.0.297306447289.issue13073@psf.upfronthosting.co.za>
Message-ID: <1317374630.11.0.192008885569.issue13073@psf.upfronthosting.co.za>


Changes by Senthil Kumaran :


----------
assignee: docs at python -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 11:24:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 09:24:15 +0000
Subject: [issue13075] PEP-0001 contains dead links
In-Reply-To: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>
Message-ID: <1317374655.76.0.880501710403.issue13075@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 12:00:49 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 30 Sep 2011 10:00:49 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317376849.61.0.0384730043577.issue12753@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

I propose to use a better lookup algorithm using binary search, and then integrate the NamedSequences into this as well. The search result could be a record

 struct {
   char *name;
   int len;
   Py_UCS4 chars[3]; /* no sequence is more than 3 chars */
 }

You would have two tables for these: one for the aliases, and one for the named sequences.

_getcode would continue to return a single char only, and thus not support named sequences. lookup could well return strings longer than 1, but only in 3.3.

I'm not sure that \N escapes should support named sequences: people rightfully expect that each escaped element in a string literal constitutes exactly one character.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 12:20:04 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 30 Sep 2011 10:20:04 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1317378004.88.0.0268767403702.issue3232@psf.upfronthosting.co.za>


Martin v. L?wis  added the comment:

I agree that the codec shouldn't "decode" unicode strings. However, the operation performed is still meaningful: users may type ACE (ascii-compatibly-encoded) DNS names into a user interface, and the application may then represent this as a "proper" Unicode name.

So I propose these changes:

- remove support for bytes in codec, but only so for 3.3 (it's actually no change in behavior, since it will continue to raise TypeErrors)
- add a function decode_idna to the module, for users that wish to un-IDNA string objects.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 12:35:58 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Sep 2011 10:35:58 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1317378958.68.0.887401442442.issue3232@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 12:36:39 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 30 Sep 2011 10:36:39 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining
	marks	inappropriately
In-Reply-To: <1317353803.72.0.585410325489.issue12737@psf.upfronthosting.co.za>
Message-ID: <4E859BAF.2050505@v.loewis.de>


Martin v. L?wis  added the comment:

> Martin, do you think that str.title() should follow the Unicode standard?

I don't think that "follow the Unicode standard" has any meaning in this
context: the Unicode standard doesn't specify (AFAIK) what a .title()
method in a programming language should do.

> Should string methods work with all the normalizations or just with NFC?

When we know what .title() should do, it should do so correctly for all
strings. I try to propose a definition for .title()

"Split S into words. Change the first letter in a word to upper-case,
and all subsequent letters to lower case. A word is a sequence that
starts with a letter, followed by letter-related characters."

Letters are all characters from the "Alphabetic" category, i.e.
Lu+Ll+Lt+Lm+Lo+Nl + Other_Alphabetic.

"letter-related" characters are letters + marks (Mn, Mc, Me).

----------
title: str.title() is overzealous by upcasing combining marks inappropriately -> str.title() is overzealous by upcasing combining marks	inappropriately

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 12:46:07 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 10:46:07 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <1317379567.58.0.848749279875.issue13057@psf.upfronthosting.co.za>


Changes by Wong Wah Meng :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 12:57:56 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 10:57:56 +0000
Subject: [issue12876] Make Test Error : ImportError: No module named _sha256
In-Reply-To: <1314873741.02.0.732192179897.issue12876@psf.upfronthosting.co.za>
Message-ID: <1317380276.84.0.894615919355.issue12876@psf.upfronthosting.co.za>


Wong Wah Meng  added the comment:

I tried again the build, after a new openSSL is installed on by my UNIX admin. The OpenSSL version is A.00.09.08r.003. The same result is generated when random is tested. The hashlib cannot be imported due to missing _sha256. 

In my build, I explicitly pass in -I to include header files of openssl, and -L to link up the libraries in openssl. 

export CC="cc +DD64 -I/home/r32813/local/include -I/opt/openssl/include"
export LDFLAGS="-L/home/r32813/local/lib -L/opt/openssl/lib -L/home/r32813/Build/2.7.1/Python-2.7.1"

Could anyone re-look at this issue again?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 13:18:14 2011
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Sep 2011 11:18:14 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <02EA6D704E30CE499C5071776509A925F59F04@039-SN1MPN1-003.039d.mgd.msft.net>
Message-ID: <1317381494.44.0.205350369392.issue13057@psf.upfronthosting.co.za>


Stefan Krah  added the comment:

Wah Meng: I think there are a couple of misconceptions that
need to be cleared up:

1) Georg's complaint was about the links to http://dyno.freescale.net/
   in you posts.


2) This is not a support hotline but a *bug tracker*. Since
   the bug in configure has not been fixed, this issue needs
   to stay open.

----------
components: +Build
stage:  -> needs patch
status: closed -> open
type:  -> compile error
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 13:26:15 2011
From: report at bugs.python.org (Wong Wah Meng)
Date: Fri, 30 Sep 2011 11:26:15 +0000
Subject: [issue13057] Thread not working for python 2.7.1 built with HP
	Compiler on HP-UX 11.31 ia64
In-Reply-To: <1317381494.44.0.205350369392.issue13057@psf.upfronthosting.co.za>
Message-ID: <02EA6D704E30CE499C5071776509A925F5AB61@039-SN1MPN1-003.039d.mgd.msft.net>


Wong Wah Meng  added the comment:

1.) I see. Sorry ya, I didn't notice. They are automatically generated as my email footer. 
2.) Ok, appreciate the information and helps!

Regards,
Wah Meng

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 13:48:25 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Sep 2011 11:48:25 +0000
Subject: [issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py
In-Reply-To: <1214701412.5.0.118957128053.issue3232@psf.upfronthosting.co.za>
Message-ID: <1317383305.41.0.824034358229.issue3232@psf.upfronthosting.co.za>


R. David Murray  added the comment:

+1.  decode_idna is likely to be useful to the email package.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 14:37:58 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 30 Sep 2011 12:37:58 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <4E859BAF.2050505@v.loewis.de>
Message-ID: <26418.1317386261@chthon>


Tom Christiansen  added the comment:

> Martin v. L?wis  added the comment:

> "Split S into words. Change the first letter in a word to upper-case,

Except that I think you actually mean that the first "letter" is 
changed into titlecase not uppercase.  

One might also say *try* to change for all these, in that not
all cased code points in Unicode have casemaps that are different
from themselves.  For example, a superscript lowercase a or b has
no distinct uppercase mapping, the way the non-superscript versions do:

    % (echo xyz; echo ab AB | unisupers) | uc
    XYZ
    ?? ??

> and all subsequent letters to lower case. A word is a sequence that
> starts with a letter, followed by letter-related characters."

I don't like the way you have defined letters and letter-related
characters.  The first already has a definition, which is not the
one you are using.  Word characters also has a definition in Unicode,
and it is not the one you are using.  I strongly advise against
redefining standard Unicode properties.  Choose other, unused terms 
if you must.  It is very confusing otherwise.

> Letters are all characters from the "Alphabetic" category, i.e.
> Lu+Ll+Lt+Lm+Lo+Nl + Other_Alphabetic.

Except that is exactly the definition of the Unicode Alphabetic property,
not the Unicode Letter property.  It is a mistake to equate
Letter=Alphabetic, and very confusing too.

I agree that this probably what you want, though.  I just don't think you
should use "letter-related characters" when there is an existing formal
definition that works, or that you should redefine Letter.

> "letter-related" characters are letters + marks (Mn, Mc, Me).

That isn't quite right.  

 * Letters are Lu+Ll+Lt+Lm+Lo.

 * Alphabetic is Letters + Other_Alphabetic.

 * Other_Alphabetic is certain marks (like the iota subscript) and the
   letter numbers (Nl), as well as a few symbols.

 * Word characters are Alphabetic + Mn+Mc+Me + Nd + Pc.

I think you are looking for here are Word characters without 
Nd + Pc, so just Alphabetic + Mn+Mc+Me.  

Is that right?

--tom

PS: You can do union/intersection stuff with properties to see what
    the resulting sets look like using the unichars command-line tool.

    This is everything that is both alphabetic and also a mark:

    % unichars -gs '\p{Alphabetic}' '\pM'
    ? ??  U+0345 GC=Mn SC=Inherited    COMBINING GREEK YPOGEGRAMMENI
    ? ??  U+05B0 GC=Mn SC=Hebrew       HEBREW POINT SHEVA
    ? ??  U+05B1 GC=Mn SC=Hebrew       HEBREW POINT HATAF SEGOL
    ? ??  U+05B2 GC=Mn SC=Hebrew       HEBREW POINT HATAF PATAH
    ? ??  U+05B3 GC=Mn SC=Hebrew       HEBREW POINT HATAF QAMATS
    ...
    ? ??  U+0902 GC=Mn SC=Devanagari   DEVANAGARI SIGN ANUSVARA
    ? ?  U+0903 GC=Mc SC=Devanagari   DEVANAGARI SIGN VISARGA
    ? ?  U+093E GC=Mc SC=Devanagari   DEVANAGARI VOWEL SIGN AA
    ? ?  U+093F GC=Mc SC=Devanagari   DEVANAGARI VOWEL SIGN I
    ? ?  U+0940 GC=Mc SC=Devanagari   DEVANAGARI VOWEL SIGN II
    ? ??  U+0941 GC=Mn SC=Devanagari   DEVANAGARI VOWEL SIGN U
    ? ??  U+0942 GC=Mn SC=Devanagari   DEVANAGARI VOWEL SIGN UU
    ? ??  U+0943 GC=Mn SC=Devanagari   DEVANAGARI VOWEL SIGN VOCALIC R
    ? ??  U+0944 GC=Mn SC=Devanagari   DEVANAGARI VOWEL SIGN VOCALIC RR
    ...

    While these are the NON-alphabetic marks, which are still Word
    characters though of course:

    % unichars -gs '\P{Alphabetic}' '\pM'
    ? ??  U+0300 GC=Mn SC=Inherited    COMBINING GRAVE ACCENT
    ? ??  U+0301 GC=Mn SC=Inherited    COMBINING ACUTE ACCENT
    ? ??  U+0302 GC=Mn SC=Inherited    COMBINING CIRCUMFLEX ACCENT
    ? ??  U+0303 GC=Mn SC=Inherited    COMBINING TILDE
    ? ??  U+0304 GC=Mn SC=Inherited    COMBINING MACRON
    ? ??  U+0305 GC=Mn SC=Inherited    COMBINING OVERLINE
    ? ??  U+0306 GC=Mn SC=Inherited    COMBINING BREVE
    ? ??  U+0307 GC=Mn SC=Inherited    COMBINING DOT ABOVE
    ? ??  U+0308 GC=Mn SC=Inherited    COMBINING DIAERESIS
    ? ??  U+0309 GC=Mn SC=Inherited    COMBINING HOOK ABOVE
    ? ??  U+030A GC=Mn SC=Inherited    COMBINING RING ABOVE
    ? ??  U+030B GC=Mn SC=Inherited    COMBINING DOUBLE ACUTE ACCENT
    ? ??  U+030C GC=Mn SC=Inherited    COMBINING CARON
    ...

    And here are the Cased code points that are do not change when 
    upper-, title-, or lowercased:

    % unichars -gs '\p{Cased}' '[^\p{CWU}\p{CWT}\p{CWL}]'
    ? ?  U+00AA GC=Ll SC=Latin        FEMININE ORDINAL INDICATOR
    ? ?  U+00BA GC=Ll SC=Latin        MASCULINE ORDINAL INDICATOR
    ? ?  U+0138 GC=Ll SC=Latin        LATIN SMALL LETTER KRA
    ? ?  U+018D GC=Ll SC=Latin        LATIN SMALL LETTER TURNED DELTA
    ? ?  U+019B GC=Ll SC=Latin        LATIN SMALL LETTER LAMBDA WITH STROKE
    ? ?  U+01AA GC=Ll SC=Latin        LATIN LETTER REVERSED ESH LOOP
    ? ?  U+01AB GC=Ll SC=Latin        LATIN SMALL LETTER T WITH PALATAL HOOK
    ? ?  U+01BA GC=Ll SC=Latin        LATIN SMALL LETTER EZH WITH TAIL
    ? ?  U+01BE GC=Ll SC=Latin        LATIN LETTER INVERTED GLOTTAL STOP WITH STROKE
    ? ?  U+0221 GC=Ll SC=Latin        LATIN SMALL LETTER D WITH CURL
    ? ?  U+0234 GC=Ll SC=Latin        LATIN SMALL LETTER L WITH CURL
    ? ?  U+0235 GC=Ll SC=Latin        LATIN SMALL LETTER N WITH CURL
    ? ?  U+0236 GC=Ll SC=Latin        LATIN SMALL LETTER T WITH CURL
    ? ?  U+0237 GC=Ll SC=Latin        LATIN SMALL LETTER DOTLESS J
    ? ?  U+0238 GC=Ll SC=Latin        LATIN SMALL LETTER DB DIGRAPH
    ? ?  U+0239 GC=Ll SC=Latin        LATIN SMALL LETTER QP DIGRAPH
    ? ?  U+0255 GC=Ll SC=Latin        LATIN SMALL LETTER C WITH CURL
    ? ?  U+0258 GC=Ll SC=Latin        LATIN SMALL LETTER REVERSED E
    ? ?  U+025A GC=Ll SC=Latin        LATIN SMALL LETTER SCHWA WITH HOOK
    ? ?  U+025C GC=Ll SC=Latin        LATIN SMALL LETTER REVERSED OPEN E
    ? ?  U+025D GC=Ll SC=Latin        LATIN SMALL LETTER REVERSED OPEN E WITH HOOK
    ? ?  U+025E GC=Ll SC=Latin        LATIN SMALL LETTER CLOSED REVERSED OPEN E
    ? ?  U+025F GC=Ll SC=Latin        LATIN SMALL LETTER DOTLESS J WITH STROKE
    ? ?  U+0261 GC=Ll SC=Latin        LATIN SMALL LETTER SCRIPT G
    ? ?  U+0262 GC=Ll SC=Latin        LATIN LETTER SMALL CAPITAL G
    ? ?  U+0264 GC=Ll SC=Latin        LATIN SMALL LETTER RAMS HORN
    ? ?  U+0265 GC=Ll SC=Latin        LATIN SMALL LETTER TURNED H
    ? ?  U+0266 GC=Ll SC=Latin        LATIN SMALL LETTER H WITH HOOK
    ...

    You can get unichars from http://training.perl.com/scripts/unichars
    where you might also care to get uniprops and perhaps uninames to go
    with it.  There are other Unicode tools there (the directory is
    100% Unicode tools, not general scripts as its name suggests), but
    those are the important ones, I reckon.

----------
title: str.title() is overzealous by upcasing combining marks	inappropriately -> str.title() is overzealous by upcasing combining marks inappropriately

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 15:45:09 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 30 Sep 2011 13:45:09 +0000
Subject: [issue13076] Bad links to 'time' in datetime documentation
Message-ID: <1317390308.93.0.874341309843.issue13076@psf.upfronthosting.co.za>


New submission from Geoffrey Bache :

Reading through the datetime module documentation, various places that refer to "datetime.time" objects are in fact links to the "time" module. They should refer to the appropriate section on the same page.

----------
messages: 144689
nosy: gjb1002
priority: normal
severity: normal
status: open
title: Bad links to 'time' in datetime documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 15:45:45 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Fri, 30 Sep 2011 13:45:45 +0000
Subject: [issue13076] Bad links to 'time' in datetime documentation
In-Reply-To: <1317390308.93.0.874341309843.issue13076@psf.upfronthosting.co.za>
Message-ID: <1317390345.54.0.566713410674.issue13076@psf.upfronthosting.co.za>


Changes by Geoffrey Bache :


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 15:48:03 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Sep 2011 13:48:03 +0000
Subject: [issue13076] Bad links to 'time' in datetime documentation
In-Reply-To: <1317390308.93.0.874341309843.issue13076@psf.upfronthosting.co.za>
Message-ID: <1317390483.27.0.986806376285.issue13076@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 17:02:08 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 30 Sep 2011 15:02:08 +0000
Subject: [issue12737] str.title() is overzealous by upcasing combining marks
	inappropriately
In-Reply-To: <26418.1317386261@chthon>
Message-ID: 


Guido van Rossum  added the comment:

I like how we're actually converging on an implementable and
maximally-useful algorithm.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 17:30:42 2011
From: report at bugs.python.org (etuardu)
Date: Fri, 30 Sep 2011 15:30:42 +0000
Subject: [issue13077] Unclear behavior of daemon threads on main thread exit
Message-ID: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za>


New submission from etuardu :

The definition of daemon thread in the current documentation reads:

?A thread can be flagged as a "daemon thread". The significance of this flag is that the entire Python program exits when only daemon threads are left. [...]?
(http://docs.python.org/library/threading.html#thread-objects)

I think it's not very clear from this that daemon threads themselves terminate when the program (main thread plus other non-daemon threads) terminates. I think this have to be said more explicitly. I'd propose a change with something like:

?A thread can be flagged as a "daemon thread", which means it will get shut down when the overall program terminates. The entire Python program exits when only daemon threads are left.?

----------
assignee: docs at python
components: Documentation
messages: 144691
nosy: docs at python, etuardu
priority: normal
severity: normal
status: open
title: Unclear behavior of daemon threads on main thread exit
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 17:42:49 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Sep 2011 15:42:49 +0000
Subject: [issue13077] Unclear behavior of daemon threads on main thread exit
In-Reply-To: <1317396642.03.0.535538271179.issue13077@psf.upfronthosting.co.za>
Message-ID: <1317397369.0.0.79874621126.issue13077@psf.upfronthosting.co.za>


R. David Murray  added the comment:

It seems clear enough to me that when a process terminates ("the entire Python program exits") then all of its threads must terminate.  That's part of the definition of threads, to my understanding.

I think the confusion arises from the use of the word "deamon", which has been discussed as a bad thing elsewhere in this tracker.  A unix user would expect a "daemon" to keep running in the background, whereas here it is exactly the opposite.  See issue 5906 for example, where in the context of Multiprocessing it becomes even more confusing.  Perhaps a similar note that 'daemon' does not mean what it does in unix would be a good idea.

----------
nosy: +r.david.murray
stage:  -> patch review
versions:  -Python 2.6, Python 3.1, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 18:01:31 2011
From: report at bugs.python.org (Richard86)
Date: Fri, 30 Sep 2011 16:01:31 +0000
Subject: [issue13040] call to tkinter.messagebox.showinfo hangs the script on
	timer on Windows
In-Reply-To: <1316861046.74.0.26633284396.issue13040@psf.upfronthosting.co.za>
Message-ID: <1317398491.32.0.71780094155.issue13040@psf.upfronthosting.co.za>


Richard86  added the comment:

This is a serious problem. I REALLY hope that someone on a Windows machine can either confirm the bug by reproducing with provided example code or disprove it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 18:10:29 2011
From: report at bugs.python.org (Bruce Ferris)
Date: Fri, 30 Sep 2011 16:10:29 +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: <1317399029.11.0.23582254116.issue12632@psf.upfronthosting.co.za>


Bruce Ferris  added the comment:

The PYTHONIOENCODING=utf-8 setting works great if I have code page 65001 set.  I haven't, however, done a complete console functionality check with that setting but, thanks for the input -- it solves the current problem I'm experiencing.

I do wonder, however, if switching to that setting should happen automatically if it's not specified and the Windows current code page is 65001.

That would solve the problem unless, of course, PYTHONIOENCODING has side-effects elsewhere that would cause other problems.

On the other hand, if it does have side-effects elsewhere than it's not the answer I'm looking for.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 18:25:45 2011
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 30 Sep 2011 16:25:45 +0000
Subject: [issue13062] Introspection generator and function closure state
In-Reply-To: <1317318190.56.0.437971601638.issue13062@psf.upfronthosting.co.za>
Message-ID: <1317399945.12.0.269659215417.issue13062@psf.upfronthosting.co.za>


Changes by Daniel Urban :


----------
nosy: +durban

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 19:05:04 2011
From: report at bugs.python.org (Eli Collins)
Date: Fri, 30 Sep 2011 17:05:04 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317402304.53.0.390862210077.issue12242@psf.upfronthosting.co.za>


Changes by Eli Collins :


Added file: http://bugs.python.org/file23274/963a2cce068d.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 19:18:31 2011
From: report at bugs.python.org (Eli Collins)
Date: Fri, 30 Sep 2011 17:18:31 +0000
Subject: [issue12242] distutils2 environment marker for current compiler
In-Reply-To: <1307028523.76.0.0549970473948.issue12242@psf.upfronthosting.co.za>
Message-ID: <1317403111.6.0.983300631282.issue12242@psf.upfronthosting.co.za>


Eli Collins  added the comment:

Attached is a fifth revision (963a2cce068d.diff) of my patch.

I was trying to avoid submitting any more revisions if possible, since this I think this patch is essentially feature-complete. However, this revision adds two things which I felt were needed:

* This patch fixes a serious oversight where UnixCCompiler.get_compiler_version() wouldn't correctly handle compiler names which contains an absolute file path, or suffixes such as ".exe" (which could happen under mingw). This corrects for that, and adds tests for those cases. 

* After thinking about it, I realized the "--get-compiler-info" option I mentioned in my last post was in fact sorely needed... otherwise there is no easy way for users to determine what string specific_compile_args is using to match against its regexp patterns; such as in Roumen's question. (I hope I wasn't overstepping any bounds by going ahead and implementing this)

The option can be run via "pysetup3 -q run build_ext --get-compiler-info". Instead of compiling any extensions, it causes build_ext to print out two lines: the first containing the name of the active compiler class, and the second containing the exact string that will be matched by specific_compile_args. I've added references to this in the documentation, as well as unittests to make sure it behaves properly.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 19:19:11 2011
From: report at bugs.python.org (Vlad Riscutia)
Date: Fri, 30 Sep 2011 17:19:11 +0000
Subject: [issue12880] ctypes: clearly document how structure bit fields are
	allocated
In-Reply-To: <1314930851.91.0.112444630543.issue12880@psf.upfronthosting.co.za>
Message-ID: <1317403151.53.0.993055557363.issue12880@psf.upfronthosting.co.za>


Vlad Riscutia  added the comment:

Attached doc update against tip (though I still hope my patch for configurable allocation strategies will make it in). 

This is my first doc patch so let me know if I missed something. I am basically explaining that bit field allocation is compiler-specific and no assumptions should be made of how a bitfield is allocated. 

I believe this is the better thing to do rather than detailing how GCC and MSVC allocated their bitfields because that would just encourage people to use this feature incorrectly. Most bugs opened on bit fields are because people are toying with the underlying buffer and get other results than what they expect. IMO, when using bitfields one should only access the structure members at a high level and not go read/write the raw memory underneath.

----------
keywords: +patch
Added file: http://bugs.python.org/file23275/bitfield_doc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 19:41:55 2011
From: report at bugs.python.org (Ash Sparks)
Date: Fri, 30 Sep 2011 17:41:55 +0000
Subject: [issue13078] Python Crashes When Saving Or Opening
Message-ID: <1317404515.12.0.258020695982.issue13078@psf.upfronthosting.co.za>


New submission from Ash Sparks :

Hi there,

Python v3.2 crashes every time I attempt to save or open .py files.

I have attached a text file that shows the error I receive.

In advance, your help is much appreciated

Regards

Ash

----------
components: Windows
files: Python_Issue.txt
messages: 144697
nosy: Ash.Sparks
priority: normal
severity: normal
status: open
title: Python Crashes When Saving Or Opening
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file23276/Python_Issue.txt

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 19:51:59 2011
From: report at bugs.python.org (ojab)
Date: Fri, 30 Sep 2011 17:51:59 +0000
Subject: [issue13079] Wrong datetime format in PEP3101
Message-ID: <1317405119.65.0.993211188436.issue13079@psf.upfronthosting.co.za>


New submission from ojab :

Example in pep3101 is
"Today is: {0:a b d H:M:S Y}".format(datetime.now())
but it should be 
"Today is: {0:%a %b %d %H:%M:%S %Y}".format(datetime.now())

----------
assignee: docs at python
components: Documentation
messages: 144698
nosy: docs at python, ojab
priority: normal
severity: normal
status: open
title: Wrong datetime format in PEP3101
type: behavior
versions: 3rd party

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 21:25:29 2011
From: report at bugs.python.org (Ned Deily)
Date: Fri, 30 Sep 2011 19:25:29 +0000
Subject: [issue13040] call to tkinter.messagebox.showinfo hangs the script on
	timer on Windows
In-Reply-To: <1316861046.74.0.26633284396.issue13040@psf.upfronthosting.co.za>
Message-ID: <1317410729.37.0.639761932625.issue13040@psf.upfronthosting.co.za>


Ned Deily  added the comment:

The problem can be reproduced on some other platforms depending on the version of Tcl/Tk in use.  But the supplied program violates the well-known if not particularly well-documented restriction of tkinter programming that all Tk UI operations must be on the main thread.  See, for example, http://effbot.org/zone/tkinter-threads.htm  or http://tkinter.unpythonic.net/wiki/mtTkinter

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed
type: crash -> 

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 21:31:38 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 30 Sep 2011 19:31:38 +0000
Subject: [issue13080] test_email fails in refleak mode
Message-ID: <1317411097.99.0.612727168161.issue13080@psf.upfronthosting.co.za>


New submission from Antoine Pitrou :

$ ./python -m test -R 3:2 -uall test_email
[1/1] test_email
beginning 5 repetitions
12345
Warning -- sys.path was modified by test_email
test test_email failed -- Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_email/test_policy.py", line 136, in test_overriden_register_defect_works
    self.assertEqual(my_policy.defects, [defect1])
AssertionError: Lists differ: [MyDefect('one',), MyDefect('t... != [MyDefect('one',)]

First differing element 0:
one
one

First list contains 2 additional elements.
First extra element 1:
two

- [MyDefect('one',), MyDefect('two',), MyDefect('one',)]
+ [MyDefect('one',)]

1 test failed:
    test_email

----------
components: Library (Lib), Tests
messages: 144700
nosy: barry, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: test_email fails in refleak mode
type: behavior
versions: Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 21:34:15 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Sep 2011 19:34:15 +0000
Subject: [issue13080] test_email fails in refleak mode
In-Reply-To: <1317411097.99.0.612727168161.issue13080@psf.upfronthosting.co.za>
Message-ID: <1317411255.96.0.618982282562.issue13080@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
assignee:  -> r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 21:42:19 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 19:42:19 +0000
Subject: [issue13079] Wrong datetime format in PEP3101
In-Reply-To: <1317405119.65.0.993211188436.issue13079@psf.upfronthosting.co.za>
Message-ID: <1317411739.15.0.439098702592.issue13079@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +eric.smith, ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 21:55:44 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 30 Sep 2011 19:55:44 +0000
Subject: [issue13075] PEP-0001 contains dead links
In-Reply-To: <1317374485.54.0.239839552518.issue13075@psf.upfronthosting.co.za>
Message-ID: <1317412544.48.0.304587493408.issue13075@psf.upfronthosting.co.za>


Eric Snow  added the comment:

"Maybe some of them are already superseded, but even then I think they have at least historical value and should be kept on python.org."

+1

----------
nosy: +eric.snow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 22:03:18 2011
From: report at bugs.python.org (Richard86)
Date: Fri, 30 Sep 2011 20:03:18 +0000
Subject: [issue13040] call to tkinter.messagebox.showinfo hangs the script on
	timer on Windows
In-Reply-To: <1316861046.74.0.26633284396.issue13040@psf.upfronthosting.co.za>
Message-ID: <1317412998.36.0.373888968062.issue13040@psf.upfronthosting.co.za>


Richard86  added the comment:

You nailed it. Thank you very much! (I really thought it was a bug, since the code ran well on Linux.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 22:30:42 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 30 Sep 2011 20:30:42 +0000
Subject: [issue12753] \N{...} neglects formal aliases and named sequences from
	Unicode charnames namespace
In-Reply-To: <1313430514.3.0.983525514499.issue12753@psf.upfronthosting.co.za>
Message-ID: <1317414642.85.0.0881821462071.issue12753@psf.upfronthosting.co.za>


Ezio Melotti  added the comment:

Leaving named sequences for unicodedata.lookup() only (and not for \N{}) makes sense.

The list of aliases is so small (11 entries) that I'm not sure using a binary search for it would bring any advantage.  Having a single lookup algorithm that looks in both tables doesn't work because the aliases lookup must be in _getcode for \N{...} to work, whereas the lookup of named sequences will happen in unicodedata_lookup (Modules/unicodedata.c:1187).
I think we can leave the for loop over aliases in _getcode and implement a separate (and binary) search in unicodedata_lookup for the named sequences.  Does that sound fine?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 22:35:44 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Sep 2011 20:35:44 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317414944.52.0.8614325043.issue13070@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

Confirmed with default.
The problem is that the TextIOWrapper gets collected after the underlying BufferedRWPair has been cleared (tp_clear) by the garbage collector: when _PyIOBase_finalize() is called for the TextIOWrapper, it checks if the textio is closed, which indirectly checks if the underlying rwpair is closed:
"""
static PyObject *
bufferedrwpair_closed_get(rwpair *self, void *context)
{
    return PyObject_GetAttr((PyObject *) self->writer, _PyIO_str_closed);
}
"""

Since self->writer has already been set to NULL by bufferedrwpair_clear(), PyObject_GetAttr() segfaults.

@Victor
Could you try the patch attached?

----------
keywords: +patch
nosy: +amaury.forgeotdarc, neologix, pitrou
versions: +Python 3.3
Added file: http://bugs.python.org/file23277/buffered_closed_gc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 22:36:55 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 30 Sep 2011 20:36:55 +0000
Subject: [issue13079] Wrong datetime format in PEP3101
In-Reply-To: <1317405119.65.0.993211188436.issue13079@psf.upfronthosting.co.za>
Message-ID: <1317415015.2.0.851327510418.issue13079@psf.upfronthosting.co.za>


Eric V. Smith  added the comment:

Thanks for the report. Fixed in 9a9bd05b9fca.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 23:03:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Sep 2011 21:03:28 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317416608.74.0.0376542438788.issue13070@psf.upfronthosting.co.za>


Charles-Fran?ois Natali  added the comment:

With test.

----------
Added file: http://bugs.python.org/file23278/buffered_closed_gc-1.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 23:11:12 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Sep 2011 21:11:12 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317417072.25.0.751991715962.issue13070@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


Removed file: http://bugs.python.org/file23277/buffered_closed_gc.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 23:11:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Sep 2011 21:11:22 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317417083.0.0.916469584743.issue13070@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


Removed file: http://bugs.python.org/file23278/buffered_closed_gc-1.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 23:11:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 30 Sep 2011 21:11:42 +0000
Subject: [issue13070] segmentation fault in pure-python multi-threaded server
In-Reply-To: <1317336165.27.0.207190934922.issue13070@psf.upfronthosting.co.za>
Message-ID: <1317417102.81.0.308726405211.issue13070@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali :


Added file: http://bugs.python.org/file23279/buffered_closed_gc-1.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 30 23:21:05 2011
From: report at bugs.python.org (Roger Libiez)
Date: Fri, 30 Sep 2011 21:21:05 +0000
Subject: [issue13081] Crash in Windows with unknown cause
Message-ID: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>


New submission from Roger Libiez :

While using the application found at: https://sourceforge.net/tracker/?group_id=199269

The following Windows error dump generates itself while processing a batch of 3D mesh files with it. I do not know the specifics about what process was underway or have any Python trace data to supply, but it can be reproduced reliably using the beta6 version of the application. The developer directed me here after I filed this bug: https://sourceforge.net/tracker/?func=detail&aid=3415495&group_id=199269&atid=968813

The only known method I have to reproduce this is to run a batch process against a large number of mesh files. Windows memory usage is not anywhere close to the 2GB process limit.

Windows 7 Home Premium 64 bit, using 32 bit Python 2.7.2.

Problem signature:
Problem Event Name: APPCRASH
Application Name: python.exe
Application Version: 0.0.0.0
Application Timestamp: 4df4ba7c
Fault Module Name: python27.dll
Fault Module Version: 2.7.2150.1013
Fault Module Timestamp: 4df4ba7c
Exception Code: c0000005
Exception Offset: 0002a33f
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

----------
components: Windows
messages: 144707
nosy: rlibiez
priority: normal
severity: normal
status: open
title: Crash in Windows with unknown cause
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________