[Python-Dev] Changing ob_size to [s]size_t
Guido van Rossum
Fri, 07 Jun 2002 15:25:10 -0400
> 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
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
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
Yeah, I'm waiting for him to check it in as PEP 290.
--Guido van Rossum (home page: http://www.python.org/~guido/)