Neil Schemenauer <nas-pyt...@arctrix.com> added the comment:
> I don't understand the rationale for this change in depth, but > does the benefit outweigh (yet another) backwards incompatibility? I think you can have it both ways. Do you want a C API that is stable over a long period of CPython releases or do you want to continue to be able to look deep (i.e. non opaque PyObject*) into CPython implementation internals? During the sprint last week, we talked about how to provide a compatible API, similar to what Pypy cpyext does. It would be possible to provide a (nearly) fully compatible API with the approach. It could get quite painful for CPython to maintain such a thing however. E.g. cpyext has proxy objects (to maintain CPython compatible structure layouts) but keeping those proxies in sync with the internal VM object structures is expensive and tricky. Certainly making PyObject opaque is going to break some 3rd party code. Making it opaque for the non-limited API is not an option IMHO because it breaks too much 3rd party code. Is making it opaque for the limited C API going to break too much code? Maybe, I don't know. Thanks for pointing out pycurl and breezy. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39573> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
