Le mar. 19 févr. 2019 à 21:15, Stefan Behnel <stefan...@behnel.de> a écrit : > What I would ask, though, and I think that's also Jeroen's request, is to > be careful what you lock up behind Py_BUILD_CORE. Any new functionality > should be available to extension modules by default, unless there is a good > reason why it should remain internal. Usually, there is a reason why this > functionality was added, and I doubt that there are many cases where these > reasons are entirely internal to CPython.
I think that we should have some rules here. One rule is that we should avoid APIs which allow to do something no possible in Python. That's an important rule for PyPy and other Python implementations. We cannot avoid such APIs completely, but they should be the exception, not the default. Another rule is to avoid stop adding new APIs which only exist for performance. For example, PyDict_GetItem() only exists for performance: PyObject_GetItem() can be used instead. There are multiple issues with writing "specialized code". For example, PyDict_GetItem() must only used if the type is exactly dict (PyDict_CheckExact). Otherwise, you change the Python semantics (don't respect overriden __getitem__). Each new API means more work for other Python implementations, but also more maintenance work for CPython. Premature optimization is the root of all evil. Most C extensions use premature optimization which are causing us a lot of troubles nowadays when we want to make the C API evolve and cause issues to PyPy which has issues to reimplement the C API on top of their different object model with a different GC. These are just proposals. Feel free to comment :-) Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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
