[issue4072] build_py support for lib2to3 is stale

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- nosy: +theller ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4072> ___ ___ Python

[issue4073] distutils build_scripts and install_data commands need 2to3 support

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- nosy: +theller ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4073> ___ ___ Python

[issue4091] python dll not installed in windows system directory

New submission from Thomas Heller <[EMAIL PROTECTED]>: Python 2.6 final and Python 3.0 rc1 do NOT install the python dlls into the windows system directory, even when installing 'for all users' and with admin rights. This causes problems with COM objects implemented in Pyth

[issue4089] linking python2.6.dll crash on windows xp

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs

[issue4075] Use WCHAR variant of OutputDebugString

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- nosy: +theller ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4075> ___ ___ Python

[issue7959] ctypes memory leak

New submission from Thomas Heller : This little script 'ctypes-leak.py' leaks memory: """ import gc from ctypes import * PROTO = WINFUNCTYPE(None) class Test(object): def func(self): pass def __init__(self): self.v = PROTO(self.func) while

[issue7959] ctypes memory leak

Thomas Heller added the comment: CThunkObject is not registered correctly with the cycle GC. The attached patch, against trunk, fixes the issue. -- keywords: +patch Added file: http://bugs.python.org/file16345/issue7957.patch ___ Python tracker

[issue887237] Machine integers

Thomas Heller added the comment: >> Code duplication is unavoidable because the goal is to give access to >> machine arithmetics which means (# types) x (# operations) of very >> similar looking functions. I considered reducing (perceived) code >> duplication through

[issue8142] libffi update to 3.0.9

Thomas Heller added the comment: > the ports which are maintained separately still need an update: > > libffi_msvc > libffi trunk now has a port to x86/msvc. might require some > extra updates from libffi. I'll take care of this one. Would it be a good idea to upgrad

[issue8154] os.execlp('true') crashes the interpreter on 2.x

Thomas Heller added the comment: > Thomas, > > Do you remember why your patch for issue1039 was not backported? Probably an oversight only. -- ___ Python tracker <http://bugs.python.o

[issue8142] libffi update to 3.0.9

Thomas Heller added the comment: > We should revert the following chunk for configure.ac to generate the > Makefile's again, so that we are able to run the testsuite at least with > dejagnu: > > -AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Make

[issue8142] libffi update to 3.0.9

Thomas Heller added the comment: > done, and updated the patch for the merge from the trunk. > > -- > Added file: http://bugs.python.org/file16590/libffi-update3.diff This patch passes the ctypes tests and libffi testsuite on this system: Linux tubu64 2.6.24-27-generi

[issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)

Thomas Heller added the comment: > It appears to me that no-one is maintaining this separate ctypes > code-base anymore so I'll have to ditch dependencies that use it > (Shapely) unfortunately. This is correct, the separate ctypes code base is linked via svn:external into the c

[issue8314] test_ctypes fails in test_ulonglong on sparc buildbots

Thomas Heller added the comment: Martin, you should probably post your patch to upstream libffi. -- ___ Python tracker <http://bugs.python.org/issue8314> ___ ___

[issue4120] Do not embed manifest files in *.pyd when compiling with MSVC

Thomas Heller added the comment: I'm not sure this issue is really done. The current state works fine, but there is one problem remaining: There are Python extensions that seem to need a manifest pointing to the MSVC runtime libs: dlls that start in-process com servers, like pythonco

[issue1557] import distutils.msvccompiler hangs when the environment is too large

New submission from Thomas Heller: 'Python -c "import distutils.msvccompiler"' hangs when the environment is too large. This is because in Lib\distutils\msvc9compiler.py, line 258, popen.wait() does not return because the subprocess does not terminate (probably because the

[issue1597] running test_ctypes 25 times in a row causes it to fail

Thomas Heller added the comment: Guido van Rossum schrieb: > Thanks! (I agree with Eric Smith that this is mysterious for the > innocent bystander.) I have added a comment. > Also, what about the -33/+33 leaks? I suppose these are harmless, but > it would be better if the t

[issue1597] running test_ctypes 25 times in a row causes it to fail

Thomas Heller added the comment: > more reproducible fashion. I've fixed this in ctypes/util.py now: > r59477. Cool! And the 'leak' is gone. __ Tracker <[EMAIL PROTECTED]> <ht

[issue1608] test_str.py crashes

Thomas Heller added the comment: Guido van Rossum schrieb: > (Thomas, could you run it in the 2.5 branch as well? I seem to have > checked in a lot of gratuitous changes by using an older version of > autoconf.) Done, see rev 59494. __ Tracker <[EMA

[issue1642] segfault when deleting value member in ctypes types

Thomas Heller added the comment: Fixed in rev. 59549 (trunk) and rev. 59550 (release25-maint). Thanks. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue1793] ctypes.util.find_msvcrt() function

New submission from Thomas Heller: I'm uploading this patch for discussion, in case someone cares. This code (for Windows) adds a function ctypes.util.find_msvcrt(). This function returns the filename of the MSVC runtime library that the current Python executable uses. If calling func

[issue1797] ctypes NULL function pointers should have a False bool value.

New submission from Thomas Heller: ctypes NULL function pointers should have a False bool value. -- assignee: theller components: Extension Modules files: ctypes-funcptr.patch keywords: patch messages: 59744 nosy: theller severity: normal status: open title: ctypes NULL function

[issue1796] ctypes should allow a tuple when an Array is expected

New submission from Thomas Heller: Another ctypes patch for discussion, if someone cares. This patch allows to pass a tuple of the correct size, a ctypes pointer to the correct itemtype, or None to foreign functions that expect ctypes array instances. 'None' is passed as a NU

[issue1793] ctypes.util.find_msvcrt() function

Thomas Heller added the comment: The cross-platform function is ctypes.util.find_library, which is currently not very useful on Windows. This patch changes it so that, on Windows, find_library("c") or find_library("m") finds the MS C runtime lib which exposes functions the a

[issue1797] ctypes function pointer enhancements

Thomas Heller added the comment: The patch will be extended ASAP so that 'None' is accepted by foreign functions where a function pointer (callback function) is expected. For consistency it should be possible to call the ctypes function prototype with None to create a NULL callbac

[issue1798] Add ctypes calling convention that allows safe access of errno

New submission from Thomas Heller: This patch adds new calling conventions to ctypes foreign functions by passing 'errno=True' or 'GetLastError=True' to the CDLL or WinDLL constructor. If CDLL(..., errno=True) or WinDLL(..., errno=True) is used, the function objects avai

[issue1798] Add ctypes calling convention that allows safe access of errno

Thomas Heller added the comment: > But this thread-local attribute on the function seems bizarre to me. > I would prefer another way to get the errno. I can see two alternatives: > - the function returns a tuple (normalresult, errno) on each call. > - when errno is not zero, Environm

[issue1821] configure.ac change for FreeBSD

Thomas Heller added the comment: Thanks. Committed in trunk as rev. 59952. -- assignee: -> theller nosy: +theller resolution: -> fixed status: open -> closed versions: +Python 2.6 -Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http

[issue1796] ctypes should allow a tuple when an Array is expected

Thomas Heller added the comment: Lenard Lindstrom pointed out in a post to the ctypes-users list that pointer instances must not be accepted. Uploaded new patch ctypes-array-2.patch. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1796] ctypes should allow a tuple when an Array is expected

Changes by Thomas Heller: Added file: http://bugs.python.org/file9162/ctypes-array-2.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1796> __ ___ Pyth

[issue1796] ctypes should allow a tuple when an Array is expected

Changes by Thomas Heller: Removed file: http://bugs.python.org/file9127/ctypes-arrays.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1796> __ ___ Pyth

[issue1796] ctypes should allow a tuple when an Array is expected

Changes by Thomas Heller: Removed file: http://bugs.python.org/file9162/ctypes-array-2.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1796> __ ___ Pyth

[issue1796] ctypes should allow a tuple when an Array is expected

Thomas Heller added the comment: Corrected the patch to NOT accept None. Added file: http://bugs.python.org/file9163/ctypes-array-3.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1831] ctypes.Structure constructor arguments

Thomas Heller added the comment: This would require to build the 'char *format' string at runtime, the 'char *keywords[]' array too, and pass a variable number of arguments into the call. __ Tracker <[EMAIL PROTECTED]> <htt

[issue1831] ctypes.Structure constructor arguments

Thomas Heller added the comment: Do you have any idea how this could be implemented? -- nosy: +theller __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1831] ctypes.Structure constructor arguments

Thomas Heller added the comment: Oops, uploaded the wrong file. Added file: http://bugs.python.org/file9177/ctypes-struct.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1831] ctypes.Structure constructor arguments

Changes by Thomas Heller: Removed file: http://bugs.python.org/file9176/ctypes-struct.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1831> __ ___ Pyth

[issue1831] ctypes.Structure constructor arguments

Thomas Heller added the comment: Yes, I came up with a similar solution in the meantime; see the attached patch. Added file: http://bugs.python.org/file9176/ctypes-struct.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1831] ctypes.Structure constructor arguments

Thomas Heller added the comment: Ok, added the missing Py_DECREF, changed to TypeError, and added a test. Added file: http://bugs.python.org/file9178/ctypes-struct.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/

[issue1831] ctypes.Structure constructor arguments

Changes by Thomas Heller: Removed file: http://bugs.python.org/file9177/ctypes-struct.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1831> __ ___ Pyth

[issue1831] ctypes.Structure constructor arguments

Thomas Heller added the comment: Committed as rev. 60003 in trunk. I'll also change the "too many arguments..." exception to a TypeError. Thanks. -- assignee: -> theller resolution: -> fixed status: open -> closed __ Tracker &

[issue1796] ctypes should allow a tuple when an Array is expected

Thomas Heller added the comment: Lenard Lindstrom convinced me that tuples should not be allowed when an array is expected. -- resolution: -> rejected status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

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

Thomas Heller added the comment: Matthias, can this issue be set to 'fixed' and 'closed' now? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1292> __

[issue1793] ctypes.util.find_msvcrt() function

Thomas Heller added the comment: Amaury Forgeot d'Arc schrieb: > This code works on all pythons I have on my machine: official builds, > custom builds (relase/debug) with several MS compilers... > I did not test it with other compiled vendors (mingw32...). What I do not like abou

[issue1252550] modulefinder misses modules

Changes by Thomas Heller: -- resolution: -> out of date status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1252550> _ __

[issue1872] change the bool struct format code from 't' to '?'

New submission from Thomas Heller: Currently the struct module uses the format code 't' for the bool datatype (this was added in python 2.6, in revision 53508). This conflicts with the specification in PEP 3118, which proposes the '?' format character for the bool type, &#

[issue1872] change the bool struct format code from 't' to '?'

Changes by Thomas Heller: -- components: +Documentation __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1872> __ ___ Python-bugs-list mailing list Unsubs

[issue1919] Backport of io.py

Thomas Heller added the comment: > * backport bytearray and the new buffer interface from 3.0 backport of the new buffer interface is required for PEP 3118 which is marked accepted: " It is intended that this PEP will be back-ported to Python 2.6 by adding the C-API and the two func

[issue1941] 2.6 stdlib using with statement

Thomas Heller added the comment: modulefinder should be kept compatible with Python 2.2, so please do not apply the patch for this module. See also PEP 291. No idea about the other modules. -- nosy: +theller __ Tracker <[EMAIL PROTECTED]>

[issue1971] ctypes exposing the pep 3118 buffer interface

New submission from Thomas Heller: The attached patch against py3k makes ctypes expose the pep 3118 buffer interface. The code is also available in the py3k-ctypes-pep3118 branch. -- components: Extension Modules files: ctypes-pep3118.patch keywords: patch messages: 61844 nosy: theller

[issue1941] 2.6 stdlib using with statement

Thomas Heller added the comment: Lib/platform.py contains this notice at the top: #This module is maintained by Marc-Andre Lemburg <[EMAIL PROTECTED]>. #If you find problems, please submit bug reports/patches via the #Python SourceForge Project Page and assign them to &q

[issue2115] __slots__ make attribute setting 10x slower

Thomas Heller added the comment: I think this is a serious problem (and thanks, amaury, for finding the spot). comtypes, like ctypes, uses quite a bit of isinstance calls. It is the reason that the comtypes unit tests run between 8% and 25% slower with trunk than with python 2.5.1. If I

[issue2115] __slots__ make attribute setting 10x slower

Thomas Heller added the comment: PyObject_IsSubclass() has the same problem. BTW; calling PyObject_GetAttr() with interned strings for "__instancecheck__" and "__subclasscheck__" brings not enough speedup. __ Tracker <[EMAIL PROTECTED]&g

[issue2123] ctypes pointer not always keeping target alive

Thomas Heller added the comment: May I ask: do you have a real use case for this, or is it a carefully constructed example? Of course I take all the blame for not defining/documenting this stuff. My current view is this: Python code C code

[issue2146] ctypes: support double for calling function

Thomas Heller added the comment: I reject this patch. It would be an arbitrary decision whether a Python float should be passed as a C float or as a C double, and the docs explicitely mention which native Python types can be passed to function calls when argtypes is not set; see the bottom of

[issue2145] ctypes.util.find_library(): posix .so without SONAME

Thomas Heller added the comment: Honestly I do not know enough about linux shared libraries to have any opinion about this issue. IIRC, the find_library should behave in a similar way as dynamic linking works on linux. If this libdistorm64.so is not a "real" so library, as you w

[issue2152] make sqlite.Row hashable correctly

New submission from Thomas Heller: The attached patch implements hash and cmp for sqlite3.Row objects. -- files: sqliterow.patch keywords: patch messages: 62615 nosy: theller severity: normal status: open title: make sqlite.Row hashable correctly type: behavior versions: Python 2.6

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

Thomas Heller added the comment: I'm reopening this. libffi 3 has been released; I have created the libffi3-branch for this work in Python svn. -- status: closed -> open __ Tracker <[EMAIL PROTECTED]> <http://bugs.pyt

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

Thomas Heller added the comment: libffi3-branch has been merged to trunk; the Modules/_ctypes/libffi files are from the libffi 3.0.4 release now. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://

[issue1506] func alloca inside ctypes lib needs #include on solaris

Thomas Heller <[EMAIL PROTECTED]> added the comment: I applied the patch to SVN trunk as rev 61520. It would probably be better to have a configure test for alloca.h. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PR

[issue2303] isinstance is 4x as slow as in 2.5 because the common case raises

Thomas Heller <[EMAIL PROTECTED]> added the comment: Would it help to implement a default __instancecheck__ and __subclasscheck__ for object (or for type), that subclasses can override? -- nosy: +theller __ Tracker <[EMAIL PROTECTE

[issue1971] ctypes exposing the pep 3118 buffer interface

Thomas Heller <[EMAIL PROTECTED]> added the comment: Travis, can you please review this / when can you review this issue for compliance with pep 3118? -- nosy: +teoliphant __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2470] Need fixer for dl (removed) -> ctypes module

Thomas Heller <[EMAIL PROTECTED]> added the comment: > In the simplest case, convert > > import dl > libc = dl.open("libc.so.6") > iconv = libc.call("iconv_open", "ISO-8859-1", "ISO-8859-2") > print(iconv) > > to > &g

[issue2470] Need fixer for dl (removed) -> ctypes module

Thomas Heller <[EMAIL PROTECTED]> added the comment: Thomas Heller schrieb: > Thomas Heller <[EMAIL PROTECTED]> added the comment: > >> In the simplest case, convert >> >> import dl >> libc = dl.open("libc.so.6") >> iconv = libc.cal

[issue2152] make sqlite.Row hashable correctly

Thomas Heller <[EMAIL PROTECTED]> added the comment: Here's a patch against trunk that implements tp_richcompare. It does apply to and work also in the py3k branch. I have only implemented the '__eq__' and '__ne__' comparisons. Added file: http://bug

[issue2513] 64bit cross compilation on windows

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- nosy: +theller __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2513> __ ___ Python-bugs

[issue2513] 64bit cross compilation on windows

Thomas Heller <[EMAIL PROTECTED]> added the comment: I had to make additional changes to PCBuild\pcbuild.sln to create a 64-bit wininst-9.0-amd64.exe (but I was not able to try out if it works or not). Added file: http://bugs.python.org/file9914/pcbuil

[issue2303] isinstance is 4x as slow as in 2.5 because the common case raises

Thomas Heller <[EMAIL PROTECTED]> added the comment: Issue #2534 has a patch which speeds up isinstance and issubclass by implementing type.__instancecheck__ and type.__subclasscheck__. __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2534] Speed up isinstance and issubclass

New submission from Thomas Heller <[EMAIL PROTECTED]>: This patch implements type.__instancecheck__ and type.__subclasscheck__, which speeds up isinstance and issubclass calls quite a bit. See also issue #2303. Here are the performance figures for the current trunk version: Current SNV

[issue2534] Speed up isinstance and issubclass

Thomas Heller <[EMAIL PROTECTED]> added the comment: Running Daniels code interactively, with a debug build on Windows, additionally prints 'XXX undetected error' before the Runtime error is raised. I cannot see anything that is wrong with my code. Maybe this, and the test fa

[issue2542] PyErr_ExceptionMatches must not fail

New submission from Thomas Heller <[EMAIL PROTECTED]>: PyErr_ExceptionMatches must not fail, according to the docs. So an error code from PyObject_IsSubclass() cannot be returned. The attached patch calls PyErr_WriteUnraisable in this case, and returns an arbitrary value (0 was chosen

[issue2534] Speed up isinstance and issubclass

Thomas Heller <[EMAIL PROTECTED]> added the comment: Problem found. See issue #2542, which contains a patch that fixes the failure in test_exceptions; this test now additionally prints Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in ign

[issue2543] Make ctypes compatible with Python 2.3, 2.4, and 2.5, as per PEP291

New submission from Thomas Heller <[EMAIL PROTECTED]>: To be committed after the current release is out. -- assignee: theller components: ctypes files: ctypes-compat-py23.diff keywords: patch, patch messages: 64904 nosy: theller severity: normal status: open title: Make

[issue2544] link with "gcc -shared" on HP systems

New submission from Thomas Heller <[EMAIL PROTECTED]>: As discussed in issue #1582742, this patch uses 'gcc -shared' as linker on HP systems when compiling with gcc. It fixes a problem in the ctypes test-suite, that _ctypes_test.so cannot be dynloaded because of missing

[issue1582742] Python is dumping core after the test test_ctypes

Thomas Heller <[EMAIL PROTECTED]> added the comment: See issue #2544, this problem will be solved in Python 2.6. In Python 2.5, ctypes does not work on HPUX. -- assignee: -> theller resolution: -> rejected status: open -> closed _

[issue2548] Undetected error in exception handling

New submission from Thomas Heller <[EMAIL PROTECTED]>: [Found by Daniel Diniz (ajaksu2), see issue #2542] The following code triggers an undetected error with a debug build: """ import sys def g(): try: return g() except: return sys.exc_info() g() print 42

[issue2542] PyErr_ExceptionMatches must not fail

Thomas Heller <[EMAIL PROTECTED]> added the comment: Daniel, IMO you've found a separate bug. I added it as issue #2548. __ Tracker <[EMAIL PROTECTED]> <http://bugs.

[issue2543] Make ctypes compatible with Python 2.3, 2.4, and 2.5, as per PEP291

Thomas Heller <[EMAIL PROTECTED]> added the comment: Committed as rev 62143. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2544] link with "gcc -shared" on HP systems

Thomas Heller <[EMAIL PROTECTED]> added the comment: Committed as rev 62145. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2551] Python 2.6a2 on Solaris 10 built with SUN C

Thomas Heller <[EMAIL PROTECTED]> added the comment: On *nix-like systems, ctypes will most likely only compile with gcc. Since I do not have access to such systems, neither the expertise for them, this will not change unless someone provides patches. -- nosy: +t

[issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C

Thomas Heller <[EMAIL PROTECTED]> added the comment: I'm curious: Why do you insist on using the sun compiler? Are there political or technical reasons? Another thing: in principle it should be possible to build a libffi shared library with gcc, and use it in a sun-c compiled p

[issue2616] ctypes.pointer(), ctypes.POINTER() speedup

New submission from Thomas Heller <[EMAIL PROTECTED]>: This patch implements the POINTER() and the pointer() function in C; giving a speedup of roughly a factor of 2. -- assignee: theller components: ctypes files: ctypes-pointer.diff keywords: patch, patch messages: 65356 nosy: t

[issue2559] atom sorting error when building ctypes

Thomas Heller <[EMAIL PROTECTED]> added the comment: I see this also, on Leopard x86. The linker error is not printed on Tiger PPC. At least, the ctypes test suite does work ok so it may be that it can be ignored. Googling for this error, I find that it may be related to linker change

[issue2559] atom sorting error when building ctypes

Thomas Heller <[EMAIL PROTECTED]> added the comment: So closing this as won't fix. -- resolution: -> wont fix status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http:/

[issue1797] ctypes function pointer enhancements

Changes by Thomas Heller <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9129/ctypes-funcptr.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue1797] ctypes function pointer enhancements

Thomas Heller <[EMAIL PROTECTED]> added the comment: Remove useless file (doesn't contain a patch). __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1797> __

[issue2616] ctypes.pointer(), ctypes.POINTER() speedup

Thomas Heller <[EMAIL PROTECTED]> added the comment: Committed a slightly modified patch as rev 62338; will also be merged into py3k. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2655] Create ctypes instances from buffer interface

New submission from Thomas Heller <[EMAIL PROTECTED]>: This patch implements a .from_buffer(source, offset=0) class method from ctypes types. 'source' must expose a writeable buffer interface; the created ctypes instance will share the internal buffer of the source object;

[issue2655] Create ctypes instances from buffer interface

Changes by Thomas Heller <[EMAIL PROTECTED]>: -- type: -> behavior __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2655> __ ___ Python-b

[issue2680] gotcha: _fields_ is final but accepts lists

Thomas Heller <[EMAIL PROTECTED]> added the comment: > The __slots__ member of a class object has the same behavior. > You may mutate it (even replace it) but this has no effect: only the > value available when the "class" statement was executed is relevant. The rules i

[issue2655] Create ctypes instances from buffer interface

Thomas Heller <[EMAIL PROTECTED]> added the comment: The suggestion by Lenard Lindstrom was an additional method named 'from_buffer_copy'. __ Tracker <[EMAIL PROTECTED]> <http://

[issue2682] cyclic reference in ctypes CFunctionType objects

New submission from Thomas Heller <[EMAIL PROTECTED]>: Zachary Pincus posted a message about this cyclic reference in ctypes CFunctionType objects. The reference has the problem that these objects are cleaned up later than expected. The attached patch fixes this problem by removing the

[issue2680] gotcha: _fields_ is final but accepts lists

Thomas Heller <[EMAIL PROTECTED]> added the comment: Closing as won't fix. -- resolution: -> wont fix status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http:/

[issue2682] cyclic reference in ctypes CFunctionType objects

Thomas Heller <[EMAIL PROTECTED]> added the comment: > Can you please elaborate your (apparent) concerns about this patch? IOW, > why did you not check it in? I have no concerns about the patch, and I am currently committing it. I'm uploading so that I can points others to i

[issue2682] cyclic reference in ctypes CFunctionType objects

Thomas Heller <[EMAIL PROTECTED]> added the comment: Fixed in trunk and py3k, committed as rev 62481 (trunk), rev 62484 (py3k). I'll leave this open until the decision about backporting to release25-maint is made. -- resolution: -> accepted

[issue2682] cyclic reference in ctypes CFunctionType objects

Thomas Heller <[EMAIL PROTECTED]> added the comment: >> Can you please elaborate your (apparent) concerns about this patch? IOW, >> why did you not check it in? > > I have no concerns about the patch, and I am currently committing it. > I'm uploading so tha

[issue2655] Create ctypes instances from buffer interface

Thomas Heller <[EMAIL PROTECTED]> added the comment: Implemented from_buffer() and from_buffer_copy() as rev 62497 to SVN trunk. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2655] Create ctypes instances from buffer interface

Changes by Thomas Heller <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10057/from_buffer.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2692] bytes object wrongly exposes writeable buffer interface

New submission from Thomas Heller <[EMAIL PROTECTED]>: IIUC, the bytes object should be immutable (in contrast to bytearray). But PyObject_FromWriteBuffer() does not fail. It seems that the attached patch fixes it; however there are lots of failures in the testsuite with the patch

[issue2682] cyclic reference in ctypes CFunctionType objects

Thomas Heller <[EMAIL PROTECTED]> added the comment: Also fixed in release25-maint, rev 62504. -- resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

<    1   2   3   4   >