GitLocker: The Coding Marketplace

Description:

pywincffi 0.5.0

Python Windows Wrapper Using CFFI

pywincffi is a wrapper around some Windows API functions using Python
and the cffi library. This project was
originally created to assist the Twisted project in moving away from its
dependency on pywin32. Contributions to expand on the APIs which pywincffi
offers are always welcome however.
The core objectives and design principles behind this project are:

It should be easier to to use Windows API functions both in terms of
implementation and distribution.
Python 2.7 and 3.x should be supported from a single code base and
not require a consumer of pywincffi to worry about how they use the
library.
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.
Documentation and error messages should be descriptive, consistent,
complete and accessible. Examples should be provided for more complex
use cases.
For contributors, it should be possible to develop and test regardless
of what platform the contributor is coming from.

Development
This section gives a basic overview of the development process including
the major goals. This is not comprehensive but should be a good
introduction before submitting a pull request.

Support and Documentation
Besides this readme there are two other locations you can go to receive some
help:

https://pywincffi.readthedocs.org/en/latest/dev/ - Goes beyond
what’s in this readme.
https://groups.google.com/forum/#!forum/pywincffi - Google group for
discussions, questions, etc.

Python Version Support
This project supports Python 2.7 and up including Python 3.x. PRs, patches,
tests etc that don’t include support for both 2.x and 3.x will not be
merged. The aim is also the support both major versions of Python within
the same code base rather than rely on tools such as 2to3, six or other
libraries for the most part.

Documentation
The documentation for this this library is hosted on
Read The Docs.
It’s generated directly from this library using sphinx:
virtualenv env
env/bin/activate
pip install -r dev_requirements.txt
pip install -e .
cd docs
make html
The build process also builds the documentation to ensure there are not
any obvious problems (including broken links).

Function Documentation
Windows API Functions are typically documented in the following format:
def DuplicateHandle(arg1, kwarg1=None):
"""
A brief message about this function.

.. seealso::

<url to the MSDN API documentation for this function>

:param type arg1:
Brief information about this argument

:keyword type kwarg1:
Brief information about this keyword include it's default
and how it's handled within the function.

:raises SomeException:
Some information on when this exception will be raised

:rtype: type
:return:
Information about the data that's returned
"""
It’s important to note that the docs contain a seealso stanza. This is
typically used to reference the MSDN documentation but may also be used to
reference examples, white papers or other reference which may be useful in
describing the function.
Adding new functions is covered in greater detail
here

Testing

Continuous Integration
To consistently ensure the highest quality code, the following services are
utilized to test or analyze every commit and pull request:

AppVeyor - Runs
the unittests, builds wheel files, MSIs and other output artifacts
which can be published in a release.
Travis - Runs the pep8
and pylint command line tools on the code base and tests. This also
builds the docs so documentation problems are easily spotted.
Codecov - Analyses and
displays code coverage results after tests have run on AppVeyor. Results
are posted back to pull requests.
ReadTheDocs. -
The official location where documentation is built and posted. This is
generally for merges into the master branch however.

Additional Testing
As seen above, there are numerous tests besides the unittests. To run all
the tests on Windows, much like the continuous integration systems do, you can
run test.bat:
> check.bat
This will:

Check code style for both the library and tests.
Run all unittests.
Build the wheel file.
Build the documentation and treat warnings as errors.

Keep in mind that this will not setup the virtualenv or build environment for
you. So if you can’t build the library or are missing a dependency then
the above may fail.

Vagrant
The continuous integration services above negate most of the need to setup
your local workstation to handle development for pywincffi, even if you’re not
running Windows. In some cases however it can be faster or easiear to work
on your local machine.
If you’re not running Windows or you don’t have the tools necessary to
develop pywincffi on your machine you can use
Vagrant to build a Windows machine and start
developing. There’s a more in depth explanation of this process located
here:

https://pywincffi.readthedocs.org/en/latest/dev/vagrant.html