On 16 April 2015 at 11:11, Tim Golden <m...@timgolden.me.uk> wrote: > Really, pywin32 is several things: a set of libraries (win32api, > win32file, etc.); some system-level support for various things (COM > registration, Service support etc.); and a development/editing > environment (pythonwin).
That sounds about right. > I see this ending up as (respectively): as venv-friendly wheel; a py -m > script of the kind Paul suggests; and an installable app with the usual > start menu icons etc. Again, yes, that seems reasonable. Personally, for the uses I see of pywin32, it would make sense to split it into a number of separate wheels (win32api, win32file, ...) to reduce the dependency footprint for projects that only use one or two functions out of the whole thing, but honestly ctypes is probably still a better approach for that scenario, so the benefit of such a split is likely minimal. > In my copious spare time I'll at least try to visit the pywin32 codebase > to see how viable all this is. Feel free to challenge my thoughts on the > matter. I think you're going in the right direction. The hardest parts are likely to be where the Windows architecture interferes (COM registration and services). Paul. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
