<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:wfw="http://wellformedweb.org/CommentAPI/"
     >
  <channel>
    <title>Honeypot.net</title>
    <link>http://honeypot.net/</link>
    <description>Herding cats and happy.</description>
    <pubDate>Thu, 21 Feb 2013 05:40:32 GMT</pubDate>
    <generator>Blogofile</generator>
    <sy:updatePeriod>hourly</sy:updatePeriod>
    <sy:updateFrequency>1</sy:updateFrequency>
    <item>
      <title>Yet another Python map()</title>
      <link>http://honeypot.net/2008/04/16/yet-another-python-map/</link>
      <pubDate>Wed, 16 Apr 2008 08:11:00 CDT</pubDate>
      <category><![CDATA[geek]]></category>
      <category><![CDATA[python]]></category>
      <category><![CDATA[multiprocessing]]></category>
      <guid isPermaLink="true">http://honeypot.net/2008/04/16/yet-another-python-map/</guid>
      <description>Yet another Python map()</description>
      <content:encoded><![CDATA[<p>In <a href="/2007/07/06/multi-processing-map-python/">another article</a>, I described a replacement for Python's built-in map() function that could take advantage of multi-processing systems.  That one was based on the standard Unix fork().  Since then, I've written another based on <a href="http://www.parallelpython.com/">Parallel Python</a> that is much simpler and lets other, better-tested code do all the hard work.  It could also be easily extended to run on a cluster instead of just the local system, but I haven't been inclined to tinker with that too much yet.</p>
<p>Note one possibly important difference from the builtin map() function: this version returns a generator that yields values as they are calculated.  That way, you can launch the parallel processes then go on with other work while you give the workers a chance to finish their jobs.</p>
<p>Kudos to <a href="http://www.connellybarnes.com/code/python/forkmap">Connelly</a> for nudging me to finally publish this.</p>
<p><strong>Download:</strong> <a href="/files/ppmap.py">ppmap.py</a></p>]]></content:encoded>
    </item>
    <item>
      <title>Multi-processing map() for Python</title>
      <link>http://honeypot.net/2007/07/06/multi-processing-map-python/</link>
      <pubDate>Fri, 06 Jul 2007 15:35:13 CDT</pubDate>
      <category><![CDATA[geek]]></category>
      <category><![CDATA[python]]></category>
      <category><![CDATA[multiprocessing]]></category>
      <guid isPermaLink="true">http://honeypot.net/2007/07/06/multi-processing-map-python/</guid>
      <description>Multi-processing map() for Python</description>
      <content:encoded><![CDATA[<p>I think that Python should use multi-processing and/or multi-threading to take advantage of as many opportunities for parallel execution as possible. To this end, I've written a drop-in replacement for map() that runs across as many processes as requested. It should be otherwise identical in every way the built-in version (and if it's not please let me know!).</p>
<p>I also wrote <a href="/2008/04/16/yet-another-python-map/">a version based on Parallel Python</a> that is a lot simpler but not quite identical to the original. In particular, it returns a generator instead of a list of values so that program execution doesn't block until the results are fetched.</p>
<p>Drop me a line if you find this interesting or useful or just plain dumb.</p>
<p><strong>Download:</strong> <a href="/files/forkmap.py">forkmap.py</a></p>]]></content:encoded>
    </item>
  </channel>
</rss>
