(original) (raw)
Zach has a patch to automate putting the right exports in python3.dll, which I'm strongly in favor of, but it was rejected because people may have added APIs that aren't meant to be stable.
Right now, you can #include a number of prototypes that aren't actually available because there are two places to update and so one (in this case, the DLL) doesn't get updated.
I think the current plan is to remove everything not currently in the DLL from the stable ABI and force people to add them back manually. This way we can enable the generator without committing to a large set of new APIs.
I don't have the issue number handy, but it should be near the top of the recently modified list.
Cheers,
Steve
Top-posted from my Windows Phone
Right now, you can #include a number of prototypes that aren't actually available because there are two places to update and so one (in this case, the DLL) doesn't get updated.
I think the current plan is to remove everything not currently in the DLL from the stable ABI and force people to add them back manually. This way we can enable the generator without committing to a large set of new APIs.
I don't have the issue number handy, but it should be near the top of the recently modified list.
Cheers,
Steve
Top-posted from my Windows Phone
From: Paul Moore
Sent: �5/�28/�2015 7:12
To: Python Dev
Subject: \[Python-Dev\] Usability of the limited API
With Python 3.5 shipping an embeddable copy of the interpreter on
Windows, I thought I'd try out a simple embedded interpreter as an
experiment. I wanted to use the limited API, as I'd rather it were
easy to upgrade the interpreter without recompiling the embedding app.
But the "Very high-level embedding" example in the docs doesn't
compile with the limited API.
#include
int
main(int argc, char \*argv\[\])
{
wchar\_t \*program = Py\_DecodeLocale(argv\[0\], NULL);
if (program == NULL) {
fprintf(stderr, "Fatal error: cannot decode argv\[0\]\\n");
exit(1);
}
Py\_SetProgramName(program); /\* optional but recommended \*/
Py\_Initialize();
PyRun\_SimpleString("from time import time,ctime\\n"
"print('Today is', ctime(time()))\\n");
Py\_Finalize();
PyMem\_RawFree(program);
return 0;
}
The Py\_DecodeLocale/Py\_SetProgramName/PyMem\_RawFree bit can probably
be replaced by a Py\_SetProgramName call specifying a static value,
it's not exactly crucial. (Py\_DecodeLocale appears to be defined as in
the limited API by the headers, but not exported from python3.dll, by
the way, which implies that something's out of sync).
But PyRun\_SimpleString doesn't appear to be exposed in the limited
API, even though https://docs.python.org/3/c-api/veryhigh.html doesn't
mention this, and https://docs.python.org/3/c-api/stable.html says
that functions not part of the stable API will be marked as such.
I dumped out the exported symbols from python3.dll, which is the
simplest way I could think of finding out what is in the limited API
(it's hardly user friendly, but never mind). And frustratingly, none
of the very high level PyRun\_XXX APIs are available.
At this point, I think I'll probably just give up and use the full
API, but it does make me question whether the limited API is actually
usable as it stands.
I was hoping to be able to suggest as an application bundling option
that people could write a trivial wrapper script in C to fire up a
Python script, and bundle that along with its dependencies and the
embeddable Python distribution. Looks like that's doable, but only
using the full API, which makes upgrading the bundled Python
interpreter a bit messier. Ah, well, no huge loss :-(
But after this experiment, I do wonder - is the limited API really a
viable option for embedders?
Paul
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
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/steve.dower%40microsoft.com
Windows, I thought I'd try out a simple embedded interpreter as an
experiment. I wanted to use the limited API, as I'd rather it were
easy to upgrade the interpreter without recompiling the embedding app.
But the "Very high-level embedding" example in the docs doesn't
compile with the limited API.
#include
int
main(int argc, char \*argv\[\])
{
wchar\_t \*program = Py\_DecodeLocale(argv\[0\], NULL);
if (program == NULL) {
fprintf(stderr, "Fatal error: cannot decode argv\[0\]\\n");
exit(1);
}
Py\_SetProgramName(program); /\* optional but recommended \*/
Py\_Initialize();
PyRun\_SimpleString("from time import time,ctime\\n"
"print('Today is', ctime(time()))\\n");
Py\_Finalize();
PyMem\_RawFree(program);
return 0;
}
The Py\_DecodeLocale/Py\_SetProgramName/PyMem\_RawFree bit can probably
be replaced by a Py\_SetProgramName call specifying a static value,
it's not exactly crucial. (Py\_DecodeLocale appears to be defined as in
the limited API by the headers, but not exported from python3.dll, by
the way, which implies that something's out of sync).
But PyRun\_SimpleString doesn't appear to be exposed in the limited
API, even though https://docs.python.org/3/c-api/veryhigh.html doesn't
mention this, and https://docs.python.org/3/c-api/stable.html says
that functions not part of the stable API will be marked as such.
I dumped out the exported symbols from python3.dll, which is the
simplest way I could think of finding out what is in the limited API
(it's hardly user friendly, but never mind). And frustratingly, none
of the very high level PyRun\_XXX APIs are available.
At this point, I think I'll probably just give up and use the full
API, but it does make me question whether the limited API is actually
usable as it stands.
I was hoping to be able to suggest as an application bundling option
that people could write a trivial wrapper script in C to fire up a
Python script, and bundle that along with its dependencies and the
embeddable Python distribution. Looks like that's doable, but only
using the full API, which makes upgrading the bundled Python
interpreter a bit messier. Ah, well, no huge loss :-(
But after this experiment, I do wonder - is the limited API really a
viable option for embedders?
Paul
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
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/steve.dower%40microsoft.com