It probably ships with python on some platforms. Pretty sure it does on Windows.
But it does not really have a python API. Most (all?) extensions that ship with Inkscape are written in python, and it comes with some base classes and helper modules to make those extensions. But the "API" is basically "we send the current document to the extension's stdin, and whatever comes out as stdout becomes the new document". The extension, written in Python or something else, is responsible for handling all the quirks of SVG (a mix of subsets of two or more of the SVG specs) and (the current version of) Inkscape's additions to SVG.
It is quite painful. I have maintained a couple of third-party extensions written in python since back in Inkscape 0.99.x days (ca 2007). Had to do several annoying major rewrites. Since there is no real API you depend on whatever happens to be in those helper classes, rarely documented and never stable. One of my extension, as do some of the first-party extensions, have to rely on launching Inkscape as a sub-process to perform some work, since there is no way to call in to the running Inkscape. If there was a real API you could have functions to call to query about the boundaries of objects, and other functions to apply changes to objects, that could use internal implementations that are already existing and that can do those things. But the way it works now (and always worked in Inkscape) is that you have to take care of everything yourself, more or less, maybe helped by some of the included helpers if you are lucky to find something that does something similar to what you want to do.
Pretty much done with this. I stopped officially supporting new Inksape versions. I just tell users that the next time Inkscape messes with their not-really-API my extensions will be dead. I can still run them with old Inkscape in some virtual machine. Maybe I will re-implement everything if I find an application that has strong backwards-compatibility goals.
But it does not really have a python API. Most (all?) extensions that ship with Inkscape are written in python, and it comes with some base classes and helper modules to make those extensions. But the "API" is basically "we send the current document to the extension's stdin, and whatever comes out as stdout becomes the new document". The extension, written in Python or something else, is responsible for handling all the quirks of SVG (a mix of subsets of two or more of the SVG specs) and (the current version of) Inkscape's additions to SVG.
It is quite painful. I have maintained a couple of third-party extensions written in python since back in Inkscape 0.99.x days (ca 2007). Had to do several annoying major rewrites. Since there is no real API you depend on whatever happens to be in those helper classes, rarely documented and never stable. One of my extension, as do some of the first-party extensions, have to rely on launching Inkscape as a sub-process to perform some work, since there is no way to call in to the running Inkscape. If there was a real API you could have functions to call to query about the boundaries of objects, and other functions to apply changes to objects, that could use internal implementations that are already existing and that can do those things. But the way it works now (and always worked in Inkscape) is that you have to take care of everything yourself, more or less, maybe helped by some of the included helpers if you are lucky to find something that does something similar to what you want to do.
Pretty much done with this. I stopped officially supporting new Inksape versions. I just tell users that the next time Inkscape messes with their not-really-API my extensions will be dead. I can still run them with old Inkscape in some virtual machine. Maybe I will re-implement everything if I find an application that has strong backwards-compatibility goals.