Editing Pythonic
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 3: | Line 3: | ||
== Features == | == Features == | ||
Features and capabilities of Octave's Python interface may include: | |||
* Import and call | * Import and call Python modules and functions from the Octave interpreter | ||
* Automatically convert basic Octave and Python types seamlessly between the two | * Automatically convert basic Octave and Python types seamlessly between the two environments | ||
* | * Be able to handle arbitrary unknown Python objects (print their repr, store in a variable, pass back in to a Python function) | ||
* | * Store references to Python functions (and other "callables") and be able to call them as if they were function handles | ||
== Development == | |||
Project development is ongoing among a small group of developers. Communication takes place on the Octave maintainers mailing list. The official Mercurial repository is at [http://hg.octave.org/pytave http://hg.octave.org/pytave], but there is also a Bitbucket clone and a network of forks, for those who prefer that model of development, at [https://bitbucket.org/mtmiller/pytave https://bitbucket.org/mtmiller/pytave]. | |||
== | == Pytave == | ||
This project is currently derived from an earlier project called Pytave, which was developed to work in the opposite direction, to allow Python to call Octave functions on an embedded Octave interpreter. The bulk of the project is in the code to convert between Octave and Python data types, so most of that is reusable and serves both purposes. As a side goal, we may continue to maintain the Python wrapper around Octave and incorporate that into Octave as well, so that Octave can provide its own native Python module. | |||
=== Documentation === | |||
The current development needs to be documented. We are using doxygen for the documentation. | The current development needs to be documented. We are using doxygen for the documentation. | ||
=== Python from Octave === | === Python from Octave === | ||
The conversion of Python's | The conversion of Python's dict is not unique. For that we have decided to load a Python's dict as a structure. This works only when all the keys fo the dict are strings. When the keys are something else there is the option to use `repr` to create the fields of the Octave's struct, e.g. | ||
<!-- {{SyntaxHighlight| --> | <!-- {{SyntaxHighlight| --> | ||
Line 85: | Line 77: | ||
==== Octave view of Python ==== | ==== Octave view of Python ==== | ||
Currently we can do things like | Currently we can do things like | ||
Line 120: | Line 111: | ||
==== Python Objects in Octave ==== | ==== Python Objects in Octave ==== | ||
The {{Codeline|@ | The {{Codeline|@pyobj}} classdef class is intended to wrap arbitrary Python objects so they can be accessed an manipulated from within Octave. | ||
{{Code|avoiding garbage collection|<syntaxhighlight lang="octave" style="font-size:13px" line highlight="4"> | |||
{{Code||<syntaxhighlight lang="octave"> | pyexec('d = dict(one=1, two=2)') # create object in Python | ||
x = pyobj('d') # create pyobj wrapper for that object | |||
x | pyexec('d = []') # careful, don't lose the object to the GC | ||
x.keys() # list the keys of the dict | |||
clear x # now the object should be GCed | |||
</syntaxhighlight>}} | </syntaxhighlight>}} | ||
One proposed way to do this: | |||
1. `x` stores the pointer to `d`. The `@pyobj` ctor creates a dummy reference to `d`, this prevents GC | |||
2. on deletion of x (`clear x`) we delete the dummy reference in Python. | |||
Other ideas: | |||
* Store the `repr` as a string in `x`. But this makes a copy of the object rather than a reference to the original object. | |||
====== Interface design ====== | |||
{{Codeline|pyeval}} should be modified to return a {{Codeline|@pyobj}} for things that it cannot convert to Octave-native types. | |||