>>>> The structure of type objects is not available to applications; >>>> declaration of "static" type objects is not possible anymore >>>> (for applications using this ABI). >>> Hmm, that's going to create big problems for extensions that >>> want to expose a C-API for their types: Type checks are normally >>> done by pointer comparison using those static type objects. >> They would just have to expose "MyExtensionPrefix_MyType_Check" and >> "MyExtensionPrefix_MyType_CheckExact" functions the same way that types >> in the C API do. > > Hmm, that's a function call per type check and will slow things > down a lot, esp. when working with APIs that deal a lot with > these objects.
See my other response. You can continue to provide _Check macros; knowledge of the structure of types is not necessary to perform such checks. > The typical way to implement these type checks is via a simple > pointer comparison (falling back to a function for sub-types). > That's cheap and fast. And will continue to be available to ABI-compliant extensions. >>> Including Py_INCREF()/Py_DECREF() ? >> I believe so - MvL deliberately left the fields that the ref counting >> relies on as part of the ABI. > > Hmm, another slow-down. ??? Why is "no change" a slow-down? > This is not much of an issue if the C runtime DLL doesn't change > between releases, but it becomes a problem when they do e.g. > due to an upgrade to a new MSVC++ compiler version or in case > the extension was downloaded pre-compiled from pypi or some > other site. What problem specifically may occur? Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
