-
Notifications
You must be signed in to change notification settings - Fork 2.2k
[QUESTION] De-deprecation of direct call to module constructor #2718
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This was part of a long discussion in #2413, #2534, and (unfinished/unmerged) #2551. To answer questions and summarize those:
What is your use case? a) Do you just want a module (cfr. b) Do you want more fine-grained control over the main extension module that is the entry point of the C extension, instead of the basic |
I had still forgotten #2552, which actually deprecated the public The one thing it failed to do is repurpose the old |
We use an embedded interpreter and create a couple of modules that are exposed to Python. I am not sure I understand the difference you make between an extension module and a module? |
@martinRenou, so Python seems to be making a difference between To illustrate, compare these two minimal examples, based on the example in the Python docs: #include <Python.h>
static PyMethodDef SpamMethods[] = {
{NULL, NULL, 0, NULL}
};
static struct PyModuleDef spammodule = {
PyModuleDef_HEAD_INIT,"spam", "", -1, SpamMethods
};
PyMODINIT_FUNC
PyInit_spam(void)
{
return PyModule_Create(&spammodule);
} $ python3
Python 3.6.9 (default, Oct 8 2020, 12:12:24)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import spam
>>> The simpler version with #include <Python.h>
PyMODINIT_FUNC
PyInit_spam(void)
{
return PyModule_New("spam");
} $ python3
Python 3.6.9 (default, Oct 8 2020, 12:12:24)
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import spam
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
SystemError: initialization of spam did not return an extension module
>>> So that's why we were trying to move towards a different in pybind11 as well. The first one, that requires the allocation of Does that make sense to you? I don't immediately know what kind of thing you need for an embedded module, but I would expect the second one (without |
Will you consider making this API public? That's the kind of API I am looking for.
IIRC we don't use this because we want to return the |
Well, I proposed #2551, so yes, I'm definitely up for merging it. Feel free to bump it into the others' attention again ;-) Meanwhile, you could just try with
What about just accessing |
We explicitely use the
module
constructor instead of the macro in xeus-python, and got the deprecation warning:Replacing
with
fixes it, but we find it a bit too verbose. Why not allowing direct calls to the constructor?
The text was updated successfully, but these errors were encountered: