Pythonic: Difference between revisions

From Octave
Jump to navigation Jump to search
(pyobj notes)
Line 107: Line 107:
G_struct = struct(G); # G converted to a struct
G_struct = struct(G); # G converted to a struct
</syntaxhighlight>}}
</syntaxhighlight>}}
==== Python Objects in Octave ====
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 should 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.
Other ideas:
2. Store the `repr` as a string in `x`.  This makes a copy of the object rather than a reference to the original object.

Revision as of 18:41, 18 May 2016

There is a small project in development to bring a Python calling interface to Octave. The broad goal of this project is to add functions and types to Octave to allow calling Python functions directly from Octave.

Features

Features and capabilities of Octave's Python interface may include:

  • Import and call Python modules and functions from the Octave interpreter
  • 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, 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.

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.

Python from Octave

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.

Code: Conversion of Python's dict to structure
> x = pyeval ("{1:'one',2:'two'}");
> x.("1")
ans = one

> x.("2")
ans = two

> x = pyeval ("{(1,1):'one',2.5:'two'}");
> x.("(1,1)")
ans = one

> x.("2.5")
ans = two

This would be the default behavior. We will extend pyeval to receive an optional argument specifying the Octave type that should be used as the output of the conversion, e.g. when the dict uses continuos numbers as keys one could do

Code: pyeval optional argument
> x = pyeval ("{1:'one',2:'two'}",@cell);
> x{1}
ans = one
> x{2}
ans = two

> x = pyeval ("{1:'one',2:'two'}",@char);
> x

x = 

one
two
 
> whos x
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  ===== 
        x           2x3                          6  char

Total is 6 elements using 6 bytes

> x = pyeval ("[i for i in xrange(3)]",@double)
x =
0 1 2

The optional argument could be the constructor of an Octave class.

Octave view of Python

Currently we can do things like

Code: Objects in python exists across calls to pyexec and pyeval
pyexec ("import networkx as nx")
pyexec ("G=nx.complete_graph(10)")
x = pyeval ("G.nodes()")

But we cannot get a representation of G within Octave.

The idea is to have an object that maintains a pointer to an Python object and that has all the methods to convert that object to Octave.

The python object can be manipulated by python calls like pycall and pyexec without needing to do an explicit conversion. For example

Code: Octave object that points to a python object
pyexec ("import networkx as nx")
pyexec ("G=nx.complete_graph(10)")
G      = pyobj ("G") ## G is an object without Octave representation but with methods to do the conversion if required
nodes  = pycall ("nx.nodes",G) # Python nx.nodes(G)
nodes2 = pyeval ("G.nodes()")  # Equivalent

Comment: It seems that pyexec and pycall do not share workspace, so the code above wont work because nx doesn't exist when we call pycall at line 4.

The conversion methods should provide different output objects to Octave. The idea is to be able to call something like

Code: Octave view of Python object with conversion methods
G_cell   = cell(G);   # G converted to a cell
G_struct = struct(G); # G converted to a struct


Python Objects in Octave

The @pyobj classdef class is intended to wrap arbitrary Python objects so they can be accessed an manipulated from within Octave.

Code: avoiding garbage collection
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 should be GCed

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:

2. Store the `repr` as a string in `x`. This makes a copy of the object rather than a reference to the original object.