zfs discuss - Jul 2008 - Announcement: The Unofficial Unsupported Python ZFS API

I''ve put together some Python/Swig/C++ code that allows Python
programs to interface directly with libzfs.  It works fairly well: you
can open filesystems and pools, retrieve properties, iterate over
filesystems using a Python function instead of a C one, things throw
exceptions properly, and it would be easy to add more functionality.
It runs on either OpenSolaris or Solaris 10, x86 or Sparc, and uses
either gcc or Sun Studio to build.  Any combination of the above
should work, but I''ve only tested a few.

As mentioned, this uses libzfs, and is thus not a stable interface to
be relied on.  It does work, though.  I currently plan to keep it
working and improve it, but if time gets tight for me, this is pretty
low on my list of priorities.

See http://will.incorrige.us/pyzfs/ for the download and installation
instructions.  If anyone is interested in helping me complete (or has
suggestions on altering) the functionality of this library, please
contact me at this address and send me your ssh public key for
Subversion access.

Suggestions, comments, questions are welcome.

Will

Hi

I had a quick look. Looks great!

A suggestion - From given example, I think API could be made more
"pythonic". Python is dynamically typed and properties can be
dynamically looked up too. Thus, instead of prop_get_* we can have -

1. prop() : generic function, returning "typed" arguments. The builtin
zfs properties would be returned with correct "type" and user
properties would be returned as generic string.

2. Ability to just say "z.property_name" (eg. z.compression). This
would be trivial to implement syntactic sugar.

Also, some work would be needed to provide "pythonic" iterators and
other idioms so that API does not feel like a python interface to C.

Thanks

- Akhilesh
 
 
This message posted from opensolaris.org

As long as I''m composing an email, I might as well mention that I had
forgotten to mention Swig as a dependency (d''oh!).  I now have a
mention of it on the page, and a spec file that can be built using
pkgtool.  If you tried this before and gave up because of a missing
package, please give it another shot.

On Mon, Jul 14, 2008 at 10:35, Akhilesh Mritunjai
<mritun+opensolaris at gmail.com> wrote:
> I had a quick look. Looks great!
Thanks!
> A suggestion - From given example, I think API could be made more
"pythonic". Python is dynamically typed and properties can be
dynamically looked up too. Thus, instead of prop_get_* we can have -
>
> 1. prop() : generic function, returning "typed" arguments. The
builtin zfs properties would be returned with correct "type" and user
properties would be returned as generic string.
Definitely.  This was just a barebones "does it work" kind of thing.
I do plan to make it more python-styled than C-wrapper styled, but I
wanted to go for the "release early, release often" kind of thing.
> 2. Ability to just say "z.property_name" (eg. z.compression).
This would be trivial to implement syntactic sugar.
Sure.  This will just take a bunch of wrappers to get/set all the properties.
> Also, some work would be needed to provide "pythonic" iterators
and other idioms so that API does not feel like a python interface to C.
This I''m not so sure about.  I could do it, sure, but the only way I
can think of to do this would basically be this:
def iterable_filesystems(self):
    def fn(fs, data):
        data.append(fs)
    list_of_fs = []
    self.iter_filesystems(fn, list_of_fs)
    return list_of_fs
Granted, perhaps this isn''t pythonic as it stands, but especially in
cases with thousands of filesystems storing all those objects could
get (relatively) expensive.  I may have to look into the Python API
some more; perhaps there''s a way to provide an iterable object without
shoving everything into Python space at once.

Will

On 14 Jul 2008, at 16:07, Will Murnane wrote:
> As long as I''m composing an email, I might as well mention that I
had
> forgotten to mention Swig as a dependency (d''oh!).  I now have a
> mention of it on the page, and a spec file that can be built using
> pkgtool.  If you tried this before and gave up because of a missing
> package, please give it another shot.
Not related to the actual API itself, but just thought I''d note that  
all the cool kids are using ctypes these days to bind Python to  
foreign libraries.

http://docs.python.org/lib/module-ctypes.html

This has the advantage of requiring no other libraries and no compile  
phase at all.

Jonathan

I have applied for and received approval for a Sourceforge project.
It''s rather barebones at the moment, but the important part is a
public Subversion server is now available.  See
https://pyzfs.svn.sourceforge.net/svnroot/pyzfs/trunk .

On Mon, Jul 14, 2008 at 12:04, Jonathan Hogg
<jonathan at significant-whitespace.com> wrote:
> Not related to the actual API itself, but just thought I''d note
that all the
> cool kids are using ctypes these days to bind Python to foreign libraries.
Look!  Some Joneses!  We better keep up with them!  There''s just no
pleasing some people.

In completely unrelated news, I have decided to try using ctypes
instead of Swig.  See the prototype code (with less error checking and
no working iterators) at
https://pyzfs.svn.sourceforge.net/svnroot/pyzfs/trunk/ctypes .
> This has the advantage of requiring no other libraries and no compile phase
> at all.
Not quite true---if you mess things up badly enough you can get
compiler errors from the C code that Python generates and compiles
behind the scenes.  But at least you get to write in Python, not C++.

Will