difflib.SequenceMatcher fails for larger strings

I'm trying to write a program to test a persons typing speed and show them their mistakes. However I'm getting weird results when looking for the differences in longer strings: import difflib a =

[issue24964] Add tunnel CONNECT response headers to httplib / http.client

Thomas added the comment: Martin: Thanks for your quick answer (and sorry for sending the whole file) ! I think it is indeed a good idea to detach the proxy connection and treat it as any other connection, as you did in your patch. It would be great if you would be able to dig it up

[issue26628] Segfault in cffi with ctypes.union argument

New submission from Thomas: Passing ctypes.Union types as arguments crashes python. Attached is a minimal example to reproduce. Due to undefined behavior, you may have to increase the union _fields_ to reproduce. I tested with 3.5.1 and 2.7.11. It seems that cffi treats the union as a normal

[issue26628] Segfault in cffi with ctypes.union argument

Thomas added the comment: Note [http://www.atmark-techno.com/~yashi/libffi.html] > Although ‘libffi’ has no special support for unions or bit-fields, it is > perfectly happy passing structures back and forth. You must first describe > the structure to ‘libffi’ by creating a new

[issue26628] Undefined behavior calling C functions with ctypes.Union arguments

Thomas added the comment: So after some more pondering about the issue I read the documentation again: > Warning ctypes does not support passing unions or structures with bit-fields > to functions by value. Previously I always read this as 'does not support passing unions with bit-

[issue26628] Undefined behavior calling C functions with ctypes.Union arguments

Changes by Thomas <bugs.pyt...@zulan.net>: Added file: http://bugs.python.org/file42372/libfoo.c ___ Python tracker <rep...@bugs.python.org> <http://bugs.python

[issue26628] Undefined behavior calling C functions with ctypes.Union arguments

Thomas added the comment: Thanks Eryk for the additional explanation. I added a more elaborate example that doesn't abuse the standard c function that actually doesn't expect a union: % gcc -shared -fPIC libfoo.c -o libfoo.so -Wall % python pyfoo.py *** stack

[issue26657] Directory traversal with http.server and SimpleHTTPServer on windows

Thomas added the comment: Martin Panter: Regarding the warning, you appear to be correct. However, reading the source of http.server again made me notice _url_collapse_path(path) which seems to have some overlap with translate_path. Also it crashes with an IndexError if path contains '..'. Also

[issue26657] Directory traversal with http.server and SimpleHTTPServer on windows

New submission from Thomas: SimpleHTTPServer and http.server allow directory traversal on Windows. To exploit this vulnerability, replace all ".." in URLs with "c:c:c:..". Example: Run python -m http.server and visit 127.0.0.1:8000/c:c:c:../secret_file_that_should_be_s

[issue26833] returning ctypes._SimpleCData objects from callbacks

New submission from Thomas: If a callback function returns a ctypes._SimpleCData object, it will fail with a type error and complain that it expects a basic type. Using the qsort example: def py_cmp_func(a, b): print(a.contents, b.contents) return c_int(0) > TypeError: an inte

[issue26799] gdb support fails with "Invalid cast."

Thomas added the comment: I have done a bit more digging, turns out it is actually no problem at all to debug python in gdb with gdb with python support (at least using a fixed python-gdb-py). Turns out the type->length of the the globally initialized ptr types is wrong: It is 4 instead o

[issue26799] gdb support fails with "Invalid cast."

New submission from Thomas: Trying to use any kind of python gdb integration results in the following error: (gdb) py-bt Traceback (most recent call first): Python Exception Invalid cast.: Error occurred in Python command: Invalid cast. I have tracked it down to the _type_... globals, and I

[issue26799] gdb support fails with "Invalid cast."

Thomas added the comment: The second option seems like the safest choice, attached is a patch that addresses just that. -- keywords: +patch Added file: http://bugs.python.org/file42538/gdb-python-invalid-cast.patch ___ Python tracker <

[issue26799] gdb support fails with "Invalid cast."

Thomas added the comment: Thank you for the quick integration and fixing the return. I have signed the electronic form yesterday. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/i

[issue24882] ThreadPoolExecutor doesn't reuse threads until #threads == max_workers

Thomas added the comment: We ran into this issue in the context of asyncio which uses an internal ThreadPoolExecutor to provide an asynchronous getaddrinfo / getnameinfo. We observed an async application spawned more and more threads through several reconnects. With a maximum of 5 x CPUs

[issue42369] Reading ZipFile not thread-safe

New submission from Thomas : According to https://docs.python.org/3.5/whatsnew/changelog.html#id108 bpo-14099, reading multiple ZipExtFiles should be thread-safe, but it is not. I created a small example where two threads try to read files from the same ZipFile simultaneously, which crashes

[issue42369] Reading ZipFile not thread-safe

Change by Thomas : -- components: +Library (Lib) type: -> crash ___ Python tracker <https://bugs.python.org/issue42369> ___ ___ Python-bugs-list mai

[issue42369] Reading ZipFile not thread-safe

Thomas added the comment: I have simplified the test case a bit more: import multiprocessing.pool, zipfile # Create a ZipFile with two files and same content with zipfile.ZipFile("test.zip", "w", zipfile.ZIP_STORED) as z: z.writestr("file1", b"0"*1

[issue42369] Reading ZipFile not thread-safe

Thomas added the comment: Scratch what I said in the previous message. I thought that the lock was created in _SharedFile and did not notice that it was passed as a parameter. -- ___ Python tracker <https://bugs.python.org/issue42

[issue42369] Reading ZipFile not thread-safe

Thomas added the comment: I have not observed any segfaults yet. Only zipfile.BadZipFile exceptions so far. The exact file at which it crashes is fairly random. It even crashes if all threads try to read the same file multiple times. I think the root cause of the problem is that the reads

[issue42369] Reading ZipFile not thread-safe

Thomas added the comment: The monkey patch works for me! Thank you very much! (I have only tested reading, not writing). However, the lock contention of Python's ZipFile is so bad that using multiple threads actually makes the code run _slower_ than single threaded code when reading a zip

[issue34451] docs: tutorial/introduction doesn't mention toggle of prompts

Change by Thomas : -- keywords: +patch nosy: +thmsdnnr nosy_count: 6.0 -> 7.0 pull_requests: +25650 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27105 ___ Python tracker <https://bugs.python.org/i

[issue43477] from x import * behavior inconsistent between module types.

New submission from Thomas : I'm looking for clarification as to how `from x import *` should operate when importing file/directory-based modules versus when importing a sub-module from within a directory-based module. While looking into a somewhat related issue with pylint, I noticed

[issue43477] from x import * behavior inconsistent between module types.

Thomas added the comment: Ahh, I always forget about blame. Though the form was different, the initial commit of `importlib` (authored by Brett, so the nosy list seems fine for the moment) behaved the same way, and had an additional comment noting that the section in question was included

[issue43477] from x import * behavior inconsistent between module types.

Thomas added the comment: I've spent a bit of time building (and rebuilding) Python 3.9 with a modified `Lib/importlib/_bootstrap.py`/regenerated `importlib.h` to give me some extra logging, and believe the answer I was looking for is `_find_and_load_unlocked`. `_find_and_load_unlocked

[issue44961] @classmethod doesn't set __wrapped__ the same way as functool's update_wrapper

New submission from Thomas : @classmethod defines a __wrapped__ attribute that always points to the inner most function in a decorator chain while functool's update_wrapper has been fixed to set the wrapper.__wrapped__ attribute after updating the wrapper.__dict__ (see https

[issue45259] No _heappush_max()

Change by Thomas : -- versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue45259> ___ ___

[issue45259] No _heappush_max()

New submission from Thomas : There is no heappush function for a max heap when the other supporting helper functions are already implemented (_siftdown_max()) -- components: Library (Lib) messages: 402351 nosy: ThomasLee94 priority: normal severity: normal status: open title

[issue45259] No _heappush_max()

Change by Thomas : -- nosy: +rhettinger, stutzbach -ThomasLee94 ___ Python tracker <https://bugs.python.org/issue45259> ___ ___ Python-bugs-list mailin

[issue39247] dataclass defaults and property don't work together

Thomas added the comment: Hello everyone, A quick look on SO and Google + this python issue + this blog post and its comments: https://florimond.dev/en/posts/2018/10/reconciling-dataclasses-and-properties-in-python/ show that this is still a problem where dataclass users keep hitting

[issue39247] dataclass defaults and property don't work together

Thomas added the comment: Thinking a little more about this, maybe a different solution would be to have default values be installed at the class level by default without being overwritten in the init, as is the case today. default_factory should keep being set in the init as is the case

[issue39247] dataclass defaults and property don't work together

Thomas added the comment: Scratch that last one, it leads to problem when mixing descriptors with actual default values: @dataclass class Foo: bar = field(default=some_descriptor) # technically this is a descriptor field without a default value or at the very least, the dataclass

[issue39247] dataclass defaults and property don't work together

Thomas added the comment: Agreed on everything but that last part, which I'm not sure I understand: > If we allow descriptor to accept an iterable as well you could have multiple > descriptors just like normal. Could you give an example of what you mean with a regular class? I've had

[issue39247] dataclass defaults and property don't work together

Thomas added the comment: Just to rephrase, because the explanation in my last message can be ambiguous: At dataclass construction time (when the @dataclass decorator inspects and enhances the class): for field in fields: if descriptor := getattr(field, 'descriptor'): setattr

[issue39247] dataclass defaults and property don't work together

Thomas added the comment: > An example of multiple descriptors would be to have: > @cached_property > @property > def expensive_calc(self): > #Do something expensive That's decorator chaining. The example you gave is not working code (try to return something from expensive

[issue34451] docs: tutorial/introduction doesn't mention toggle of prompts

Thomas added the comment: I added a pull request to attempt to fix this issue. It received a label but no review and has gone stale, so I am sending out a ping. -- ___ Python tracker <https://bugs.python.org/issue34

[issue42369] Reading ZipFile not thread-safe

Thomas added the comment: @khaledk I finally got some time off, so here you go https://github.com/1/ParallelZipFile I can not offer any support for a more correct implementation of the zip specification due to time constraints, but maybe the code is useful for you anyway

[issue1039] Asssertion in Windows debug build

New submission from Thomas Heller: In a windows debug build, an assertion is triggered when os.execvpe is called with an empty argument list: self.assertRaises(OSError, os.execvpe, 'no such app-', [], None) The same problem is present in the trunk version. Attached is a patch that fixes

[issue1043] test_builtin failure on Windows

New submission from Thomas Heller: test test_builtin failed -- Traceback (most recent call last): File c:\svn\py3k\lib\test\test_builtin.py, line 1473, in test_round self.assertEqual(round(1e20), 1e20) AssertionError: 0 != 1e+020 -- components: Windows messages: 55355 nosy

[issue1042] test_glob fails with UnicodeDecodeError

New submission from Thomas Heller: Unicode errors in various tests - not only in test_glob: test_glob test test_glob failed -- Traceback (most recent call last): File c:\svn\py3k\lib\test\test_glob.py, line 87, in test_glob_directory_names eq(self.glob('*', '*a'), []) File c

[issue1040] Unicode problem with TZ

Thomas Heller added the comment: BTW, setting the environment variable TZ to, say, 'GMT' makes the problem go away. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1040

[issue1040] Unicode problem with TZ

New submission from Thomas Heller: In my german version of winXP SP2, python3 cannot import the time module: c:\svn\py3k\PCbuildpython_d Python 3.0x (py3k:57600M, Aug 28 2007, 07:58:23) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import

[issue1041] io.py problems on Windows

New submission from Thomas Heller: Running the PCBuild\rt.bat script fails when it compares the expected output with the actual output. Some inspection shows that the comparison fails because there are '\n' linefeeds in the expected and '\n\r' linefeeds in the actual output: c:\svn\py3k

[issue1617699] slice-object support for ctypes Pointer/Array

Thomas Wouters added the comment: I'd like to check this into the trunk, without the non-step-1 support for now, so that we can remove simple slicing from the py3k branch. We can always add non-step-1 support later (all the sooner if someone who isn't me volunteers to do the painful bits

[issue1617687] specialcase simple sliceobj in list (and bugfixes)

Thomas Wouters added the comment: I prefer the current method, as it's more obviously walking in two strides across the same array. I also dislike hiding the final memmove() of the tail bit inside the loop. As for which is more obvious, I would submit neither is obvious, as it took me quite

[issue1617702] extended slicing for buffer objects

Thomas Wouters added the comment: Committed revision 57619. -- assignee: - twouters resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617702

[issue1617701] extended slicing for structseq

Thomas Wouters added the comment: Committed revision 57619. -- assignee: - twouters resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617701

[issue1617698] Extended slicing for array objects

Thomas Wouters added the comment: Committed revision 57619. -- assignee: - twouters resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617698

[issue1617682] specialcase simple sliceobj in tuple/str/unicode

Thomas Wouters added the comment: Committed revision 57619. -- assignee: - twouters resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617682

[issue1617691] Extended slicing for UserString

Thomas Wouters added the comment: Committed revision 57619. -- assignee: - twouters resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617691

[issue1617700] slice-object support for mmap

Thomas Wouters added the comment: Committed revision 57619. -- assignee: - twouters resolution: - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617700

[issue1056] test_cmd_line starts python without -E

New submission from Thomas Wouters: test_cmd_line tests various things by spawning sys.executable. Unfortunately it does so without passing the -E argument (which 'make test' does do) so environment variables like PYTHONHOME and PYTHONPATH can cause the test to fail. -- assignee

[issue1617699] slice-object support for ctypes Pointer/Array

Thomas Wouters added the comment: Added tests (by duplicating any slicing operations in the test suite with extended slice syntax, to force the use of slice-objects ;) _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617699

[issue1617699] slice-object support for ctypes Pointer/Array

Changes by Thomas Wouters: _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617699 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman

[issue1040] Unicode problem with TZ

Thomas Heller added the comment: IMO the very best would be to avoid as many conversions as possible by using the wide apis on Windows. Not for _tzname maybe, but for env vars, sys.argv, sys.path, and so on. Not that I would have time to work

[issue1617699] slice-object support for ctypes Pointer/Array

Changes by Thomas Wouters: _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617699 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman

[issue1039] Asssertion in Windows debug build

Thomas Heller added the comment: Applied in rev. 57731. -- resolution: accepted - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1039

[issue1617699] slice-object support for ctypes Pointer/Array

Thomas Heller added the comment: Set to accepted. As pointed out in private email, please apply it to the trunk. Your thoughts about the 'length' of pointers make sense, and are very similar to what I had in mind when I implemented pointer indexing. For indexing pointers, negative indices

[issue1617699] slice-object support for ctypes Pointer/Array

Changes by Thomas Heller: -- assignee: theller - twouters _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617699 _ ___ Python-bugs-list mailing list Unsubscribe

[issue1617699] slice-object support for ctypes Pointer/Array

Thomas Wouters added the comment: Well, that's not quite how I implemented the slicing, and it's also not how the existing simple-slicing was implemented: A negative start index is taken to mean 0, and a stop index below the start index is taken to mean 'the start index' (leading to an empty

[issue1617699] slice-object support for ctypes Pointer/Array

Thomas Heller added the comment: Yes. But looking at your examples I think it would be better to forbid missing indices completely instead of allowing them only where they clearly mean 0. Writing (and reading!) a 0 is faster than thinking about if a missing index is allowed or what it means

[issue1617699] slice-object support for ctypes Pointer/Array

Thomas Wouters added the comment: Hmmm Well, that's fine by me, but it changes current behaviour, and in a way that ctypes own testsuite was testing, even ;) (it does, e.g., 'p[:4]' in a couple of places.) Requiring the start always would possibly break a lot of code. We could make only

[issue1617699] slice-object support for ctypes Pointer/Array

Thomas Wouters added the comment: Checked in a slightly newer version. -- resolution: accepted - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1617699

[issue1067] test_smtplib failures (caused by asyncore)

New submission from Thomas Wouters: test_smtplib fails because asyncore uses bytes(data) where data may be bytes or str or some undefined type. The attached patch fixes it to the extend that test_smtplib works again (plus a small fix in test_smtplib itself.) I'm not sure if this is the right

[issue1067] test_smtplib failures (caused by asyncore)

Thomas Wouters added the comment: Checked in. -- resolution: accepted - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1067 __ ___ Python

[issue1067] test_smtplib failures (caused by asyncore)

Thomas Wouters added the comment: I agree, but the change wasn't actually mine. I merely adjusted the already-implemented strategy to the fact that bytes(str) no longer works. I think the original change was Jeremy H's. __ Tracker [EMAIL PROTECTED] http

[issue1777530] ctypes on Solaris

Thomas Heller added the comment: This is an experimental patch (solaris.patch). Can you please proofread it and try it out on the solaris machine? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1777530 _Index

[issue1777530] ctypes on Solaris

Thomas Heller added the comment: Martin, here is a patch (solaris-2.patch), hopefully according to your comments. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1777530 _Index: util.py

[issue1686386] Python SEGFAULT on invalid superclass access

Thomas Herve added the comment: object.c is already inconsistent about tabs and space :). It may be better to fix it in the commit, not to clutter the patch. But I can provide a new patch if necessary. _ Tracker [EMAIL PROTECTED] http://bugs.python.org

[issue1145] Allow str.join to join non-string types (as per PEP 3100)

New submission from Thomas Lee: The current implementation of str.join requires that the parameters passed to it be string/unicode values. A suggestion to allow it to accept parameters of any type came up in PEP 3100. Implemented for Unicode using the attached patch. It would be trivial to add

[issue1145] Allow str.join to join non-string types (as per PEP 3100)

Thomas Lee added the comment: Oh and an example of usage: # before the patch ', '.join([str(x) for x in [1, 2, 3]]) # after the patch ', '.join([1, 2, 3]) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1145

[issue1777530] ctypes on Solaris

Thomas Heller added the comment: Can someone please test the patch and report back? -- Thanks _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1777530 _ ___ Python-bugs

[issue1686386] Python SEGFAULT on tuple.__repr__ and str()

Thomas Herve added the comment: I think it could be solved both the same way: if tuple repr is wrong, there are probably some other repr code that is wrong too, so fixing PyObject_Repr is safer. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1686386

[issue1145] Allow str.join to join non-string types (as per PEP 3100)

Thomas Lee added the comment: Sure - I'll get onto that. Should have another patch up later tonight. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1145 __ ___ Python-bugs-list

[issue10590] Parameter type error for xml.sax.parseString(string, ...)

New submission from Thomas Ryan tom.a.r...@gmail.com: In 3.1.3, 3.1.2, maybe earlier... xml.sax.parseString(string, handler, error_handler=handler.ErrorHandler()) Source code requires bytes, not a string as implied by function name and by the documentation. Exception thrown for strings

[issue10047] python-2.6.6 coredump running newspipe

Thomas Klausner t...@giga.or.at added the comment: I've updated the operating system to a 5.99.39, and the problem disappeared. Strange. Thanks for the suggestions. -- status: open - closed ___ Python tracker rep...@bugs.python.org http

Re: [issue10296] ctypes catches BreakPoint error on windows 32

ctypes has _always_ catched exceptions raised in function calls. On Windows ;-). ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue

Thomas Heller added the comment: Would you like to prepare a patch? I have no idea how the return values of gestalt.gestalt(sysv) and platform.release() relate to each other... -- nosy: +theller __ Tracker [EMAIL PROTECTED] http://bugs.python.org

[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue

Thomas Heller added the comment: On the mac where I have access to platform.release() returns the string '8.10.0'. gestalt.gestalt(sysv) returns 0x1049. Your patch does not look correct to me. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1203

[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue

Thomas Heller added the comment: This patch looks better. However, the 'os.uname()' function seems to return the information that we need; so I updated the patch to use this instead. Can you please proofread it (osx.patch) ? __ Tracker [EMAIL PROTECTED] http

[issue1145] Allow str.join to join non-string types (as per PEP 3100)

Thomas Lee added the comment: Is there anything else you need from me for this one Guido? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1145 __ ___ Python-bugs-list mailing

[issue1249] PEP 3137 patch: make PyBytes/PyUnicode ==/!= comparisons return False

New submission from Thomas Lee: Initial patch attached. -- components: Interpreter Core files: bytes-unicode-return-false-r1.patch messages: 56284 nosy: thomas.lee severity: normal status: open title: PEP 3137 patch: make PyBytes/PyUnicode ==/!= comparisons return False type: rfe

[issue1249] PEP 3137 patch: PyBytes/PyUnicode comparisons

Thomas Lee added the comment: Revised patch - originally misinterpreted what was required here. bytes() == str() now returns False, bytes() != str() now returns True. -- title: PEP 3137 patch: make PyBytes/PyUnicode ==/!= comparisons return False - PEP 3137 patch: PyBytes/PyUnicode

[issue1263] PEP 3137 patch - str8/str comparison should return false

New submission from Thomas Lee: The main patch - while exactly what is needed to make str8/str equality checks return False - breaks a bunch of tests due to PyString_* still being used elsewhere when it should be using PyUnicode. The second patch modifies structmember.c to use PyUnicode_* where

[issue1263] PEP 3137 patch - str8/str comparison should return false

Changes by Thomas Lee: __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1263 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs

[issue1263] PEP 3137 patch - str8/str comparison should return false

Thomas Lee added the comment: Oops - use unicode-string-eq-false-r3.patch, not unicode-string-eq-false-r2.patch. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1263 __Index: Objects/unicodeobject.c

[issue1203] ctypes doesn't work on Mac with --disable-toolbox-glue

Thomas Heller added the comment: IMO os.uname() is preferable. Committed as SVN rev 58415 in trunk. Thanks. -- assignee: - theller resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1203

[issue1263] PEP 3137 patch - str8/str comparison should return false

Thomas Lee added the comment: Hack to make Python/codecs.c use Unicode strings internally. I recognize the way I have fixed it here is probably not ideal (basically ripped out PyString_*, replaced with a PyMem_Malloc/PyMem_Free call) but it fixes 10-12 tests that were failing with my earlier

[issue1295] logging records cache the result of formatException()

New submission from Thomas Heller: I needed two logging handlers in my application, one notifiying the user of errors, the other writing errors to a logfile. So I created a custom subclass of logging.Formatter and redefined the formatException() method that returned a summary of the exception

[issue1295] logging records cache the result of formatException()

Thomas Heller added the comment: This is tough. On the one hand you are right that different classes that have different formatException() methods aren't treated correctly; on the other hand I think the caching is important for other cases where there are multiple loggers all using

[issue1295] logging records cache the result of formatException()

Thomas Heller added the comment: I think that a warning or an example in the docs would be nice, but I have no time to make a patch for that. -- resolution: - wont fix status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1295

[issue1319] py3k: fixes for test_ctypes

Thomas Heller added the comment: Guido van Rossum schrieb: Looks good to me. I can check it in if Thomas is okay with that (or if he remains silent long enough :-). Looks good to me too. Please check it in if you have time ;-) __ Tracker [EMAIL PROTECTED

[issue1319] py3k: fixes for test_ctypes

Thomas Heller added the comment: Here's the bugfix - is it correct? Added file: http://bugs.python.org/file8603/_ctypes.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1319 __Index: Modules/_ctypes/_ctypes.c

[issue1319] py3k: fixes for test_ctypes

Thomas Heller added the comment: Committed as rev 58642. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1319 __ ___ Python-bugs-list mailing list Unsubscribe: http

[issue1324] r58034 breaks building _ctypes with the upstream libffi.

Thomas Heller added the comment: Maybe I should give up the idea to define the ffi_type_... types myself. Committed as rev 58655. Thanks. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1324

[issue1292] libffi needs an update to support mips64, arm and armeabi on linux

Thomas Heller added the comment: I'm unsure how to proceed with this. Replacing the copy of libffi in the ctypes sources - I'm very afraid to do that. It has it's own configure system, written by someone else. Then it has several changes from various people for Python, which would

[issue1292] libffi needs an update to support mips64, arm and armeabi on linux

Thomas Heller added the comment: In the branches_ctypes-branch I hacked setup.py to always use an installed libffi if one is found. Then I triggered the trunk buildbots which failed or crashed before in some c_longdouble tests; the tests worked ok on them (ppc Debian unstable, and S-390 Debian

[issue1292] libffi needs an update to support mips64, arm and armeabi on linux

Thomas Heller added the comment: I meant branches/ctypes_branch, of course. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1292 __ ___ Python-bugs-list mailing list Unsubscribe

[issue1292] libffi needs an update to support mips64, arm and armeabi on linux

Thomas Heller added the comment: I have now made --with-system-ffi default to yes for Linux/alpha*, Linux/arm*, Linux/ppc*, and Linux/s390* machines. If you think it is needed for mips machines also please add this - there's no buildbot where I can check the result

[issue1390] toxml generates output that is not well formed

Changes by Thomas Conway: -- components: Library (Lib) nosy: drtomc severity: normal status: open title: toxml generates output that is not well formed type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1390

  1   2   3   4   5   6   7   8   9   10   >