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

[Guido van Rossum]

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

Could be that you were breaking the rules of course. :-)

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

There are two kinds of case to be made for binary compatibility, both
involving 3rd party extensions whose maintainer has lost interest.
Case one is: it's only available in binary for a given platform (maybe
something it's linked with wasn't open source).  Case two: the code
doesn't compile any more under a new Python version, and the user who
wants to use it isn't sufficiently versatile in C to be able to fix it
(or has no time).
> > 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
> ...

Hm.  Maybe only the UCS4 variants should be renamed?

Of course, few extensions reference Unicode APIs...

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

But you don't *have* to make any of those changes.  That's the whole
point of backwards compatibility.

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

I think we have left the topic of binary compatibility here. :-)

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

Yeah, I'm waiting for him to check it in as PEP 290.

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