[issue5042] Structure sub-subclass does not initialize with base class positional arguments

Thomas Heller added the comment: I've commited a slightly changed patch plus a test. trunk: 74917, py3k: 74918, release26-maint: 74919, release31-maint: 74920. -- ___ Python tracker <http://bugs.python.org/i

[issue5042] Structure sub-subclass does not initialize with base class positional arguments

Changes by Thomas Heller : -- resolution: -> fixed status: open -> closed versions: -Python 2.5 ___ Python tracker <http://bugs.python.org/issue5042> ___ __

[issue4606] Passing 'None' if argtype is set to POINTER(...) doesn't always result in NULL

Thomas Heller added the comment: Comitted as trunk: 74921, py3k: 74922, release31-maint: 74923, release26-maint: 74924 -- resolution: accepted -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue6613] ctypes.PyThreadState_SetAsyncExc does not work on linux 64bit machines

Thomas Heller added the comment: I guess this is a bug in your code, as mentioned in my last comment, so closing as invalid. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue6729] Add support for ssize_t

Thomas Heller added the comment: Find where c_size_t is defined: in Lib/ctypes/__init__.py -- ___ Python tracker <http://bugs.python.org/issue6729> ___ ___ Pytho

[issue6918] ctypes compilation error on SnowLeopard

Thomas Heller added the comment: This one is fixed, isn't it? See for example the buildbot output at http://www.python.org/dev/buildbot/2.6/builders/x86%20osx.5%202.6/builds/566/steps/compile/logs/stdio (Search for "building '_ctypes' extension" on the page)

[issue6958] Add Python command line flags to configure logging

New submission from Thomas Heller : I want the Python executable to have command line flags which allow simple configuration of the logging module. Use cases are to run applications/scripts (which use libraries that use logging calls) with different logging output without having to edit (ugly

[issue6958] Add Python command line flags to configure logging

Thomas Heller added the comment: > I get the idea. The Python part of the patch demonstrates what you're > getting at, though it can't be used as is - for example the > getattr(logging, a, a) could lead to problems. However a more > intelligent parser (which looked

[issue6958] Add Python command line flags to configure logging

Thomas Heller added the comment: > Why does this need to be built into the interpreter? The script / app > should have logging config support. It does not need to, but it would be nice. I think the '-l' flag should be similar to the -W flag. Or consider for example using un

[issue6958] Add Python command line flags to configure logging

Thomas Heller added the comment: > Jean-Paul Calderone: > > How about putting this into the logging module instead? Instead of > "python ", making it > "python -m logging > This: > > * involves no changes to the core interpreter > *

[issue6958] Add Python command line flags to configure logging

Thomas Heller added the comment: > How do these "global" settings (either via the interpreter or a wrapper > in the logging module) change what an app might do on its own? IOW, if > my app is already written to configure logging, and someone invokes it > with these

[issue6958] Add Python command line flags to configure logging

Thomas Heller added the comment: I retract this request. It seems the idea is not liked or a solution is not easy. (The solution I now use is to start Python from a batch file that parses some command line flags itself, sets environment variables, and my sitecustomize.py file configures

[issue7103] Error in config parser example (w/ Patch)

New submission from Thomas Courbon : When ran in python 3.1.1 (hand compiled, fedora 11), the first example of configparser module fail with : Traceback (most recent call last): File "test1.py", line 22, in config.write(configfile) File "/usr/local/lib/python3.1/configp

[issue7103] Error in config parser example (w/ Patch)

Changes by Thomas Courbon : -- keywords: +patch Added file: http://bugs.python.org/file15101/configparser_example_issue_7103.patch ___ Python tracker <http://bugs.python.org/issue7

[issue7103] Error in config parser example (w/ Patch)

Thomas Courbon added the comment: Due to its quite generic title I was unable to find this issue. Sorry for the duplicate. Thomas -- ___ Python tracker <http://bugs.python.org/issue7

[issue7143] get_payload(decode=True) eats last newline

New submission from Andreas Thomas : The attachment of my sample email contains '123\n', but get_payload (decode=True) returns '123'. The source of this error is the function _bdecode from the email.utils module, which gets called for decoding base64 encoded payloads. He

[issue7179] Unportable test(1) construct

New submission from Thomas Klausner : Mac/BuildScript/scripts/postflight.patch-profile and Misc/build.sh contain the unportable bash(1) "==" comparison operator for test(1). It is not supported by most other shells or even test(1) from GNU coreutils. Please use &

[issue7179] Unportable test(1) construct

Thomas Klausner added the comment: That's against python-2.6.3. I see that Misc/build.sh automagically linked from this bug report doesn't have this problem any longer (though the other file still does). -- ___ Python trac

[issue7204] Strange shebang line in test_pep263

New submission from Thomas Klausner : In Python-2.6.3, test_pep263.py starts with the following line: #! -*- coding: koi8-r -*- When this is executed by a shell, it looks for the interpreter "-*-". I guess the '!' is superfluous there, or it should be something like #!

[issue5510] patches for Modules/socketmodule.c for NetBSD

Thomas Klausner added the comment: Attached is the patch fixing this problem from pkgsrc; it was written by Iain Hibbert who also maintains BlueTooth in NetBSD, so I'm very confident it's "right" :) Please include it! -- nosy: +wiz Added file: http://bugs.python

[issue3244] multipart/form-data encoding

Changes by Thomas Guettler : -- nosy: +guettli ___ Python tracker <http://bugs.python.org/issue3244> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

Thomas Courbon added the comment: *bump* Hi there Pythoners ! As Timothy Farrell I'm currently working (or rather, toying since it just for fun) on a Python3 web framework. I just started but when it come to file upload I experience issues which I believe are connected to that issue.

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

Thomas Courbon added the comment: It seems that there wasn't work on that issue (which look complicated by the way). I'll wait, there is so much other aspects of a web framework to play with :) Thank anyway for the pointer. -- ___ Pyth

[issue5673] Add timeout option to subprocess.Popen

Changes by Thomas Guettler : -- nosy: +guettli ___ Python tracker <http://bugs.python.org/issue5673> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7356] parsing of ldconfig output in ctypes/utils.py depends on the locale

Thomas Heller added the comment: I'm curious: Which output do you get from: 'LANG=C /sbin/ldconfig -p | fgrep GL' -- ___ Python tracker <http://bugs.py

[issue7356] parsing of ldconfig output in ctypes/utils.py depends on the locale

Thomas Heller added the comment: I assume the patch is fine, would you like to apply it? Thanks. -- ___ Python tracker <http://bugs.python.org/issue7

[issue1100942] Add datetime.time.strptime and datetime.date.strptime

Changes by Thomas Guettler : -- nosy: +guettli ___ Python tracker <http://bugs.python.org/issue1100942> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7446] http.cookies.BaseCookie (and SimpleCookie) can't be load from dict

New submission from Thomas Courbon : Hi there ! According the documentation [1], the following code should work : >>> from http.cookies import SimpleCookie >>> c = SimpleCookie({'field1': 'value1', 'field2': 'value2'}) >>> pri

[issue7603] There is no 'seq' type

New submission from Thomas Oldbury : I find myself often writing the following code: if isinstance(var, (tuple, list, basestring)): to determine if a var is indexable and iterable. It would be simpler if there were a 'seq' type which is subclassed into mutableseq and immuta

[issue5377] Strange behavior when performing int on a Decimal made from -sys.maxint-1

Changes by Thomas Heller : -- components: -ctypes nosy: -theller ___ Python tracker <http://bugs.python.org/issue5377> ___ ___ Python-bugs-list mailin

[issue5377] Strange behavior when performing int on a Decimal made from -sys.maxint-1

Changes by Thomas Heller : -- assignee: theller -> ___ Python tracker <http://bugs.python.org/issue5377> ___ ___ Python-bugs-list mailing list Unsubscri

[issue5477] Typo in itertools documentation

New submission from Thomas Guest : http://docs.python.org/3.0/library/itertools.html says: > The tools also work well with the high-speed functions in the operator module. For example, the plus-operator can be mapped across two vectors to form an efficient dot-product: sum(map(operator.

[issue2123] ctypes pointer not always keeping target alive

Thomas Heller added the comment: I accept this as a bug; however I don't have time now to work on it. -- ___ Python tracker <http://bugs.python.org/i

[issue5608] Add python.exe to the path in windows?

New submission from Thomas Willis : All the vast amounts of documentation out there on how to do neat things with python seem to assume that python is already in the system path. It would be nice if the installer went ahead and set this up for the user. In my experience there are windows users

[issue3102] ctypes defines global symbols

Thomas Heller added the comment: I think simple renaming would be fine. I do not see how module_methods could be made static; however, the init_callbacks_in_module function should probably be removed completely. Some other symbols could be made static because they are only used in a single

[issue5710] ctypes should return composite types from callbacks

Thomas Heller added the comment: There is a problem returning arbitrary complicated ctypes types from callbacks. Consider that a callback function returns a structure; the structure itself may contain 'char *' field for example. The callback function creates the structure and fi

[issue1006238] cross compile patch

Changes by Thomas Heller : -- nosy: +theller ___ Python tracker <http://bugs.python.org/issue1006238> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)

Thomas Heller added the comment: Joshua Kinard schrieb: > Joshua Kinard added the comment: > > Is there any movement on this perchance? Just bumped into this on my > MIPS platform and discovered this bug. There is no MIPS buildbot at the moment, and I'm unclear which o

[issue3102] ctypes defines global symbols

Thomas Heller added the comment: Here is a quite large patch (300 lines) against svn trunk that renames a lot of symbols. The list of symbols, listed by 'nm -g --defined-only _ctypes.so' is as follows: thel...@tubu32:~/devel/trunk$ find . -name _ctypes.so | xargs nm -g --defined-onl

[issue3102] ctypes defines global symbols

Thomas Heller added the comment: Correction: The patch has 3000 lines, not 300. And I think that the 'My_Unicode_...' functions can be removed because they are not used anywhere. I have to check this. -- ___ Python tracker <http://bu

[issue5161] wrong paths for ctypes cleanup

Thomas Heller added the comment: Fixed in trunk svn rev. 71842, I will merge this into the py3k branch soon. -- resolution: -> fixed status: open -> closed versions: +Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.org/

[issue2774] ctypes documentation not effective

Thomas Heller added the comment: Unassigning; myself I will not rewrite the ctypes docs. -- assignee: theller -> ___ Python tracker <http://bugs.python.org/iss

[issue5049] ctypes unwilling to allow pickling wide character

Thomas Heller added the comment: Thanks, amaury, for the patch. Fixed in trunk, release26-maint, release30-maint, py3k branch. SVN revisions 71847, 71848, 71849, 71851. -- keywords: -needs review resolution: -> fixed status: open -> closed versions: +Python 2.7, Pyth

[issue3102] ctypes defines global symbols

Thomas Heller added the comment: Fixed in trunk (svn rev 71853). I'll leave this open until it is ported to py3k. -- resolution: -> accepted versions: +Python 2.7, Python 3.1 ___ Python tracker <http://bugs.python.or

[issue3102] ctypes defines global symbols

Thomas Heller added the comment: BTW: The 'My_Unicode...' symbols are gone, too. -- ___ Python tracker <http://bugs.python.org/issue3102> ___ ___

[issue3102] ctypes defines global symbols

Thomas Heller added the comment: svn rev 71845, in py3k branch. -- resolution: accepted -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue5078] Avoid redundant call to FormatError()

Thomas Heller added the comment: Fixed in trunk and py3k branch, svn revisions 71906 and 71907. Thanks for the patch. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)

Thomas Heller added the comment: I wonder if fixes for issues like these (ctypes build errors on some plaforms) could be verified by using cross compilers on linux? -- ___ Python tracker <http://bugs.python.org/issue4

[issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)

Thomas Heller added the comment: I've applied py-issue-4305.patch and reran configure 2.61. Committed as rev 72081 (trunk), 72082 (py3k branch), 72083 (release26-maint branch), 72084 (release30-maint branch). Can someone please confirm that it works now, so that I can close this

[issue5413] urllib ctypes error on Mac OS X Server 10.5

Thomas Heller added the comment: Seems ronald takes care of this issue. -- assignee: theller -> ronaldoussoren ___ Python tracker <http://bugs.python.org/iss

[issue5507] ctypes configuration fails on mips-linux (and probably Irix)

Thomas Heller added the comment: Duplicate of issue 4305. -- resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue4538] ctypes could include data type limits

Thomas Heller added the comment: Isn't is easy to find these limits by using ctypes? Something like ctypes.sizeof(ctypes.c_uint32)... -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python

[issue4875] find_library can return directories instead of files

Changes by Thomas Heller : -- versions: +Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4875> ___ ___ Python-bugs-list mailin

[issue4305] ctypes fails to build on mipsel-linux-gnu (detects mips instead of mipsel)

Thomas Heller added the comment: Tested myself, on a mipsel debian qemu instance. -- resolution: accepted -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC

Thomas Heller added the comment: Hm, I don't see any problems with current Python trunk or the release26-maint branch, on a Fedora 10 system. -- ___ Python tracker <http://bugs.python.org/i

[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC

Thomas Heller added the comment: > Try this as root, then repeat your test: > semanage boolean -m --off allow_execstack Ok, I can reproduce the problem now. Thanks! -- title: ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC -> ctypes sh

[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC

Thomas Heller added the comment: Here is a patch for Python trunk (linux only). -- Added file: http://bugs.python.org/file13897/issue5504.patch ___ Python tracker <http://bugs.python.org/issue5

[issue4875] find_library can return directories instead of files

Thomas Heller added the comment: Fixed in trunk (rev 72352), release26-maint (rev 72353), py3k (rev 72354), and release30-maint (rev 72355). -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue1648957] HP-UX: _ctypes/libffi/src/ia64/ffi/__attribute__/native cc

Changes by Thomas Heller : -- components: -Build stage: test needed -> ___ Python tracker <http://bugs.python.org/issue1648957> ___ ___ Python-bugs-list mai

[issue1581906] test_sqlite fails on OS X if test_ctypes is run

Thomas Heller added the comment: So, should this be closed as some kind of 'works for me' + 'wont fix' + 'third-party-bug' in Apple's sqlite? -- ___ Python tracker &

[issue6013] json slower than simplejson

New submission from Thomas Heller : The json package is a lot slower than the simplejson package. Both packages have their C compiled speedup module; however: C:\>py26 -m timeit -s "from json import dumps, loads" "loads(dumps(range(32)))" 1000 loops, best of 3:

[issue6013] json slower than simplejson

Thomas Heller added the comment: Here are the numbers from trunk (rev ) and release26-maint branch (rev ): c:\svn\release26-maint\PCbuild>python -m timeit -s "from json import loads, dumps" "loads(dumps(range(32)))" 1000 loops, best of 3: 726 usec per loop c:\svn\rel

[issue6051] smtplib docs should link to email module examples

New submission from Thomas Guettler : On "smtplib example": http://docs.python.org/library/smtplib.html#smtp-example should be a link to: http://docs.python.org/library/email-examples.html I think the smtplib example is bad, since the email gets created with a string. That's n

[issue6061] time.clock(): overflow in programs that run for very long

New submission from Thomas Reiter : On a 64-bit Linux machine the attached program generates the following (shortened) output: $ python bug.py ... after 2145.49s: after 2145.82s: after 2146.14s: after 2146.47s: after 2146.80s: after 2147.13s: after 2147.45s: after -2147.19s: Here's

[issue6061] time.clock(): overflow in programs that run for very long

Thomas Reiter added the comment: That version of Python is linked against 32-bit libc. Point of overflow corresponds to 2^31 us. -- status: open -> closed ___ Python tracker <http://bugs.python.org/iss

[issue6121] help('modules ') causes IndexError.

Changes by Thomas Heller : -- assignee: theller -> components: -ctypes nosy: -theller ___ Python tracker <http://bugs.python.org/issue6121> ___ ___ Python-

[issue6259] ctypes pointer arithmetic

New submission from Thomas Heller : This patch implements some pointer arithmetic operations for ctypes. -- files: ctypes-pointerarith.patch keywords: patch messages: 89225 nosy: theller severity: normal status: open title: ctypes pointer arithmetic type: behavior versions: Python 2.7

[issue6259] ctypes pointer arithmetic

Changes by Thomas Heller : -- assignee: -> theller components: +ctypes versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue6259> ___ ___ Py

[issue6305] islice doesn't accept large stop values

New submission from Thomas Guest : Python 3.0 (r30:67503, Jan 7 2009, 16:22:01) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin >>> from itertools import islice, count >>> islice(count(), (1<<31) - 1) >>> islice(count(), (1<<31)) Traceback (mo

[issue6388] platform.python_implementation does not work on IronPython

New submission from Thomas Bleier : platform.python_implementation as of CPython 2.6 does not work on IronPython 2.0.1 It obviously crashes because it fails determining that it run's on IronPython. >>> platform.python_implementation() Traceback (most recent call last): File

[issue8897] sunau bytes / str TypeError in Py3k

New submission from Thomas Jollans : The sunau module, essentially, "doesn't work". This looks like a problem with the bytes/unicode transition of "str" in Python 3.x vs Python 2: Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48) [GCC 4.4.3] on linux2 Type "he

[issue8897] sunau bytes / str TypeError in Py3k

Thomas Jollans added the comment: Attached is a patch against the current py3k trunk that fixes this. (as far as I can tell) -- keywords: +patch Added file: http://bugs.python.org/file17580/sunau-bytes.diff ___ Python tracker <h

[issue8897] sunau bytes / str TypeError in Py3k

Thomas Jollans added the comment: test case for sunau, as requested. Loosely based on test_wave. -- Added file: http://bugs.python.org/file17582/sunau-test.diff ___ Python tracker <http://bugs.python.org/issue8

[issue8934] aifc should use str instead of bytes (wave, sunau compatibility)

New submission from Thomas Jollans : aifc getcomptype() and setcomptype() use bytes while the corresponding methods in the sunau and wave modules use str (b'NONE', b'ULAW' vs 'NONE', 'ULAW'). This means that programmers wanting simple format-agnostic

[issue8934] aifc should use str instead of bytes (wave, sunau compatibility)

Thomas Jollans added the comment: tentative documentation patch uploaded -- Added file: http://bugs.python.org/file17584/aifc_str_doc.diff ___ Python tracker <http://bugs.python.org/issue8

[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7

Thomas Heller added the comment: The commit that breaks the examples is revision 80761. Tested on WinXP 32 bit. Someone should test on Win 64bit too ;-). -- priority: normal -> release blocker ___ Python tracker <http://bugs.python.org/iss

[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7

Thomas Heller added the comment: Problem in py3k branch also. -- versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue8959> ___ ___ Python-bug

[issue8990] array constructor and array.fromstring should accept bytearray.

New submission from Thomas Jollans : Currently, the array constructor, if given a bytearray, detects this with PyByteArray_Check, and hands it on to array_fromstring, which does not support bytearray (by using "s#" with PyArg_ParseTuple) and raises TypeError. >>> a

[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7

Thomas Heller added the comment: > Is r80761 something that can be safely reverted? Yes, I think so. -- ___ Python tracker <http://bugs.python.org/iss

[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7

Thomas Heller added the comment: Fixed in rev. 82127 (trunk) and rev 82138 (py3k). Added test for the issues reported here so that it doen't happen again. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://b

[issue8959] WINFUNCTYPE wrapped ctypes callbacks not functioning correctly in Python 2.7

Thomas Heller added the comment: Thanks, Michael, for reporting this issue. -- ___ Python tracker <http://bugs.python.org/issue8959> ___ ___ Python-bugs-list m

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: Thanks for the input. I'm going to re-work the patch a bit (releasing buffers and such) and add a test within the next few days. The question remains whether or not to accept other buffers with itemsize == 1. The way I understand it, fromstring al

[issue9055] test_issue_8959_b fails when run from a service

Thomas Heller added the comment: > To test windows callbacks, I suggest to use EnumResourceTypes() > instead, which is more likely to work in any condition: Unfortunately the proposed test doesn't detect the problem in Python2.7 rc1. It runs without crashing, even if enumerating th

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: OK, here's the new patch. I added tests for array(typecode, bytearray(b'abab')), a.extend(b'123') and a.extend(bytearray(b'123')). @Victor: int itemsize is the array's item size, buffer.itemsize is the strings'

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: Two more patches: Firstly, this patch (array_3.2_fromstring.diff) is nearly identical to array2.diff. "y*" would (again) have to be changed to "s*" to apply this to 3.1 -- Added file: http://bugs.python.org/file17826/array

[issue8990] array constructor and array.fromstring should accept bytearray.

Thomas Jollans added the comment: Secondly, this is my attempt to add the more sensibly named {to|from}bytes methods, and to deprecate {to|from}string. I doubt it's perfect, maybe there's some policy on deprecating methods that I didn't find? This may be better discussed in a

[issue8990] array constructor and array.fromstring should accept bytearray.

Changes by Thomas Jollans : Added file: http://bugs.python.org/file17828/tofrombytes.diff ___ Python tracker <http://bugs.python.org/issue8990> ___ ___ Python-bugs-list m

[issue8990] array constructor and array.fromstring should accept bytearray.

Changes by Thomas Jollans : Removed file: http://bugs.python.org/file17827/tofrombytes.diff ___ Python tracker <http://bugs.python.org/issue8990> ___ ___ Python-bug

[issue1553375] Add traceback.print_full_exception()

Changes by Thomas Guettler : -- nosy: +guettli ___ Python tracker <http://bugs.python.org/issue1553375> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1553375] Add traceback.print_full_exception()

Thomas Guettler added the comment: It would be very nice if logging.info('...', exc_info=True) shows the calling/upper frames, too. -- ___ Python tracker <http://bugs.python.org

[issue9427] logging.error('...', exc_info=True) should display upper frames, too

New submission from Thomas Guettler : logging.error('...', exc_info=True) only displays the frames downward. But I often need the upper frames, to debug a problem. This example shows, that you don't see the "upper" frame in the stactrace. But that's information

[issue9427] logging.error('...', exc_info=True) should display upper frames, too

Thomas Guettler added the comment: Related: #1553375 -- ___ Python tracker <http://bugs.python.org/issue9427> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1553375] Add traceback.print_full_exception()

Thomas Guettler added the comment: Related #9427 -- ___ Python tracker <http://bugs.python.org/issue1553375> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9427] logging.error('...', exc_info=True) should display upper frames, too

Thomas Guettler added the comment: I tested it only on python 2.6. Can someone please look at more reset versions? -- ___ Python tracker <http://bugs.python.org/issue9

[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC

Thomas Heller added the comment: The libffi library included with Python has been updated in the meantime, so most of the issue5504-linux.patch is unneeded now. Here is a new patch, issue5504-py27.patch, against the current release27-maint branch. Seems it is exactly the same as the fedora

[issue4453] MSI installer shows error message if "Compile .py files to bytecode" option is selected

Aaron Thomas added the comment: 3.1, yes, same problem 2.7, I'll check what's 2a? Aaron On Aug 3, 2010 10:00 PM, "Terry J. Reedy" wrote: Terry J. Reedy added the comment: Can either of you check 2.7/3.1 or 2a? -- nosy: +tjreedy versions: +Python 2.7 -Py

[issue9427] logging.error('...', exc_info=True) should display upper frames, too

Thomas Guettler added the comment: Until exc_info=True prints the current stack, I use this pattern: import traceback logging.error(u's...\nStack: %s' % ( ''.join(traceback.format_stack())), exc_info=True) -- ___ P

[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC

Thomas Heller added the comment: issue5504-py27-2.patch is the updated patch that now also works on Windows. -- Added file: http://bugs.python.org/file18439/issue5504-py27-2.patch ___ Python tracker <http://bugs.python.org/issue5

[issue5504] ctypes should work with systems where mmap can't be PROT_WRITE and PROT_EXEC

Thomas Heller added the comment: Fixed in rev 83836 (release27-maint branch) and rev. 83837 (py3k branch). -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue6869] Embedded python crashed on 4th run, if "ctypes" is used

Thomas Heller added the comment: Fixed in rev 83841 (py3k), rev 83842 (release31-maint), and rev 83843 (release27-maint). Thanks for the patch. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

<    10   11   12   13   14   15   16   17   18   19   >