On 2018年11月16日, Nathaniel Smith wrote: > [..] it seems like you should investigate (a) whether you can make > Py_LIMITED_API *be* that API, instead of having two different > ifdefs
That might be a good idea. One problem is that we might like to make backwards incompatible changes to Py_LIMITED_API. Maybe it doesn't matter if no extensions actually use Py_LIMITED_API. Keeping API and ABI compatibility with the existing Py_LIMITED_API could be difficult. What would be the downside of using a new CPP define? We could deprecate Py_LIMITED_API and the new API could do the job. Also, I think extensions should have to option to turn the ABI compatibility off. For some extensions, they will not want to convert if there is a big performance hit (some macros turn into non-inlined functions, call functions rather than access a non-opaque structure). Maybe there is a reason my toggling idea won't work. If we can use a CPP define to toggle between inline and non-inline functions, I think it should work. Maybe it will get complicated. Providing ABI compatibility like Py_LIMITED_API is a different goal than making the API more friendly to alternative Python VMs. So, maybe it is a mistake to try to tackle both goals at once. However, the goals seem closely related and so it would be a shame to do a bunch of work and not achieve both. Regards, Neil _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com