M.-A. Lemburg writes: > I've only tested these using my mx tools compiled against 1.5 -- > really old, I know, but I still actively use that version. tp_xxx7/8 > were added in Python 1.5.2, I think, so writing to them causes > the core dump. Yep. I said: > For the specific problem you mention, we could add a type flag > (Py_TPFLAGS_HAVE_WEAKREFS) that could be tested; it would be set in > Py_TPFLAGS_DEFAULT. M-A replied: > That would work, but is it really worth it ? The APIs have changed > considerably, so the fact that I got away with a warning in Python2.0 No, which is why I'm happy to tell you to recomple your extensions. > doesn't really mean anything -- I do have a problem now, though, > since maintaining versions for 1.5, 1.5.2, 2.0 and 2.1 will > be a pain :-/ Unless you're using PyCode_New() or PyFrame_New(), recompiling the extension should be all you'll need -- unless you're pulling stunts like ExtensionClass does (defining a type-like object using an old definition of PyTypeObject). If any of the functions you're calling have changed signatures, you'll need to update them anyway. The weakref support will not cause you to change your code unless you want to be able to refer to your extension types via weak refs. > Py_FatalError() is a bit too harsh, I guess. Wouldn't it > suffice to raise an ImportError exception and have Py_InitModule() > return NULL in case a module with an incompatible API version is > encountered ? I suppose we could do that, but it'll take more than my agreement to make that happen. Guido seemed to think that few modules will be calling PyCode_New() and PyFrame_New() directly (pyexpat being the exception). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
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