[issue4709] Mingw-w64 and python on windows x64
New submission from Cournapeau David da...@ar.media.kyoto-u.ac.jp:
I believe the current pyport.h for windows x64 has some problems. It
does not work for compilers which are not MS ones, because building
against the official binary (python 2.6) relies on features which are
not enabled unless MS_WIN64 is defined, and the later is not defined if
an extension is not built with MS compiler.
As a simple example:
#include Python.h
int main()
{
printf(sizeof(Py_intptr_t) = %d\n, sizeof(Py_intptr_t));
return 0;
}
If you build this with MS compiler, you get the expected
sizeof(Py_intptr_t) = 8, but with gcc, you get 4. Now, if I build the
test like:
gcc -I C:\Python26\include -DMS_WIN64 main.c
Then I got 8 as well.
I believe the attached patch should fix the problem (I have not tested
it, since building python on amd64).
--
components: Build
files: mingw-w64.patch
keywords: patch
messages: 78140
nosy: cdavid
severity: normal
status: open
title: Mingw-w64 and python on windows x64
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file12411/mingw-w64.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4709
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4707] round() shows undocumented behaviour
Martin v. Löwis mar...@v.loewis.de added the comment: Martin, that gives some answers like round(51, -2) -- 0 instead of 100. I see. Here is a version that fixes that. def round(n, i): i = 10**(-i) r = n%(2*i) o = i/2 n -= r if r = o: return n elif r 3*o: return n+i else: return n+2*i However, I now see that it is pointless not to use divrem, since % computes the quotient as a side effect. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4631] urlopen returns extra, spurious bytes
Changes by Martin v. Löwis mar...@v.loewis.de: -- priority: critical - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4631 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4707] round() shows undocumented behaviour
Mark Dickinson dicki...@gmail.com added the comment: Updated patch: fix test_builtin. (Rest of the patch unchanged.) Added file: http://bugs.python.org/file12412/round_int_int2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4710] [PATCH] zipfile.ZipFile does not extract directories properly
New submission from Kuba Wieczorek faw...@gmail.com: This behaviour has been known of course for quite long time. I suppose this is not intentional so I've played a bit with this and I hope you'll consider some little change. Currently, if a ZIP archive contains some subdirectories then zipfile.ZipFile.extract()/extractall() will create files instead of directories in the target location. This of course will lead some scripts to crash (unless any work-around has been done) because files from the subdirectories couldn't be created. Attached is a patch against current 2.7 tree. Applied, will make extractall() extract properly all the contents of the archive with proper tree structure. If a directory name is passed to the extract(), it will only create the directory itself without the contents (I guess it is obvious). -- components: Library (Lib) files: zipfile_extract_dirs.patch keywords: patch messages: 78143 nosy: faw severity: normal status: open title: [PATCH] zipfile.ZipFile does not extract directories properly type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file12413/zipfile_extract_dirs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4710 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4631] urlopen returns extra, spurious bytes
Antoine Pitrou pit...@free.fr added the comment: The patch should have at least a test so that we don't have a regression on this one. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4631 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4707] round() shows undocumented behaviour
Daniel Diniz aja...@gmail.com added the comment: Hi Mark, I think there's an overflow for ndigits that predates your patch: round(2, -2**31 +1) 2 round(2, -2**31 +2) nan (it looks like these lines above make 2.6 hang :/) Now, I'm getting a segfault in 3.0 when Ctrl + C-ing during a long running round: Python 3.1a0 (py3k:67893M, Dec 21 2008, 10:38:30) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type help, copyright, credits or license for more information. round(2, -2**31 + 1) 2 round(2, -2**31 + 2) # Press Ctrl + C Segmentation fault (backtrace below) Also, maybe round(2, -2**31 + 2) taking long is a bug of its own? The crash with backtrace: Starting program: /home/ajaksu/py3k/python [Thread debugging using libthread_db enabled] Python 3.1a0 (py3k:67893M, Dec 21 2008, 11:08:29) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type help, copyright, credits or license for more information. [New Thread 0xb7d2e8c0 (LWP 14925)] round(2, -2**31 + 1) 2 round(2, -2**31 + 2) # Press Ctrl + C Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7d2e8c0 (LWP 14925)] _PyUnicode_New (length=10) at Objects/unicodeobject.c:359 359 unicode-str[0] = 0; (gdb) bt #0 _PyUnicode_New (length=10) at Objects/unicodeobject.c:359 #1 0x080708a5 in PyUnicodeUCS2_DecodeUTF8Stateful (s=0x813d8dc last_value, size=10, errors=0x0, consumed=0x0) at Objects/unicodeobject.c:2022 #2 0x08072e22 in PyUnicodeUCS2_FromStringAndSize (u=0x813d8dc last_value, size=10) at Objects/unicodeobject.c:2000 #3 0x08072f82 in PyUnicodeUCS2_FromString (u=0x813d8dc last_value) at Objects/unicodeobject.c:557 #4 0x0810ddf7 in PyDict_SetItemString (v=0xb7b21714, key=0x813d8dc last_value, item=0xb7a4e43c) at Objects/dictobject.c:2088 #5 0x080b5fb1 in PySys_SetObject (name=0x813d8dc last_value, v=0xa) at Python/sysmodule.c:67 #6 0x080afedb in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:1294 #7 0x080b063c in PyRun_InteractiveOneFlags (fp=0xb7e7a440, filename=0x813f509 stdin, flags=0xbf84bd34) at Python/pythonrun.c:1189 #8 0x080b0816 in PyRun_InteractiveLoopFlags (fp=0xb7e7a440, filename=0x813f509 stdin, flags=0xbf84bd34) at Python/pythonrun.c:909 #9 0x080b0fa2 in PyRun_AnyFileExFlags (fp=0xb7e7a440, filename=0x813f509 stdin, closeit=0, flags=0xbf84bd34) at Python/pythonrun.c:878 #10 0x080bc49a in Py_Main (argc=0, argv=0x8192008) at Modules/main.c:611 #11 0x0805a1dc in main (argc=1, argv=0xbf84de24) at ./Modules/python.c:70 I hope this helps :) Daniel -- nosy: +ajaksu2 versions: +Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4707] round() shows undocumented behaviour
Mark Dickinson dicki...@gmail.com added the comment: round(2, -2**31 + 2) # Press Ctrl + C Segmentation fault (backtrace below) Thanks, Daniel. It looks like I messed up the refcounting in the error- handling section of the code. I'll fix this. I don't think the hang itself should be considered a bug, any more than the hang from 10**(2**31-1) is a bug. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4707] round() shows undocumented behaviour
Mark Dickinson dicki...@gmail.com added the comment: Cause of segfault was doing Py_XDECREF on a pointer that hadn't been initialised to NULL. Here's a fixed patch. I still get the instant result: round(2, -2**31+1) 2 which is a little odd. It's the correct result, but I can't see how it gets there: under the current algorithm, there should be a 10**(2**31-1) happening somewhere, and that would take a *lot* of time and memory. Will investigate. Added file: http://bugs.python.org/file12414/round_int_int3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4707] round() shows undocumented behaviour
Mark Dickinson dicki...@gmail.com added the comment: Aha. The special result for round(x, 1-2**31) has nothing to do with this particular patch. It's a consequence of: #define UNDEF_NDIGITS (-0x7fff) /* Unlikely ndigits value */ in bltinmodule.c. The same behaviour results for all types, not just ints. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4707] round() shows undocumented behaviour
Daniel Diniz aja...@gmail.com added the comment: Mark Dickinson rep...@bugs.python.org wrote: I don't think the hang itself should be considered a bug, any more than the hang from 10**(2**31-1) is a bug. Well, besides the fact that you can stop 10**(2**31-1) with Ctrl+C but not round(2, -2**31+1), the round case may special case ndigits number to avoid the slow pow(10, x). round(2, -2**31+1) 2 which is a little odd. It's the correct result, but I can't see how Is it correct? The answer for 0 ndigits -2**301+1 was nan before the patch, 0 after. Given that round(2, 2**31) throws an OverflowError, iff this is wrong, should it OverflowError too? it gets there: under the current algorithm, there should be a 10**(2**31-1) happening somewhere, and that would take a *lot* of time and memory. Will investigate. That should be optimizable for ndigits number, and perhaps log10(number) k * ndigits (for large ndigits), right? But I don't think it's a realworld usecase, so dropping this idea for 2.6. Aha. The special result for round(x, 1-2**31) has nothing to do with this particular patch. It's a consequence of: Yep, predates your patch as I said :) -- versions: -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4707] round() shows undocumented behaviour
Mark Dickinson dicki...@gmail.com added the comment: [Me] which is a little odd. It's the correct result, but I can't see how [Daniel] Is it correct? No. :-) It should be 0, as you say. Given that round(2, 2**31) throws an OverflowError I think this is wrong, too. It should be 2. It's another consequence of the code in bltinmodule.c. The builtin_round function seems unnecessarily complicated: it converts the second argument from a Python object to a C int, then converts it back again before calling the appropriate __round__ method. Then the first thing the __round__ method typically does for built-in types is to convert to a C int again. As far as I can tell the first two conversions are unnecessary. Here's an updated version of the patch that does away with the unnecessary conversions, along with the UNDEF_NDIGITS hack. All tests still pass, on my machine, and with this patch I get the results I'd expect: round(2, 2**31) 2 round(2, 2**100) 2 round(2, -2**100) ^CTraceback (most recent call last): File stdin, line 1, in module KeyboardInterrupt round(2, 1-2**31) ^CTraceback (most recent call last): File stdin, line 1, in module KeyboardInterrupt That should be optimizable for ndigits number, and perhaps log10(number) k * ndigits (for large ndigits), right? But I don't think it's a realworld usecase, so dropping this idea for 2.6. Agreed. I don't think this optimization is worth it. Added file: http://bugs.python.org/file12415/round_int_int4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4711] Wide literals in the table of contents overflow in documentation
New submission from Scott Dial sc...@scottdial.com: There is a problem with the table contents with respect to literals that cannot be word-wrapped. I see this issue here: http://docs.python.org/dev/2.6/library/multiprocessing.html The line in the table of contents that reads The multiprocessing.dummy module is broken in that the literal multiprocessing.sharedctypes overflows into the right-hand side. It also ends up underneath the contents on the right, which makes it extra hard to know what that entry was about. This instance may be browser specific, but I think it brings up a more general question of what should be done with such long literals and how overflow should be handled. And perhaps even whether it is wise to have set the width of that div to such a narrow and specific value (230px). I've attached a screenshot from Firefox 2.0.0.20/Win32 in case it is not as reproducible as I would expect. -- assignee: georg.brandl components: Documentation files: multiprocessing.png messages: 78151 nosy: georg.brandl, scottdial severity: normal status: open title: Wide literals in the table of contents overflow in documentation type: behavior Added file: http://bugs.python.org/file12416/multiprocessing.png ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4711 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4666] test_bad_address in test_urllib2_localnet often fails
Roumen Petrov bugtr...@roumenpetrov.info added the comment: Tests (trunk 21 dec 2008) fail as before (i.e. test_curses, test_urllib2_localnet and test_urllibnet) but now test_smtplib fail too. Single test always succeed as example: $ echo test_smtplib /tmp/pynexttest $ ./python -E -tt ../Lib/test/regrtest.py -l -s test_smtplib 1 test OK. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4666 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1712522] urllib.quote throws exception on Unicode URL
Valery khame...@gmail.com added the comment: Hi, gurus, can anyone then give a hint what we mortals should use in order to form the URL with non-ascii symbols? We loved so much idea to feed our national symbols to urllib.quote as unicode string... and now we are quite disoriented... Thanks in advance for any comments! Valery -- nosy: +vak ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1712522 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4712] Document pickle behavior for subclasses of dicts/lists
New submission from Georg Brandl ge...@python.org: When unpickling dict subclasses, the dict is filled via setitem before __setstate__ is called. This, and other behavior around subclasses of classes that have special pickle behavior should be documented. -- assignee: georg.brandl components: Documentation messages: 78154 nosy: aronacher, georg.brandl priority: low severity: normal stage: needs patch status: open title: Document pickle behavior for subclasses of dicts/lists type: behavior versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1712522] urllib.quote throws exception on Unicode URL
Valery khame...@gmail.com added the comment: (self-answer to msg78153) the working recipe is: http://www.nabble.com/Re:-Problem:-neither-urllib2.quote-nor- urllib.quote-encode-the--unicode-strings-arguments-p19823144.html ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1712522 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4713] Installing sgmlop can crash xmlrpclib
New submission from Christoph Zwerschke c...@online.de: If you install sgmlop (downloadable from http://effbot.org/downloads/#sgmlop) under Python 2.x, then this can break xmlrpclib. You can reproduce this problem as follows (I have tested with Py 2.4, 2.5 and 2.6): data = ?xml version=1.0 encoding=UTF-8? methodCallmethodNamef/methodNameparams paramvaluek#228;se/value/param /params/methodCall import xmlrpclib assert xmlrpclib.FastParser is None print xmlrpclib.SgmlopParser and 'with' or 'without', 'sgmlop' assert xmlrpclib.loads(data) == ((u'k\xe4se',), 'f') If sgmlop is installed, this gives a UnicodeDecodeError, otherwise everything works well. This happens because xmlrpclib prefers using sgmlop over lib.parsers.expat, but fails to handle numeric character entities properly with this parser. Find attached a patch that fixes this problem. I also wonder whether lib.parsers.expat shouldn't be preferred over sgmlop, since the latter is somewhat outdated, and installing external libraries should not cause crashes or wrong behavior of standard lib modules (see also Issue1772916 for a similar problem). -- components: Library (Lib) messages: 78156 nosy: cito severity: normal status: open title: Installing sgmlop can crash xmlrpclib type: crash versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4713] Installing sgmlop can crash xmlrpclib
Changes by Christoph Zwerschke c...@online.de: -- keywords: +patch Added file: http://bugs.python.org/file12418/xmlrpclib.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4714] print opcode stats at the end of pybench runs
New submission from Antoine Pitrou pit...@free.fr: This patch prints opcode statistics at the end of a pybench run if DYNAMIC_EXECUTION_PROFILE has been enabled when compiling the interpreter. Is it ok? Is it better to add it to the Benchmark class? -- components: Demos and Tools files: pybench-opcodestats.patch keywords: patch messages: 78157 nosy: lemburg, pitrou priority: normal severity: normal stage: patch review status: open title: print opcode stats at the end of pybench runs type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file12417/pybench-opcodestats.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4714 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4710] [PATCH] zipfile.ZipFile does not extract directories properly
Koen van de Sande k...@tibed.net added the comment:
I'm no expert, but is it possible for ZIP files to have Windows-style
path seperators ('\') as well?
And is this new behavior desirable for existing code as well? It might
break existing applications, so perhaps a new extractrecursive()
function is more intuitive.
Finally, I've noticed that the patch does not add any tests to test for
the new/old behavior.
--
nosy: +koen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4710
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4715] optimize bytecode for conditional branches
New submission from Antoine Pitrou pit...@free.fr: This patch optimizes the bytecode for conditional branches. For example, the list comprehension [x for x in l if not x] produced the following bytecode: 1 0 BUILD_LIST 0 3 LOAD_FAST0 (.0) 6 FOR_ITER23 (to 32) 9 STORE_FAST 1 (x) 12 LOAD_FAST1 (x) 15 JUMP_IF_TRUE10 (to 28) 18 POP_TOP 19 LOAD_FAST1 (x) 22 LIST_APPEND 2 25 JUMP_ABSOLUTE6 28 POP_TOP 29 JUMP_ABSOLUTE6 32 RETURN_VALUE but after the patch it produces the following bytecode: 1 0 BUILD_LIST 0 3 LOAD_FAST0 (.0) 6 FOR_ITER18 (to 27) 9 STORE_FAST 1 (x) 12 LOAD_FAST1 (x) 15 POP_JUMP_IF_TRUE 6 18 LOAD_FAST1 (x) 21 LIST_APPEND 2 24 JUMP_ABSOLUTE6 27 RETURN_VALUE Notice that not only the code is shorter, but the conditional jump (POP_JUMP_IF_TRUE) jumps right to the start of the loop instead of going through the JUMP_ABSOLUTE at the end. continue statements are helped similarly. Furthermore, the old jump opcodes (JUMP_IF_FALSE, JUMP_IF_TRUE) could profitably be replaced by two new opcodes: - one which jumps if true and pops otherwise - one which jumps if false and pops otherwise -- components: Interpreter Core files: condbranches.patch keywords: patch messages: 78159 nosy: pitrou severity: normal stage: patch review status: open title: optimize bytecode for conditional branches type: resource usage versions: Python 3.1 Added file: http://bugs.python.org/file12419/condbranches.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4710] [PATCH] zipfile.ZipFile does not extract directories properly
Kuba Wieczorek faw...@gmail.com added the comment: I'm not sure if it would make sense to save current extract()/extractall() behaviour and implement new with another function because current one is simply faulty. And if it's about BC breaks then well... it may be introduced in 3.0 line, I think that leaving faulty behaviour and introducing another with another function misses the point. AFAIK there'd be no problem with Windows-style paths but to be sure I revised my patch. Yes, I'm sorry for the lack of tests, it is my first patch and I forgot about this. I'll write them in a couple of hours. Added file: http://bugs.python.org/file12420/zipfile_extract_dirs_r2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4710 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Martin v. Löwis mar...@v.loewis.de added the comment: Unfortunately, the patch is broken. The program fname='test123' f=open(fname,'w') f.read() crashes with the patch applied. I think I will revert the patch in 2.5.3, release 2.5.4, and reject the patch. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Guilherme Polo ggp...@gmail.com added the comment: It isn't being careful when calling PyErr_SetFromErrno inside the Py_UniversalNewlineFread function since this function is being called all over fileobject after releasing the GIL.. so, isn't this just a matter of adding pairs of PyGILState_Ensure/PyGILState_Release around these calls to PyErr_SetFromErrno in this specific function ? -- nosy: +gpolo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706039] Added clearerr() to clear EOF state
Guilherme Polo ggp...@gmail.com added the comment: On Sun, Dec 21, 2008 at 9:52 PM, Martin v. Löwis rep...@bugs.python.org wrote: Martin v. Löwis mar...@v.loewis.de added the comment: It isn't being careful when calling PyErr_SetFromErrno inside the Py_UniversalNewlineFread function since this function is being called all over fileobject after releasing the GIL.. so, isn't this just a matter of adding pairs of PyGILState_Ensure/PyGILState_Release around these calls to PyErr_SetFromErrno in this specific function ? Perhaps that could fix this problem (or perhaps not - is PyGILState_Ensure guaranteed to do the right thing, even in the presence of multiple interpreters?) It is said to be unsupported in that case, but I guess you knew that. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1706039 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4715] optimize bytecode for conditional branches
Antoine Pitrou pit...@free.fr added the comment: Here is an optional patch which provides the two opcodes I was talking about (I've called them POP_OR_JUMP and JUMP_OR_POP). Together with a bit of work on the peepholer they make the bytecode expression of boolean calculations very concise. A somewhat contrived example: f = lambda x,y,z,v: (z if x else y) or v Without the patch: 1 0 LOAD_FAST0 (x) 3 JUMP_IF_FALSE7 (to 13) 6 POP_TOP 7 LOAD_FAST2 (z) 10 JUMP_FORWARD 4 (to 17) 13 POP_TOP 14 LOAD_FAST1 (y) 17 JUMP_IF_TRUE 4 (to 24) 20 POP_TOP 21 LOAD_FAST3 (v) 24 RETURN_VALUE With the patch: 1 0 LOAD_FAST0 (x) 3 POP_JUMP_IF_FALSE 12 6 LOAD_FAST2 (z) 9 JUMP_FORWARD 3 (to 15) 12 LOAD_FAST1 (y) 15 JUMP_OR_POP 21 18 LOAD_FAST3 (v) 21 RETURN_VALUE Added file: http://bugs.python.org/file12421/condbranches-plus.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3297] Python interpreter uses Unicode surrogate pairs only before the pyc is created
Changes by hippietrail hippytr...@gmail.com: -- nosy: +hippietrail ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4708] os.pipe should return inheritable descriptors (Windows)
Gabriel Genellina gagsl-...@yahoo.com.ar added the comment: From the thread in c.l.p: Pros (of changing os.pipe() to return inheritable pipes): - as it isn't explicitely documented whether os.pipe() returns inheritable pipes or not, both versions are right according to the documentation. - if someone relies on pipes being non-inheritable on Windows (why?), this is undocumented behaviour, and Python has the right to change it. - would improve POSIX compatibility, it mimics what os.pipe() does on those OS - inheritable pipes are less surprising for guys coming from other OS - inheritable pipes are a lot more useful than non-inheritable ones when doing IPC (probably its main usage). Cons: - os.pipe has behaved that way since long time ago. - some programs *might* break, if they relied on pipes being non-inheritable on Windows, even if that was undocumented behaviour. -- nosy: +gagenellina ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4708 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
