On 23-Oct-2006, at 16:58 , Larry Hastings wrote: > I genuinely don't know how many external Python extension modules > are well-behaved in this regard. But in case it helps: I just > checked PIL, NumPy, PyWin32, and SWIG, and all of them were well- > behaved. > > Apart from stringobject.c, there was exactly one spot in the Python > source tree which made assumptions about the structure of > PyStringObjects (Mac/Modules/macos.c). It's in the block starting > with the comment "This is a hack:". Note that this is unfixed in > my patch, so just now all code using that self-avowed "hack" will > break. As the author of that hack, that gives me an idea for where you should look for code that will break: code that tries to expose low- level C interfaces to Python. (That hack replaced an even earlier worse hack, that took the id() of a string in Python and added a fixed number to it to get at the address of the string, to fill it into a structure, blush). Look at packages such as win32, PyObjC, ctypes, bridges between Python and other languages, etc. That's where implementors are tempted to bend the rules of Official APIs for the benefit of serious optimizations. -- Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20061024/fe49d742/attachment.html
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