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.
There is Mark Hammond's book [1] about python-win32 though I haven't
used it and don't know if it contains anything that would be helpful
to you.
It is rather old now but some claim that is not important. [2]
Personally I consider Python-win32 to be docware -- software that is
sufficiently difficult to use with the included free documentation
that many people will just buy the $$$ documentation. Numpy is
another prominent example of docware. A misappropriation of the good-
will value of legitimate open source software.
[1]http://www.amazon.com/Python-Programming-Win32-Windows-Programmers/
dp/1565926218/ref=sr_1_1?ie=UTF8&s=books&qid=1198165983&sr=1-1
[2]
http://groups.google.com/group/comp.lang.python/browse_thread/thread/e5a1f274ec411cbe/78b1390a6f6d75b2?hl=en&lnk=st&q=com+win32+(doc+OR+documentation)+group%3Acomp.lang.python#78b1390a6f6d75b2
The book of which you speak is still relevant since the Microsoft's
API hasn't changed much. Everything I've tried of their examples has
worked. Unfortunately, it is kind of expensive.
Mike
Unfortunately many of these services and programs that can be accessed
in this way are themselves very poorly documented, or require indeed
expensive books. Blaming Python-Win32 is hitting the wrong group of
people entirely! You cannot expect them to document huge monsters such
as Windows XP or Vista, or the other monsters that can be automated
through COM, such as Powerpoint, Word and Excel.
I am myself automating some trivial MS-office stuff, but I am
flabbergasted by the fragmentary nature of on-line documentation in
MS-office. The real problem is that these kinds of programs are not
described at a reasonable conceptual level, making it difficult to
automate trivial tasks. In your term MS-office is docware, certainly not
Python-Win32. My experiences with Python-Win32 itself are very good.
Gerrit
PyWin32 is free, and writing extensive documentation would be a huge
undertaking. Besides, since it's mostly a one-to-one mapping between
the Win32 API and Python, it would be a bit boring to do.
Besides, few people write GUI apps with Python (there are better
alternatives like Delphi or VB), and those who do usually prefer to
use cross-platform tools like wxWidgets.
Like others have mentionned, apparently the only book available is
this:
> Like others have mentionned, apparently the only book available is
> this:
>
> www.oreilly.com/catalog/pythonwin32/chapter/ch12.html
PyWin32 follows the Windows API quite pedantically, except for GUI
where it wraps MFC. If you can read C and C++, the help file and
Microsoft's documentation is sufficient. I would say that despite of
being C or C++, the most important source for using PyWin32 is MSDN.
If Benoit is having trouble using PyWin32, I think he is having
trouble using the Windows API.
I wouldn't blame him :-) Besides, the point of writing Windows apps
directly in Python, ie. without relying on an extra GUI layer like
wxWidgets, is to be more productive than using C++.