296
edits
Pythonic: Difference between revisions
Jump to navigation
Jump to search
→Known Problems: add more known problems from notes
(→Python Objects in Octave: clean-up pyobj section: this is basically working, rather than design) |
(→Known Problems: add more known problems from notes) |
||
| Line 124: | Line 124: | ||
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. | ||
Python objects are implemented as Octave classdef objects. More specifically, any Python object is represented by an object of type <tt>pyobject</tt>. which contains a persistent reference to the corresponding Python object. The pyobject class overrides functions such as <tt>class</tt> and <tt>isa</tt> so it appears as if each Python type is represented by a corresponding distinct class in Octave, but in reality they are all of the same type. This is similar to Octave's Java interface. | |||
Because classdef is used, some of the following known issues are specifically related to Octave's classdef implementation, which is still a relatively new work in progress. | |||
<ul> | <ul> | ||
<li>Assignment to <tt>dict</tt> or other mapping object | |||
<li>Assignment to <tt>dict</tt> or other mapping object using string keys fails. The following syntax produces an error: | |||
{{Code||<syntaxhighlight lang="octave"> | {{Code||<syntaxhighlight lang="octave"> | ||
d = py.dict (); | d = py.dict (); | ||
| Line 136: | Line 141: | ||
</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 147: | Line 153: | ||
[y{1:3}] = x{1:3}; | [y{1:3}] = x{1:3}; | ||
</syntaxhighlight>}}</li> | </syntaxhighlight>}}</li> | ||
<li>Function handles to Python functions, bound methods, or other callable objects is not yet supported. As a workaround, the {{Codeline|pyeval}} function can be used to return a reference to a function which can be assigned and called like any Octave function handle, but cannot be passed in to functions that expect a function handle.</li> | <li>Function handles to Python functions, bound methods, or other callable objects is not yet supported. As a workaround, the {{Codeline|pyeval}} function can be used to return a reference to a function which can be assigned and called like any Octave function handle, but cannot be passed in to functions that expect a function handle.</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> | ||
<li>Python objects can't be loaded or saved using the Octave {{Codeline|load}} and {{Codeline|save}} commands. This missing feature applies to any classdef object, this is Octave bug {{Bug|45833}}. As a workaround, any Python pickling or serialization functions can be used to load and save objects separately from the usual Octave workspace techniques.</li> | |||
<li>Names cannot be imported into the current workspace using the {{Codeline|import}} command. {{Codeline|import}} is not yet implemented in Octave at all.</li> | |||
</ul> | |||
In addition, the following workaround may be considered a known issue. I don't know enough about Matlab's Python implementation to know how important this is, but it's worth documenting. | |||
<ul> | |||
<li> | |||
<tt>py.foo</tt> is supposed to act like a kind of dynamic namespace, automatically loading any matching Python function or module that is in the search path. This most closely maps to the concept of a "package" in Matlab or Octave, which would normally be implemented with a <tt>+py</tt> directory. Since we didn't know of an easy way to create a package scope that does some kind of dynamic dispatch, we implemented <tt>py</tt> as an old-style <tt>@py</tt> class. This takes advantage of the fact that the syntax <tt>py.foo</tt> instantiates a <tt>py</tt> object and calls <tt>subsref</tt> on it. This only works because it is an old-style class, with classdef this would be treated like a static class method call rather than a property lookup on an object instance. This lets us interpret the property lookup as a dynamic search of the Python module path. | |||
</li> | |||
</ul> | </ul> | ||