> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4