Le sam. 10 nov. 2018 à 02:50, Nathaniel Smith <n...@pobox.com> a écrit : > Doesn't this mean that you're just making the C API larger and more > complicated, rather than simplifying it? You cite some benefits > (tagged pointers, changing the layout of PyObject, making PyPy's life > easier), but I don't see how you can do any of those things so long as > the current C API remains supported.
Tagged pointers and changing the layout of PyObject can only be experimented in a new different Python runtime which only supports C extensions compiled with the new C API. Technically, it can be CPython compiled with a different flag, as there is already python3-dbg (debug mode, ./configure --with-pydebug) and python3 (release mode). Or it can be CPython fork. I don't propose to experiment tagged pointer or changing the layout of PyObject in CPython. It may require too many changes and it's unclear if it's worth it or not. I only propose to implement the least controversial part of the new C API in the master branch, since maintaining this new C API in a fork is painful. I cannot promise that it will make PyPy's life easier. PyPy developers already told me that they already implemented the support of the current C API. The promise is that if you use the new C API, PyPy should be more efficient, because it would have less things to emulate. To be honest, I'm not sure at this point, I don't know PyPy internals. I also know that PyPy developers always complain when we *add new functions* to the C API, and there is a non-zero risk that I would like to add new functions, since current ones have issues :-) I am working with PyPy to involve them in the new C API. Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
