Is there *any* real documentation to PyWin32?

[Tim Golden]

Benoit wrote:
> I understand that the Win32 has been said to be itself poorly
> documented, so perhaps that the documentation that comes with the
> modules is of similar quality is no coincidence.  Maybe I'm still too
> young in my programming to grasp the good of that documentation, but
> for myself, it tells me next to nothing.  Could anyone point me to
> anything which may exist that does a better job of explaining the
> extensions' use?  I tried to take a look @ Microsoft's documentation,
> but it was confusing.

I think the thing is that, for most of the modules, they're simply
answering the question "How do I do <x> in Python?" where <x> is the
answer to the question "How do I do <y> in Windows?". For example:
"How do I send something to a printer in Windows?". If you Google
around a bit with that, you'll end up with things like OpenPrinter,
StartDocPrinter and so on. With a Vb/Delphi/C++ example in hand,
the pywin32 extensions usually make it possible to translate pretty
much directly into Python.

Obviously, the modules are more-or-less hand-coded/generated so
only whatever someone's[*] seen fit to include are included (and
development continues so new things do turn up). The more general
solution is ctypes, standard with Py2.5+, available as an extension
before that. That's even lower level, but does mean that if something
isn't exposed via pywin32 then you can do-it-yourself.

All this isn't really answering your question but is at least
explaining a bit why "explaining the extensions' use" is perhaps
a trivial task - they're there to expose the Microsoft API in
a slightly more Pythonic layer.

There are a few web pages around with a few hints and recipes, my
own included:

http://timgolden.me.uk/python/win32_how_do_i.html

Ultimately, though, you're at the mercy of the MS API unless
someone's already done the legwork of providing a more Pythonic
wrapper to something.

TJG

[*] And "someone" here means the selfless small team, mostly consisting
of Mark Hammond and Roger Upole, who've contributed over the years.