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

[M.-A. Lemburg]

Guido van Rossum wrote:
>>>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.

Could be 95% FUD :-), but I do remember that older versions of my
extensions broke when weak references were introduced.

> 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!

That's true for most extensions.

Note that I wasn't saying that they all broke... distutils is
mainly being very careful about the Python version on Windows
because the name of the DLL contains the version name and the
reference is hard-coded into the extension DLLs.

Also, I don't have a problem with recompiling an extension for
a new Python version. What's important to me is that the
existing code continues to compile and work, not that a
compiled version for some old Python version continues
to run in a new version (the warnings are unacceptable in
a production environment, so there's no point in discussing
this).

>>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.

No, it's not:

08077f18 T PyUnicodeUCS2_AsASCIIString
0807da34 T PyUnicodeUCS2_AsCharmapString
080760a8 T PyUnicodeUCS2_AsEncodedString
08077b54 T PyUnicodeUCS2_AsLatin1String
0807d84c T PyUnicodeUCS2_AsRawUnicodeEscapeString
08076f64 T PyUnicodeUCS2_AsUTF16String
0807d6b4 T PyUnicodeUCS2_AsUTF8String
...

>>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.

I was referring to the Py<Type>_Check() changes. After
a recompile they now also accept subtypes.

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

Just see Raymond's PEP for a list of coding changes over the
years. Before this list existed , getting at that information was
hard.

Other subtle changes include the bool stuff, things like re starting
to fail when it sees multiple definitions of group names, changes
to xrange, change of character escaping, new scoping rules,
renaming in the C API (Length->Size) etc. etc.

>>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. 

The migration guide.

> Or even which
> Andrew (I presume you mean Raymond Hettinger)?

Andrew Kuchling.

Raymond Hettinger is summarizing the new coding style
possiblities (and how to write code for older Python
versions).

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/
Meet us at EuroPython 2002:                 http://www.europython.org/