[Python-Dev] Usability of the limited API

[Steve Dower]

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
________________________________
From: Paul Moore<mailto:p.f.moore at gmail.com>
Sent: ‎5/‎28/‎2015 7:12
To: Python Dev<mailto:python-dev at python.org>
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 <Python.h>

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 at python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150528/1c2c474a/attachment.html>