[Python-Dev] Changing ob_size to [s]size_t

[Guido van Rossum]

> > Can you point to a document that records a decision to the contrary?
> 
> Garbage collection, weak references, changes in the memory allocation,
> etc. etc.

IMO this is 100% FUD.

The GC does not change the object lay-out.  It is only triggered for
types that have a specific flag bit.  The changes in the GC API also
changed the flag bit used.  Weak references also use a flag bit in the
type object and if the flag bit is on, look at a field in the type
that checks whether there is a weakref pointer in the object struct.
All objects (with public object lay-out) that have had their struct
extended have always done so by appending to the end.

Tim spent weeks to make the memory allocation code backwards
compatible (with several different versions, binary and source
compatibility).

As an example, the old Zope ExtensionClass code works fine with Python
2.2.

> All these change the binary layout of structs or the semantics
> of memory allocation -- mostly only in slight ways, but to a point
> where 100% binary compatibility is not given anymore.

Still, I maintain that most extensions that work with 1.5.2 still work
today without recompilation, if you can live with the API version
change warnings.  Try it!

> Other changes (which I know of) are e.g. the Unicode APIs which
> have changed (they now include UCS2 or UCS4 depending on whether
> you use 16-bit or 32-bit Unicode internally).

When you compile with UCS2 it should be backward compatible.

> I don't think that binary compatibility is all that important;
> it just requires a recompile (and hey, that way you even get
> sub-type support for free ;-).

Actually, you don't -- you have to set a flag bit to make your type
subclassable.  There are too many things that classic extension types
don't provide.

> Far more difficult to handle are all those minute little changes
> which easily slip the developer's radar.

Examples?

> Luckily this will get approached now by Andrew and Raymond, so
> things are getting much better for us poor souls having to
> live on supporting 3-4 different Python versions :-)

I'm not sure which initiative you are referring to.  Or even which
Andrew (I presume you mean Raymond Hettinger)?

--Guido van Rossum (home page: http://www.python.org/~guido/)