[Python-Dev] binary incompatibility and tp_flags
Mon, 17 Jul 2000 12:04:12 +0200
Greg Stein wrote:
> On Mon, Jul 17, 2000 at 10:26:54AM +0200, M.-A. Lemburg wrote:
> > Greg Stein wrote:
> > > 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.
> Never said anyone did :-) ... just said, "*when* it happens, then we have
> some stuff that we can clean out."
Ah, ok :)
> > > 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
> > > incompatibility.
> > 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...
> Hrm. This is a bit weird then. Modules will produce errors when they really
> don't need to.
> I understand that it would be handy to say "hey, does the Unicode stuff
> exist", but that same mechanism is going to produce errors at module-init
> time when stuff is loaded.
The modules produce API warnings at startup, but they still
continue to work like before and this is important since
there are many people out there which are used to updating
their software via RPM (or other packagers) and don't know
how to compile source files.
My comment about the API number bump was referring to using
added functionality if available -- there could be #ifdef
sections in the source files to enable/disable e.g. Unicode
Python Pages: http://www.lemburg.com/python/