Re: [zfs-discuss] Announcement: The Unofficial Unsupported Python ZFS API
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 <[EMAIL PROTECTED]> 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Announcement: The Unofficial Unsupported Python ZFS API
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Announcement: The Unofficial Unsupported Python ZFS API
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 <[EMAIL PROTECTED]> 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Announcement: The Unofficial Unsupported Python ZFS API
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
