Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)
On Tue, 20 Nov 2018 23:17:05 +0100 Victor Stinner wrote: > Le mar. 20 nov. 2018 à 23:08, Stefan Krah a écrit : > > Intuitively, it should probably not be part of a limited API, but I never > > quite understood the purpose of this API, because I regularly need any > > function that I can get my hands on. > > (...) > > Reading typed strings directly into an array with minimal overhead. > > IMHO performance and hiding implementation details are exclusive. You > should either use the C API with impl. details for best performances, > or use a "limited" C API for best compatibility. > > Since I would like to not touch the C API with impl. details, you can > imagine to have two compilation modes: one for best performances on > CPython, one for best compatibility (ex: compatible with PyPy). I'm > not sure how the "compilation mode" will be selected. You mean the same API can compile to two different things depending on a configuration? I expect it to be error-prone. For example, let's suppose I want to compile in a given mode, but I also use Numpy's C API. Will the compile mode "leak" to Numpy as well? What if a third-party header includes "Python.h" before I do the "#define" that's necessary? Regards Antoine. ___ 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
Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)
Le mer. 21 nov. 2018 à 12:11, Antoine Pitrou a écrit : > You mean the same API can compile to two different things depending on > a configuration? Yes, my current plan is to keep #include but have an opt-in define to switch to the new C API. > I expect it to be error-prone. For example, let's suppose I want to > compile in a given mode, but I also use Numpy's C API. Will the > compile mode "leak" to Numpy as well? For example, if we continue to use Py_LIMITED_API: I don't think that Numpy currently uses #ifdef Py_LIMITED_API, nor plans to do that. If we add a new define (ex: my current proof-of-concept uses Py_NEWCAPI), we can make sure that it's not already used by Numpy :-) > What if a third-party header > includes "Python.h" before I do the "#define" that's necessary? IMHO the define should be added by distutils directly, using -D in compiler flags. I wouldn't suggest: #define #include But the two APIs should diverge, so your C extension should also use a define to decide to use the old or the new API. So something will break if you mess up in the compilation :-) 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
[Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]
On 2018-11-19, 11:59 GMT, Stefan Krah wrote: > In practice people desperately *have* to use whatever is > there, including functions with underscores that are not even > officially in the C-API. Yes, there are some functions which evaporated and I have never heard a reason why and how I am supposed to overcome their removal. E.g., when porting M2Crypto to Python3 I had to reimplement my own (bad) version of `FILE* PyFile_AsFile(PyObject *pyfile)` function (https://is.gd/tgQGDw). I think it is obvious why it is necessary for C bindings, and I have never found a way how to get the underlying FILE handle from the Python File object properly. Just my €0.02. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 All of us could take a lesson from the weather. It pays no attention to criticism. -- somewhere on the Intenret ___ 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
Re: [Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]
On Wed, Nov 21, 2018, at 06:53, Matěj Cepl wrote: > On 2018-11-19, 11:59 GMT, Stefan Krah wrote: > > In practice people desperately *have* to use whatever is > > there, including functions with underscores that are not even > > officially in the C-API. > > Yes, there are some functions which evaporated and I have never > heard a reason why and how I am supposed to overcome their > removal. E.g., when porting M2Crypto to Python3 I had to > reimplement my own (bad) version of `FILE* > PyFile_AsFile(PyObject *pyfile)` function > (https://is.gd/tgQGDw). I think it is obvious why it is > necessary for C bindings, and I have never found a way how to > get the underlying FILE handle from the Python File object > properly. In Python 3, there is no underlying FILE* because the io module is implemented using fds directly rather than C stdio. ___ 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
Re: [Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]
Please open a bug report once you have such issue ;-) Victor Le mer. 21 nov. 2018 à 15:56, Matěj Cepl a écrit : > > On 2018-11-19, 11:59 GMT, Stefan Krah wrote: > > In practice people desperately *have* to use whatever is > > there, including functions with underscores that are not even > > officially in the C-API. > > Yes, there are some functions which evaporated and I have never > heard a reason why and how I am supposed to overcome their > removal. E.g., when porting M2Crypto to Python3 I had to > reimplement my own (bad) version of `FILE* > PyFile_AsFile(PyObject *pyfile)` function > (https://is.gd/tgQGDw). I think it is obvious why it is > necessary for C bindings, and I have never found a way how to > get the underlying FILE handle from the Python File object > properly. > > Just my €0.02. > > Matěj > -- > https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz > GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 > > All of us could take a lesson from the weather. It pays no > attention to criticism. > -- somewhere on the Intenret > > ___ > 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/vstinner%40redhat.com ___ 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
Re: [Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]
On 2018-11-21, 14:54 GMT, Benjamin Peterson wrote: > In Python 3, there is no underlying FILE* because the io > module is implemented using fds directly rather than C stdio. OK, so the proper solution is to kill all functions which expect FILE, and if you are anal retentive about stability of API, then you have to fake it by creating FILE structure around the underlying fd handler as I did in M2Crypto, right? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If you have a problem and you think awk(1) is the solution, then you have two problems. -- David Tilbrook (at least 1989, source of the later famous jwz rant on regular expressions). ___ 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
