When building a c extension on windows the linker fails like this:

link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:../../../libs/plop/Release_MD_PLOPDS_VS6 /LIBPATH:C:\Programme\python32\libs /LIBPATH:C:\Programme\python32\PCbuild kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib libplop.lib /EXPORT:PyInit_plop_py build\temp.win32-3.2\Release\plop_py.obj /OUT:build\lib.win32-3.2\plop_py.pyd /IMPLIB:build\temp.win32-3.2\Release\plop_py.lib /MANIFESTFILE:build\temp.win32-3.2\Release\plop_py.pyd.manifest
   Creating library build\temp.win32-3.2\Release\plop_py.lib and object build\temp.win32-3.2\Release\plop_py.exp

plop_py.obj : error LNK2019: unresolved external symbol __imp___PyArg_ParseTuple_SizeT referenced in function __wrap_PLOP_new

build\lib.win32-3.2\plop_py.pyd : fatal error LNK1120: 1 unresolved externals


I use distutils to build the extension. The same code works fine on Linux/Unix/MacOSX. When I unset the Py_LIMITED_API it works fine on Windows too.

It seems this function was forgotten. I'd add this for 3.2.1, which of course means that your extension wouldn't run on a 3.2.0 installation. Would you consider this acceptable?

Would you prefer to see a compiler error indicating that you are using a function not available in 3.2.0 (with an option of opting into 3.2.1+)?

fixing this for the next version of course would be acceptable. 

As I can use the extension (not setting Py_LIMITED_API) even with 3.2.0 it is not a big problem. I only loose the benefit of Py_LIMITED_API and will have to release another version of the binding later on.

> Would you prefer to see a compiler error indicating that you are using
> a function not available in 3.2.0 (with an option of opting into 
> 3.2.1+)?

I fear I don't understand exactly what is meant here. For me it was enough to get the linker error telling me it is not working.

> I fear I don't understand exactly what is meant here. For me it was enough to get the linker error telling me it is not working.

Suppose 3.2.1 adds this function, which then means that your extension
builds fine. However, it won't run on 3.2.0, so you might complain that
the ABI isn't really "stable". Therefore, I wonder whether you would
have liked to continue receiving compile-time indications that you are
using parts of the ABI which had not been around in 3.2.0.

Now that you know, you *personally* probably don't need this
notification anymore. I just wonder about people in similar situations.

OK now I got it. 

Yes for others this would be "very" helpful. Specially as the Py_LIMITED_API promises to solve the changing API issue on windows and Parse_Tuple is one of the main API's used in extensions this would be helpful I guess.

I personally decided to build without Py_LIMITED_API for Python 3.2.*, I will use the new feature with Python 3.3.*. This is more clear for our customers. Till now we only had new extensions with new x.y versions of Python, nether with x.y.z versions.

New changeset 3f14119e4af7 by Martin v. Löwis in branch 'default':
Issue #11626: Add _SizeT functions to stable ABI.
http://hg.python.org/cpython/rev/3f14119e4af7

As some time has passed (unfortunately), I now decided to add these functions only to the stable ABI of 3.3+. I'd appreciate if you could review the beta releases and comment whether they fix the issue. Notice that you will have to set Py_LIMITED_API to 0x03030000 (or higher) to access them.

Thanks,

I tested it with 3.3beta1 and it works fine now.