Introduction

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.

Unicode everywhere

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

isapi

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.

datetime objects

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.

The win32timezone.now and win32timezone.utcnow methods may be useful when working with datetime objects.