Document limitation regarding .py file patching and Python versions

README.md

@@ -76,3 +76,4 @@ The path separator to use in the following options is `';'` on Windows and `':'`
 - Any DLL containing an Authenticode signature will have its signature cleared if its dependencies are name-mangled.
 - `delvewheel` cannot repair a wheel that contains extension modules targeting more than one CPU architecture (e.g. both `win32` and `win_amd64`). You should create a separate wheel for each CPU architecture and repair each individually.
 - If your project has a [delay-load DLL dependency](https://learn.microsoft.com/en-us/cpp/build/reference/linker-support-for-delay-loaded-dlls), you must use a custom delay-load import hook when building the DLL that has the delay-load dependency. This ensures that the directory containing the vendored DLLs is included in the DLL search path when delay-loading. For convenience, we provide a suitable hook for Microsoft Visual C/C++ at [delayload/delayhook.c](delayload/delayhook.c). Add the file to your C/C++ project when building your DLL.
+- An `__init__.py` file in a top-level package or a `.py` file at the root of a namespace package must be parsable by the version of Python that runs `delvewheel`. For instance, you cannot run `delvewheel` using Python 3.9 to repair a wheel containing a top-level package with an `__init__.py` file that uses syntax features introduced in Python 3.10. Aside from this rule, there are no other requirements regarding the relationship between the version of Python that runs `delvewheel` and the version(s) of Python that the wheel supports.