Stefan Behnel added the comment: I'm a bit torn on this. On the one hand, it's basically saying, "Cython is probably going to do it right anyway, so let's just assume it does". That's nice, and might be applicable to other cases as well. But that also feels like it could need some kind of versioning.
On the other hand, it's totally not magic to implement something similar by hand, so naming the flag in a Cython specific way feels wrong from a design perspective. Other tools might start picking it up, and that would lead to major confusion. In a way, it's both very broad and too narrow. Basically, if we expect the flag to be used in a broader way, I'm happy to generally mark Cython modules with it. It's very explicit in *that* regard. I'm just not sure that the use case at hand is the right reason to introduce this kind of general marker. Speaking of versioning, though, what about introducing a generic slot field instead that notes the latest CPython API version known to work with the module? (Cast pointer value to int to get the value.) That way, CPython could introduce new extension module behaviour with new C-API versions, and tools that support them can update their version value in the slot to mark them as safely supported. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30403> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
