Mailman 3 February 2016 - docs

[issue14597] Cannot unload dll in ctypes until script exits
by Mark Mikofski Feb. 16, 2016

Feb. 16, 2016

Mark Mikofski added the comment: Snippets of "proprietary" code `setup.py` ---------- # run clean or build libraries if they don't exist if 'clean' in sys.argv: try: os.remove(os.path.join(LIB_DIR, SOLPOSAM_LIB_FILE)) os.remove(os.path.join(LIB_DIR, SPECTRL2_LIB_FILE)) except OSError as err: sys.stderr.write('%s\n' % err) `core.py` --------- # load the DLL solposAM_dll = ctypes.cdll.LoadLibrary(SOLPOSAMDLL) _solposAM = solposAM_dll.solposAM After deleting files, setup.py tries to build, then runs test_cdlls.py a unittest that contains test_solposAM() that calls solposAM() and imports core.py that contains solposAM. Case 1: ------- I put the load library calls inside the function solposAM(). Function calls works as expected. I am able to delete dlls after interpreter exits and restarts using os.remove() Case 2: ------- I put the load library calls at the module level. Function calls works as expected. If I try to delete dlls after interpreter exits and restarts using os.remove() I get access denied, but I can delete them from windows explorer. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14597> _______________________________________

1 0

[issue14597] Cannot unload dll in ctypes until script exits
by Brian Curtin Feb. 16, 2016

Feb. 16, 2016

Changes by Brian Curtin <brian(a)python.org>: ---------- nosy: -brian.curtin _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14597> _______________________________________

1 0

[issue14597] Cannot unload dll in ctypes until script exits
by Eryk Sun Feb. 16, 2016

Feb. 16, 2016

Eryk Sun added the comment: As to not being able to delete a loaded DLL on Windows, a workaround that may help in some instances is to rename it to a temporary name on the same volume. This is useful for upgrading in place. If you have admin privileges you can even flag the renamed DLL to be deleted when the system reboots: MoveFileExW(renamed_dll_path, NULL, MOVEFILE_DELAY_UNTIL_REBOOT) Renaming a loaded DLL succeeds because the system opens the file with delete sharing, which allows renaming (i.e. relinking) an open file. To verify this, let's check the associated file object that's used by the mapping for python35.dll. We can see this in a local kernel debugging session. The following is in 64-bit Windows 7. Attach to the Python process address space: lkd> .tlist python.exe 0n2296 python.exe lkd> !process 0n2296 0 Searching for Process with Cid == 8f8 Cid handle table at fffff8a003506000 with 951 entries in use PROCESS fffffa800712fb10 SessionId: 0 Cid: 08f8 Peb: 7fffffdf000 ParentCid: 02b8 DirBase: 20780d000 ObjectTable: fffff8a0189fe1a0 HandleCount: 67. Image: python.exe lkd> .process /p /r 0xfffffa800712fb10 Implicit process is now fffffa80`0712fb10 Loading User Symbols ................................... Get the base address for python35.dll. lkd> lm m python35 start end module name 00000000`66fb0000 00000000`67393000 python35 (deferred) Get the associated Virtual Address Descriptor (VAD). lkd> !vad 66fb0000 VAD level start end commit fffffa800855f230 (-1) 66fb0 67392 151 Mapped Exe EXECUTE_WRITECOPY \Program Files\Python35\python35.dll Get the File object reference from the associated control area. lkd> ?? ((nt!_MMVAD *)0xfffffa800855f230)->Subsection->ControlArea->FilePointer struct _EX_FAST_REF +0x000 Object : 0xfffffa80`093f1503 Void +0x000 RefCnt : 0y0011 +0x000 Value : 0xfffffa80`093f1503 The low nibble in the above address is information that needs to be masked out, so the address is actually 0xfffffa80`093f1500. Verify we have the correct file object by checking the filename. lkd> ?? ((nt!_FILE_OBJECT *)0xfffffa80`093f1500)->FileName struct _UNICODE_STRING "\Program Files\Python35\python35.dll" +0x000 Length : 0x48 +0x002 MaximumLength : 0x78 +0x008 Buffer : 0xfffff8a0`04b23690 "\Program Files\Python35\python35.dll" Finally, check the sharing mode. We see below that the file for a DLL mapping is loaded with read and delete sharing, but not write sharing. lkd> ?? ((nt!_FILE_OBJECT *)0xfffffa80`093f1500)->SharedRead unsigned char 0x01 '' lkd> ?? ((nt!_FILE_OBJECT *)0xfffffa80`093f1500)->SharedDelete unsigned char 0x01 '' lkd> ?? ((nt!_FILE_OBJECT *)0xfffffa80`093f1500)->SharedWrite unsigned char 0x00 '' Thus when deleting a DLL fails, it's not due to ERROR_SHARING_VIOLATION (32). The sharing mode would actually permit deleting the file. Instead the error is ERROR_ACCESS_DENIED (5), which results from the system call NtSetInformationFile returning STATUS_CANNOT_DELETE (0xC0000121), because the file currently has a mapped image or data section. But that doesn't stop us from renaming it to get it out of the way of an in-place upgrade. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14597> _______________________________________

1 0

[issue14597] Cannot unload dll in ctypes until script exits
by Eryk Sun Feb. 16, 2016

Feb. 16, 2016

Eryk Sun added the comment: The _ctypes extension module provides dlclose on POSIX and FreeLibrary on Windows. For the reasons already stated in this issue, ctypes should not automatically call these functions, but maybe they should be documented and imported to the ctypes module instead of being buried in the private _ctypes extension module. You could also implement them with ctypes itself, but the existing functions in the _ctypes module already set a proper exception if the call fails and properly use pointers (an HMODULE is a pointer). ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14597> _______________________________________

1 0

[issue22062] Fix pathlib.Path.(r)glob doc glitches.
by Mike Short Feb. 16, 2016

Feb. 16, 2016

Changes by Mike Short <bmshort(a)gmail.com>: Added file: http://bugs.python.org/file41933/pathlib.py.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22062> _______________________________________

1 0

[issue22062] Fix pathlib.Path.(r)glob doc glitches.
by Mike Short Feb. 16, 2016

Feb. 16, 2016

Changes by Mike Short <bmshort(a)gmail.com>: ---------- keywords: +patch Added file: http://bugs.python.org/file41932/pathlib.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22062> _______________________________________

1 0

[issue26368] grammatical error in documentation
by Ryan Stuart Feb. 16, 2016

Feb. 16, 2016

New submission from Ryan Stuart: The note for 18.5.5.1. Stream functions is missing a word. It should read "Note The top-level functions in this module are meant **as** convenience wrappers only; there’s really nothing special there, and if they don’t do exactly what you want, feel free to copy their code." ---------- assignee: docs@python components: Documentation files: asyncio-stream_docs.patch keywords: patch messages: 260339 nosy: Ryan Stuart, docs@python priority: normal severity: normal status: open title: grammatical error in documentation versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41931/asyncio-stream_docs.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26368> _______________________________________

3 2

[issue26363] builtins propagation is misleading described in exec and eval documentation
by Xavier Combelle Feb. 15, 2016

Feb. 15, 2016

Changes by Xavier Combelle <xavier.combelle(a)gmail.com>: ---------- assignee: docs@python components: Documentation nosy: docs@python, xcombelle priority: normal severity: normal status: open title: builtins propagation is misleading described in exec and eval documentation _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26363> _______________________________________

1 0

[issue26334] bytes.translate() doesn't take keyword arguments; docs suggests it does
by Nicholas Chammas Feb. 14, 2016

Feb. 14, 2016

New submission from Nicholas Chammas: The docs for `bytes.translate()` [0] show the following signature: ``` bytes.translate(table[, delete]) ``` However, calling this method with keyword arguments yields: ``` >>> b''.translate(table='la table', delete=b'delete') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: translate() takes no keyword arguments ``` I'm guessing other methods have this same issue. (e.g. `str.translate()`) Do the docs need to be updated, or should these methods be updated to accept keyword arguments, or something else? [0] https://docs.python.org/3/library/stdtypes.html#bytes.translate ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 260034 nosy: Nicholas Chammas, docs@python priority: normal severity: normal status: open title: bytes.translate() doesn't take keyword arguments; docs suggests it does versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26334> _______________________________________

4 5

[issue5824] SocketServer.DatagramRequestHandler Broken under Linux
by Martin Panter Feb. 14, 2016

Feb. 14, 2016

Martin Panter added the comment: Also see the three commented-out tests in test_socketserver. I presume the code needs to ensure the client binds to a name, and then the tests will be able to receive something back from the server. ---------- stage: -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue5824> _______________________________________

1 0