pywin32 now supports Python 3.x. Note that the Python source code is maintained in Python 2.x syntax and automatically converted to Python 3.x syntax using the 2to3 tool. Please don't submit patches etc using Python 3.x syntax.
Important: This py3k support is experimental and things are subject to change. In particular, we may occasionally accept 'insane' args, such as accepting bytes when only a unicode string object makes sense etc. We reserve the right to cleanup any such issues that may arise in a backwards incompatible manner.
In general, pywin32 on Python 2.x will accept both str and unicode objects and convert as appropriate. However, in py3k, bytes objects will generally not be accepted when a 'string' is required - the intent is to restrict usage of bytes objects in py3k to where bytes truly are meant.
Most pywin32 modules for py3k are built with UNICODE defined, and thus will call the Unicode versions of the Windows API.
Specific module notes
The isapi package supports py3k, but note that currently only the
redirector.py sample has been converted to work in
both environments - in particular, subtle urllib changes will
probably require attention - see the redirector sample for details.
Note that ISAPI itself is a narrow-character based API. As a result, functions such as GetServerVariable() etc all return bytes objects - it is up to the application to interpret those bytes. pywin32 detects server variables starting with UNICODE_ and does return unicode objects in that case - see the IIS documentation for more details.
If you pass a unicode object to the ISAPI functions, it will be automatically encoded using the default encoding rather than the 'mbcs' encoding used by the rest of pywin32. In general this should be avoided as IIS doesn't define an encoding.
Python 3.x builds use a subclass of datetime.datetime objects as the "native" datetime object; a subclass is used to provive a backwards compatible PyDateTime.Format method, but otherwise the datetime object is identical to the base class. All time objects returned by pywin32 will have a UTC timezone (via the win32timezone.TimeZoneInfo.utc() method), and times with any timezone will be accepted when passed to pywin32 - but "time zone naive" objects are *not* supported.
Note that it is possible we will support "time zone naive" objects in the future, as supporting such objects in the future will be fully backwards compatible. However, it is not yet clear that supporting such objects is helpful due to the ambiguities that may arise, and attempting to remove such support in the future would cause more problems than enabling it.