On Fri, Nov 25, 2005 at 07:40:51PM +0000, Mike Hearn wrote:
On Fri, 25 Nov 2005 11:44:07 -0600, aaron-XW8b5UTxoeLYtjvyW6yDsg wrote:
This is a common misconception. Inkscape doesn't really have Python for scripting. All of the current functionality is just shelled out to the installed system python.
Hmm, are you sure? The configure script checks for various functions in libpython itself like Py_Initialize. Seems odd to check for anything if all it does is run scripts using the command line.
There are actually two different Python scripting systems.
The first is the commandline version Aaron is talking about. This is the one that's in routine use, and that has had many scripts written for it. The limitation (and power) of this system is that it's very self-contained. We interact with these scripts via their STDIN / STDOUT, and that's it. This makes it quite straightforward to create scripts, however it limits the amount of flexibility with what can be done with them, since the scripts couldn't e.g. manipulate internal Inkscape data structures or invoke internal Inkscape commands.
The second is the embedded scripting interpreter. This is what the configure script is set up to check. It is also available via the Inkscape menu (View -> Scripts), if you've compile it in. In theory, this will be able to connect up to Inkscape's internals, but presently it is still at proof-of-concept stage; you can run a script to pop up the about screen, and of course perform any other generic python operations, but that's about it.
The plan is to get the DOM work completed. This will establish a consistent internal API in Inkscape that the scripting system (among other things) can hook into. Without the DOM, we'd have to maintain the scripting language bindings in a more manual, haphazard fashion that would be very difficult to maintain.
Anyway, so the long and short of all this is that yes, you're right that solving the scripting ABI incompatibility issue is definitely important, but not yet critical for Inkscape since it's not something that is going to affect users in the near term. But, say, a year from now, it will be a very big deal, so if you can lay out the best long term scheme for handling these compatibility issues now, it'll help put everyone on the right path for long term needs.
(Btw, also note we have Perl bindings, which I imagine may have similar issues as Perl 6 begins to be deployed.)
Bryce