[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

Change by Ivan Pozdeev : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker ___

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

Change by Ivan Pozdeev : -- type: crash -> behavior ___ Python tracker ___ ___

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

Ivan Pozdeev added the comment: Here's the warnings patch. No sure if the `copy.copy' recipe is officially supported. -- nosy: +native_api Added file: http://bugs.python.org/file37000/add-warnings.diff ___ Python tracker rep...@bugs.python.org

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

Changes by Ned Deily n...@acm.org: -- nosy: +amaury.forgeotdarc, belopolsky, meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22552 ___

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

R. David Murray added the comment: How does this relate to issue 14201? That is, is the answer just use getitem if you don't want caching? (And apply the doc patch from that issue :) -- nosy: +r.david.murray ___ Python tracker

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

Ivan Pozdeev added the comment: @R. David Murray: haha, the reverse change that introduced this problem in the first place! issue 14201's problem is exactly why I was going to suggest to also make _FuncPtr's compare equal if they point to the same function. @eryksun: Packages do this because

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

eryksun added the comment: How does this relate to issue 14201? That is, is the answer just use getitem if you don't want caching? Unlike CDLL.__getitem__, LibraryLoader.__getitem__ does use the attribute cache. Why use a LibraryLoader if you don't want the cached libs and access to

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

eryksun added the comment: Packages do this because it's the natural thing to do I guess the tutorial is channeling projects toward using the cdll/windll LibraryLoader instances on Windows. It even shows using cdll.LoadLibrary('libc.so.6') on Linux. That's equivalent to CDLL('libc.so.6'); I

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

Ivan Pozdeev added the comment: If you want cached libs without polluting ctypes.cdll or ctypes.windll, just create your own instance such as windll = ctypes.LibraryLoader(ctypes.WinDLL). This one looks like the next best thing to the current state of affairs, requiring minimal change to

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

Changes by Ivan Pozdeev ivan_pozd...@mail.ru: -- title: ctypes.LibraryLoader returns singleton objects, resulting in usage conflicts - ctypes.CDLL returns singleton objects, resulting in usage conflicts ___ Python tracker rep...@bugs.python.org

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

Ivan Pozdeev added the comment: Another possible solution is to prohibit settings attributes of vanilla _FuncPtr objects, requiring a library to make a private copy to be able to do that. -- ___ Python tracker rep...@bugs.python.org

[issue22552] ctypes.CDLL returns singleton objects, resulting in usage conflicts

eryksun added the comment: The ctypes global LibraryLoader instances are convenient for Windows scripts and applications. Actually what they cache is the library (a CDLL instance), which in turn caches function pointers. Python packages, on the other hand, shouldn't use these particular