[issue11750] Mutualize win32 functions

Antoine Pitrou added the comment: Thanks a lot for doing this! Patch now committed to 3.3 (after testing under Windows 7 64 bits). -- assignee: brian.curtin -> components: -Windows resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___

[issue11750] Mutualize win32 functions

Roundup Robot added the comment: New changeset f3a27d11101a by Antoine Pitrou in branch 'default': Issue #11750: The Windows API functions scattered in the _subprocess and http://hg.python.org/cpython/rev/f3a27d11101a -- nosy: +python-dev ___ Python

[issue11750] Mutualize win32 functions

Changes by Antoine Pitrou : -- components: +Windows ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue11750] Mutualize win32 functions

sbt added the comment: > Overlapped's naming is still lagging behind :-) Argh. And a string in winapi_module too. Yet another patch. -- Added file: http://bugs.python.org/file25252/winapi_module.patch ___ Python tracker

[issue11750] Mutualize win32 functions

Antoine Pitrou added the comment: > sbt added the comment: > > s/_win32/_winapi/g Overlapped's naming is still lagging behind :-) Other than that, a comment: +def Close(self): +if not self.closed: +self.closed = True +_winapi.CloseHandle(s

[issue11750] Mutualize win32 functions

sbt added the comment: s/_win32/_winapi/g -- Added file: http://bugs.python.org/file25241/winapi_module.patch ___ Python tracker ___

[issue11750] Mutualize win32 functions

Antoine Pitrou added the comment: > > How about _windowsapi or _winapi then, to ensure there are no clashes? > > I don't have any strong feelings, but I would prefer _winapi. Ditto here. -- ___ Python tracker __

[issue11750] Mutualize win32 functions

sbt added the comment: > How about _windowsapi or _winapi then, to ensure there are no clashes? I don't have any strong feelings, but I would prefer _winapi. -- ___ Python tracker

[issue11750] Mutualize win32 functions

Kristján Valur Jónsson added the comment: >at some point it became the Windows API. You are right: http://en.wikipedia.org/wiki/Windows_API How about _windowsapi or _winapi then, to ensure there are no clashes? -- ___ Python tracker

[issue11750] Mutualize win32 functions

Brian Curtin added the comment: pythoncore.vcproj) > > * no changes to pcbuild.sln needed > > * removed reference to 'win32_functions.c' in setup.py > > I think the module would be better named _win32, since that's the name > of the API (like POSIX under Unix). While there are many references t

[issue11750] Mutualize win32 functions

sbt added the comment: > I think the module would be better named _win32, since that's the name > of the API (like POSIX under Unix). Changed in new patch. > Also, it seems there are a couple of naming inconsistencies renaming > (e.g. the overlapped wrapper is named "_multiprocessing.win32.Ove

[issue11750] Mutualize win32 functions

Antoine Pitrou added the comment: > New patch. Compared to the previous one: > > * socket functions have been moved from _windows to _multiprocessing > * _windows.vcpoj has been removed (so _windows is part of pythoncore.vcproj) > * no changes to pcbuild.sln needed > * removed reference to 'wi

[issue11750] Mutualize win32 functions

sbt added the comment: New patch. Compared to the previous one: * socket functions have been moved from _windows to _multiprocessing * _windows.vcpoj has been removed (so _windows is part of pythoncore.vcproj) * no changes to pcbuild.sln needed * removed reference to 'win32_functions.c' in set

[issue11750] Mutualize win32 functions

Kristján Valur Jónsson added the comment: (fixed wsock32.lib in revision ab0aff639cfb) -- ___ Python tracker ___ ___ Python-bugs-list

[issue11750] Mutualize win32 functions

Kristján Valur Jónsson added the comment: It shouldn't. I noticed this and fixed this at CCP a while back but I wasn't in Python Committer mode at the time. _select needs fixing. -- ___ Python tracker ___

[issue11750] Mutualize win32 functions

sbt added the comment: > I don't think we need the vcproj file, unless I missed something. _multiprocessing.win32 currently wraps closesocket(), send() and recv() so it needs to link against ws2_32.lib. I don't know how to make _windows link against ws2_32.lib without adding a vcproj file fo

[issue11750] Mutualize win32 functions

Brian Curtin added the comment: I don't think we need the vcproj file, unless I missed something. -- ___ Python tracker ___ ___ Pytho

[issue11750] Mutualize win32 functions

sbt added the comment: Attached is an up to date patch. * code has been moved to Modules/_windows.c * DWORD is uniformly treated as unsigned * _subprocess's handle wrapper type has been removed (although subprocess.py still uses a Python implemented handle wrapper type) I'm not familiar wit

[issue11750] Mutualize win32 functions

Changes by Kristján Valur Jónsson : -- nosy: +kristjan.jonsson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11750] Mutualize win32 functions

sbt added the comment: I think there are some issues with the treatment of the DWORD type. (DWORD is a typedef for unsigned long.) _subprocess always treats them as signed, whereas _multiprocessing treats them (correctly) as unsigned. _windows does a mixture: functions from _subprocess par

[issue11750] Mutualize win32 functions

Changes by Antoine Pitrou : -- nosy: +sbt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue11750] Mutualize win32 functions

Antoine Pitrou added the comment: PS: I don't think there's a problem with the "_windows" name, as long as wxPython doesn't depend on a *toplevel* module named "_windows". -- ___ Python tracker __

[issue11750] Mutualize win32 functions

Antoine Pitrou added the comment: I agree with Amaury that it would be better in Modules. In my experience, code that is in PC/ is a pain to discover. A couple of nits about the patch: - the functions in the PyMethodDef array could be sorted alphabetically - the defint() macro isn't necessary,

[issue11750] Mutualize win32 functions

Brian Curtin added the comment: For the first point, I just put it there since other Windows-only modules already exist there. _subprocess did, msvcrt and winreg currently do, and there's a few other Windows-only things in there. It's not a big deal, so I can move it into Modules if we want -

[issue11750] Mutualize win32 functions

Amaury Forgeot d'Arc added the comment: Two high-level remarks about the patch: - IMO there is no reason to put _windows.c in the PC directory. After all, there is no such distinction for posix-specific modules. - wxPython already has a submodule named _windows.py. I wonder if this will caus

[issue11750] Mutualize win32 functions

Changes by Santoso Wijaya : -- nosy: +santa4nt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue11750] Mutualize win32 functions

Changes by Brian Curtin : -- keywords: +needs review stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue11750] Mutualize win32 functions

Brian Curtin added the comment: Here's a patch replacing Modules/_multiprocessing/win32_functions.c and PC/_subprocess.c with a common PC/_windows.c. There's not much to the patch despite its size -- it just shuffles around the C code and does a few renames in the appropriate Python modules.

[issue11750] Mutualize win32 functions

Brian Curtin added the comment: Big +1. I'll work up a patch. -- assignee: -> brian.curtin ___ Python tracker ___ ___ Python-bugs-li

[issue11750] Mutualize win32 functions

Jesse Noller added the comment: Agreed; I'm not personally the windows expert that should handle that consolidation though. -- ___ Python tracker ___ __

[issue11750] Mutualize win32 functions

Tim Golden added the comment: +1 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mai

[issue11750] Mutualize win32 functions

New submission from Antoine Pitrou : subprocess and multiprocessing both have their own private modules for wrappers of win32 functions: Modules/_multiprocessing/win32_functions.c and PC/_subprocess.c. It would be nice to group them in a common module (_win32?) that could be used throughout t