<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Python on John Stowers</title><link>https://johnstowers.co.nz/tags/python/</link><description>Recent content in Python on John Stowers</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 15 Jul 2011 12:01:48 +0000</lastBuildDate><atom:link href="https://johnstowers.co.nz/tags/python/index.xml" rel="self" type="application/rss+xml"/><item><title>Interfacing Python + C + OpenCV via ctypes</title><link>https://johnstowers.co.nz/2011/07/15/interfacing-python-c-opencv-via-ctypes/</link><pubDate>Fri, 15 Jul 2011 12:01:48 +0000</pubDate><guid>https://johnstowers.co.nz/2011/07/15/interfacing-python-c-opencv-via-ctypes/</guid><description>&lt;p&gt;I was recently asked to help a colleague access his image processing C-library from python; quite a common task. As those of you who are familiar with Python might realise, there are a whole bag of ways that this can be accomplished;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://www.swig.org/" rel="noopener"&gt;SWIG&lt;/a&gt;
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://cython.org/" rel="noopener"&gt;Cython&lt;/a&gt;
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;ctypes&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="https://launchpad.net/pybindgen" rel="noopener"&gt;PybindGen&lt;/a&gt;
&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In this case the colleague only needed to access a single function from the library returning image data, and then hand this result onto OpenCV. One happy side effect of the new (&amp;gt; v2.1) python-opencv bindings is that they do &lt;a href="http://opencv.willowgarage.com/documentation/python/cookbook.html#pil-image-to-opencv" rel="noopener"&gt;no validation on CvImage.SetData&lt;/a&gt;
, which means you can pass an arbitrary string/pointer. Because of this I advised him I thought using something like SWIG was overkill, and he could just write a wrapper to his library using ctypes, or a thin python extension directly.&lt;/p&gt;</description></item><item><title>Jhbuild and Windows - We Meet Again</title><link>https://johnstowers.co.nz/2007/12/13/jhbuild-and-windows-we-meet-again/</link><pubDate>Thu, 13 Dec 2007 01:56:18 +0000</pubDate><guid>https://johnstowers.co.nz/2007/12/13/jhbuild-and-windows-we-meet-again/</guid><description>&lt;h3 id="the-good-news"&gt;The Good News&lt;/h3&gt;
&lt;p&gt;Following on from &lt;a href="http://www.johnstowers.co.nz/blog/index.php/2007/12/11/jhbuild-adventures-on-windows/" rel="noopener"&gt;my last post&lt;/a&gt;
 I have continued work on getting Jhbuild to run on windows (within msys). The basic problem which I identified in my last post was the struggle between Python (for Windows) expectations about paths, and the hoops that msys and cygwin jump through to allow unix style paths to be used. Basically os.path.join and friends do the correct thing providing the subsequent path is used within python alone. Things get all difficult when that path is then passed out to a configure script, or as an argument to a shell command. With that in mind however, a picture speaks a thousand words&amp;hellip;.&lt;/p&gt;</description></item><item><title>The Big Move</title><link>https://johnstowers.co.nz/2007/12/06/the-big-move/</link><pubDate>Thu, 06 Dec 2007 13:37:03 +0000</pubDate><guid>https://johnstowers.co.nz/2007/12/06/the-big-move/</guid><description>&lt;p&gt;The short news is that &lt;a href="http://www.conduit-project.org/" rel="noopener"&gt;Conduit&lt;/a&gt;
 now &lt;a href="http://svn.gnome.org/viewvc/conduit/" rel="noopener"&gt;lives in GNOME SVN&lt;/a&gt;
. The move took a little longer than I would have hoped, but thats largely my fault. I would like to express my thanks to &lt;a href="http://blogs.gnome.org/ovitters" rel="noopener"&gt;Olav Vitters&lt;/a&gt;
 for importing the SVN repository, his excellent response time to my emails, and the awesome &lt;a href="http://mango.gnome.org" rel="noopener"&gt;mango&lt;/a&gt;
 system he created.&lt;/p&gt;
&lt;h3 id="whats-good"&gt;Whats Good&lt;/h3&gt;
&lt;p&gt;Conduit trunk is now pretty much feature frozen. It feels really good to finally cross off the TODO list and fix some of the bugs that I created (due to some poor choices when I started the project). While I will blog again soon about the shiny &lt;a href="http://www.conduit-project.org/wiki/0.3.5" rel="noopener"&gt;new features&lt;/a&gt;
 for the moment I will talk about one useful piece of code that I am proud of, and that may be useful to others.&lt;/p&gt;</description></item><item><title>Python Bindings for Evolution</title><link>https://johnstowers.co.nz/2007/05/30/python-bindings-for-evolution/</link><pubDate>Wed, 30 May 2007 05:34:33 +0000</pubDate><guid>https://johnstowers.co.nz/2007/05/30/python-bindings-for-evolution/</guid><description>&lt;p&gt;In order to add &lt;a href="http://www.go-evolution.org/" rel="noopener"&gt;evolution&lt;/a&gt;
 support (contacts, task items and memos) to &lt;a href="http://www.conduit-project.org" rel="noopener"&gt;Conduit&lt;/a&gt;
 I needed to be able to access the relevant parts of evolution-data-server from python. &lt;a href="http://www.conduit-project.org/wiki/evolution-python" rel="noopener"&gt;evolution-python&lt;/a&gt;
 is an incomplete wrapper around &lt;a href="http://www.gnome.org/projects/evolution/developer-doc/libebook/" rel="noopener"&gt;libebook&lt;/a&gt;
 and &lt;a href="http://www.gnome.org/projects/evolution/developer-doc/libecal/" rel="noopener"&gt;libecal&lt;/a&gt;
. It has now got to the stage of being useful, so here is a somewhat nervous announcement of evolution-python v0.0.0&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://files.conduit-project.org/releases/evolution-python-0.0.0.tar.gz" rel="noopener"&gt;Download&lt;/a&gt;
&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://doc.conduit-project.org/evolution-python/" rel="noopener"&gt;API Documentation&lt;/a&gt;
&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This should be considered a work in progress and will be changing a lot over the next few days as I implement methods needed for the two way synchronization of evolution data using Conduit. However the basic skeleton is there, and I invite people to help with the bindings. An easy way to access evolution-data-server from python has been missing for a while now so I hope evolution-python will be useful for others.&lt;/p&gt;</description></item><item><title>Threading and (py)Gtk</title><link>https://johnstowers.co.nz/2007/03/12/threading-and-pygtk/</link><pubDate>Mon, 12 Mar 2007 02:58:31 +0000</pubDate><guid>https://johnstowers.co.nz/2007/03/12/threading-and-pygtk/</guid><description>&lt;p&gt;At the request of a few people I have made a &lt;a href="http://gist.github.com/51686" rel="noopener"&gt;demo to share&lt;/a&gt;
, showing how I do threading in a pygtk application (&lt;a href="http://www.conduit-project.org" rel="noopener"&gt;Conduit&lt;/a&gt;
). I find the following approach seems to work reliably and requires little code. Other approaches can be found &lt;a href="http://aruiz.typepad.com/siliconisland/2006/04/threads_on_pygt.html" rel="noopener"&gt;here&lt;/a&gt;
 and &lt;a href="http://live.gnome.org/PyGTK/FAQ/MainLoopAndThreading" rel="noopener"&gt;here&lt;/a&gt;
.&lt;/p&gt;
&lt;p&gt;This approach takes advantage of the fact that signal emission in glib has been threadsafe since glib 2.8 (IIRC). All communication with the GUI is done via gobject signals. There is definitely a compromise in the level of GUI fiddling that you can do, particularly when compared with the &lt;em&gt;threads_enter/leave&lt;/em&gt; approach. However, I have found this signal based approach sufficent in my case, and that it encourages me to decouple the slow blocking tasks from the GUI.&lt;/p&gt;</description></item><item><title>Mmmm now thats pythonic!</title><link>https://johnstowers.co.nz/2006/11/20/mmmm-now-thats-pythonic/</link><pubDate>Mon, 20 Nov 2006 22:56:22 +0000</pubDate><guid>https://johnstowers.co.nz/2006/11/20/mmmm-now-thats-pythonic/</guid><description>&lt;p&gt;Is it just me or are all the cool apps written in python these days?&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://www.conduit-project.org/" rel="noopener"&gt;Conduit&lt;/a&gt;
 (hehe thats me!)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://listengnome.free.fr/" rel="noopener"&gt;Listen&lt;/a&gt;
 (music management and playback)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://www.exaile.org/" rel="noopener"&gt;Exaile!&lt;/a&gt;
 (amarok styly music app for GTK)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://www.gpixpod.org/wordpress/" rel="noopener"&gt;GPixPod&lt;/a&gt;
 (manage pictures for your ipod)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://specto.sourceforge.net/" rel="noopener"&gt;Specto&lt;/a&gt;
 (why procrastinate when you can have an application do it for you)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://www.fluendo.com/elisa/index.php" rel="noopener"&gt;elisa&lt;/a&gt;
 and pigment (media center by the dudes at &lt;a href="http://www.fluendo.com/" rel="noopener"&gt;Fluendo&lt;/a&gt;
)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://www.beatniksoftware.com/gimmie/" rel="noopener"&gt;Gimmie&lt;/a&gt;
 (desktop revisited)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href="http://raphael.slinckx.net/deskbar/" rel="noopener"&gt;Deskbar&lt;/a&gt;
 (the most useful app on my desktop)&lt;/p&gt;</description></item></channel></rss>