[Python-Dev] binary incompatibility and tp_flags (was: Linker
problems on Linux)
Mon, 17 Jul 2000 10:26:54 +0200
Greg Stein wrote:
> On Sun, Jul 16, 2000 at 11:25:53PM +0200, Thomas Wouters wrote:
> > On Sun, Jul 16, 2000 at 10:57:47PM +0200, Martin v. Loewis wrote:
> > > For example, if you have a 1.5.2-compiled type in an extension module,
> > > and that type happens to implement PySequenceMethods, then applying 'a
> > > in b' will likely crash: Python 2 will check for the sq_contains
> > > field, but that is past the end of the function table in the old
> > > module.
> > Nope. This is specifically fixed by the new tp_flags structmember (which was
> > 'unused' before, so reading *that* will work ok) and the PyType_HasFeature
> > macro. All code that wants to access one of the really new struct members
> > (currently, bf_getcharbuffer, sq_contains and the cycle-gc stuff. And my
> > augmented assignment patch adds another 13 ;) should check tp_flags first.
> > See the comment in Include/object.h regarding this.
> Actually, those flags should only be used if you are attempting to maintain
> binary compatibility.
> At the point where you say "okay. binary compatibility is hereby broken.",
> then we go and remove the flags for the new structure members.
I can't remember anyone saying something in that direction.
> The last API bump was to 1009 for "Unicode API added". I'm not sure why
> Guido bumped it since the *addition* of an API shouldn't create binary
He bumped it so that extensions can switch on the API number
and then decide whether to use the new API or not... there are
extensions out there which want to be compatible to 1.5.2 *and*
2.0. E.g. my mx stuff has a special portability file (mxpyapi.h)
which is meant to achieve exactly this...
> Regardless, I think we have introduced several semantic incompatibilities or
> even signature changes in the APIs. We should do a bump for safety's sake
> and we should toss the two Py_TPFLAGS_HAVE_* macros (and the corresponding
> tests within the core interpreter).
I can only speak for my mx stuff, but that still works greats
with the 2.0 API -- except for the missing PyObject_Length()
API, but that'll go back in as soon as Thomas has modified
his patch on SF.
Python Pages: http://www.lemburg.com/python/