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 20: | Line 20: | ||
== Development == | == Development == | ||
Project development is ongoing among a small group of developers. Communication takes place on the Octave maintainers mailing list. The official | 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]. | ||
== Documentation == | == Documentation == | ||
Line 31: | Line 30: | ||
=== 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 120: | Line 119: | ||
==== 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"> | |||
pyexec('d = dict(one=1, two=2)') # create object in Python | |||
x = pyobj('d') # create pyobj wrapper for that object | |||
pyexec('d = []') # careful, don't lose the object to the GC | |||
x.keys() # list the keys of the dict | |||
clear x # now the object could be GCed | |||
</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. | |||
Notes: | |||
* Seems like the relevant "pointer" is {{Codeline|id()}}. Haven't seen yet how to access an object from its id, except that its a bad idea... | |||
* My plan to create a dict in Python, indexed by {{Codeline|hex(id(x))}}, maybe called {{Codeline|__InOct__}}. Then pass the id of the object to the {{Codeline|@pyobj/pyobj}} constructor. | |||
* Follow along and help out here: https://bitbucket.org/macdonald/pytave/commits/branch/cbm_pyobj | |||
* Rejected idea: 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. See the `networkx` example above: `G` could be returned by `pyeval`. | |||
* {{Codeline|@pyobj/pyobj}} constructor would not normally be called by users. | |||
== Known Problems == | == Known Problems == | ||
This section documents some known problems or limitations of the Python calling interface, usually due to a limitation of the Octave language itself or a bug in Octave that needs some attention. | This section documents some known problems or limitations of the Python calling interface, usually due to a limitation of the Octave language itself or a bug in Octave that needs some attention. | ||
<ul> | <ul> | ||
<li>Assignment to <tt>dict</tt> or other mapping object with string keys fails. The following syntax produces an error: | |||
<li>Assignment to <tt>dict</tt> or other mapping object | |||
{{Code||<syntaxhighlight lang="octave"> | {{Code||<syntaxhighlight lang="octave"> | ||
d = py.dict (); | d = py.dict (); | ||
Line 142: | Line 166: | ||
</syntaxhighlight>}} | </syntaxhighlight>}} | ||
The reason is because Octave strings are interpreted as arrays in many contexts, and this syntax is parsed by Octave as an attempt to assign to 3 elements of an object.</li> | The reason is because Octave strings are interpreted as arrays in many contexts, and this syntax is parsed by Octave as an attempt to assign to 3 elements of an object.</li> | ||
<li>Element indexing on a <tt>list</tt> or other sequence object with a range or set of indices doesn't return the right number of output arguments. Element indexing should return as many values as were indexed, each assigned to the <tt>ans</tt> variable in turn, or be able to wrap the return list in a cell array, as shown here: | <li>Element indexing on a <tt>list</tt> or other sequence object with a range or set of indices doesn't return the right number of output arguments. Element indexing should return as many values as were indexed, each assigned to the <tt>ans</tt> variable in turn, or be able to wrap the return list in a cell array, as shown here: | ||
{{Code||<syntaxhighlight lang="octave"> | {{Code||<syntaxhighlight lang="octave"> | ||
Line 154: | Line 177: | ||
[y{1:3}] = x{1:3}; | [y{1:3}] = x{1:3}; | ||
</syntaxhighlight>}}</li> | </syntaxhighlight>}}</li> | ||
<li>Objects are not deleted because object destructors are not called by Octave when objects are cleared or go out of scope. For the Python interface, this means that the internal store of objects will continue to grow and objects will persist indefinitely even when all Octave references to a given Python object are gone. This is Octave bug {{Bug|46497}}.</li> | <li>Objects are not deleted because object destructors are not called by Octave when objects are cleared or go out of scope. For the Python interface, this means that the internal store of objects will continue to grow and objects will persist indefinitely even when all Octave references to a given Python object are gone. This is Octave bug {{Bug|46497}}.</li> | ||
</ul> | </ul> | ||
Line 176: | Line 183: | ||
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. | 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. | ||