As far as PyQt is concerned, the answer to whether it has "implemented all of the Qt modules or not" is: yes and no. But mostly no.
PyQt uses the SIP tool to generate its bindings. If you want to understand how this is done, here is how the author of PyQt and SIP explains the process:
For PyQt v4 I use an internal tool (written using PyQt of course)
called metasip. This is sort of an IDE for SIP. It uses GCC-XML to
parse the latest header files and saves the relevant data, as XML, in
a metasip project. metasip then does the equivalent of a diff against
the previous version of the API and flags up any changes that need to
be looked at. Those changes are then made through the GUI and ticked
off the TODO list. Generating the .sip files is just a button click.
In my subversion repository, PyQt v4 is basically just a 20M XML file.
Updating PyQt v4 for a minor release of Qt v4 is about half an hours
work.
In terms of how the generated code works then I don't think it's very
different from how any other bindings generator works. Python has a
very good C API for writing extension modules - it's one of the
reasons why so many 3rd party tools have Python bindings. For every
C++ class, the SIP generated code creates a corresponding Python class
implemented in C.
So PyQt is just a set of fairly thin wrappers around the Qt modules, and generally doesn't implement any functionality itself. However, there are a few exceptions to this.
Firstly, PyQt adds some syntactic sugar in various places to make the Qt APIs a little more palatable for Python coders (for example, the new-style signal and slot support).
Secondly, there are some Qt APIs which it would make no sense for PyQt to provide, due to fundamental language differences between C++ and Python (e.g. there is nothing equivalent to type-casting in Python).
And finally, there is the uic module. Unlike PySide, PyQt doesn't wrap the QtUiTools module at all. Instead, it provides a module written in pure Python that actually does implement the equivalent functionality from the Qt library. But this is the exception, rather than the rule.
In addition to the above, there are undoubtably many other differences and omissions that I haven't covered here (particularly with regard to PyQt5). As with all language bindings, the fundamental aim is to provide a practical means of communication between two languages, rather than a perfect one-to-one mapping.