On Jan 6, 2016, at 15:35, Oliver Palmer <oliverpalmer@opalmer.com> wrote:

So expanding on the "Should the CFFI wrapper and functions for win32 be a separate project" thread from six months ago I think I'd like some feedback. The pywincffi project, which I'm planning to use to start replacing pywin32 in Twisted, is getting close to its first release. At this point there's enough code in place that it could probably be used to replace pywin32 in twisted.python.lockfile and other parts of pywin32 in Twisted. Before proposing any patches however, I'd like to take this opportunity to welcome feedback from people on this list. Although pywincffi will not be a 'Twisted project' Twisted will be the primary consumer of pywincffi so I'd like to make sure developers here are happy with the direction that has been taken.

For some background, the core objectives and intended design features are below (nothing all that special mostly):

* It should be easy to build and retrieve the binary files (wheels for now, easy to add more later).
* Python 2.6, 2.7 and 3.x are supported from a single code base.
* Type conversion, error checking and other 'C like' code should be the responsibility of the library where possible.
* APIs provided by pywincffi should mirror their Windows counterparts as closely as possible so the MSDN documentation can be more easily used as reference.
* For contributors, it should be possible to work on any platform. It should also be possible to contribute without having to manually build a VM.
* For consumers, documentation and error messages should be descriptive, consistent, complete and accessible. Examples should be provided for more complex use cases.

From a functionality and design standpoint, I think the above are more or less achieved and can be maintained going forward. With that in mind, I'd like to know if anyone here has other ideas that they believe should be incorporated. Of course if anyone happens to look at the code and find functional issues with it now would be a good time to address those issues too.

Thanks in advance for the help!

Something else that would be nice to keep in mind - I would really like to eliminate our Pyrex support files for IOCP as well; if you could make sure those APIs are wrapped by pywincffi (I think they might be missing from pywin32, or at least, I believe they were at one point, which is why Pavel wrote his own thing), and perhaps even contribute patches to eliminate that old and crufty code, that would be fantastic :).