<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>Python</title><link>http://blogs.acceleration.net/ryan/category/24.aspx</link><description>Things dealing with... you guessed it: python.</description><managingEditor>Ryan</managingEditor><dc:language>en-US</dc:language><generator>.Text Version 0.95.2004.102</generator><item><dc:creator>Ryan</dc:creator><title>Improved Nant build for Cog</title><link>http://blogs.acceleration.net/ryan/archive/2005/02/09/637.aspx</link><pubDate>Wed, 09 Feb 2005 18:39:00 GMT</pubDate><guid>http://blogs.acceleration.net/ryan/archive/2005/02/09/637.aspx</guid><description>I followed my own advice on &lt;a href="http://blogs.acceleration.net/ryan/articles/577.aspx"&gt;code generation&lt;/a&gt;, and found that my build
   file didn't scale at all to a larger project, taking about a minute to run the codegen task on a couple hundred files.  I guessed that 
   most of the time was being spent in the &lt;code&gt;&lt;a href="http://nant.sourceforge.net/release/latest/help/tasks/exec.html"&gt;exec&lt;/a&gt;&lt;/code&gt; task, 
   which was instantiating the python interpreter, and that just seemed like a lot of overhead.  Lucky for me, 
   &lt;a href="http://www.nedbatchelder.com/"&gt;Ned&lt;/a&gt; is a smart guy, and one of &lt;a href="http://www.nedbatchelder.com/code/cog/"&gt;Cog&lt;/a&gt;'s options is
   to take a file containing a list of files to process.  So, now I can iterate over my project, make a text file (fileList.txt) containing the path to each file
   I want to run the codegen for, and then pass that fileList.txt to Cog at the end, only having to exec python once.  That reduced the build time from 
   64.7s to 3.2s.  Not to shabby for 10 minutes worth of work.&lt;br /&gt;&lt;br /&gt;
   Here's the updated &lt;code&gt;codegen&lt;/code&gt; nant target.  The rest of the build file remains the same.
   &lt;pre class="Code"&gt;
&amp;lt;target name="codegen"&amp;gt;
   
   &amp;lt;!-- if there's an old one, delete it.--&amp;gt;
   &amp;lt;delete file="fileList.txt" if="${file::exists('fileList.txt')}"/&amp;gt;      
   
   &amp;lt;!-- generate the new file list --&amp;gt;
   &amp;lt;foreach item="File" property="filename"&amp;gt; 
      &amp;lt;in&amp;gt; 
         &amp;lt;items&amp;gt;
            &amp;lt;include name="**.cs" /&amp;gt;
            &amp;lt;include name="**.js" /&amp;gt;
            &amp;lt;include name="**.xul" /&amp;gt;
         &amp;lt;/items&amp;gt; 
      &amp;lt;/in&amp;gt; 
      &amp;lt;do&amp;gt; 
         &amp;lt;echo file="fileList.txt" message="${filename}" append="true"/&amp;gt;
      &amp;lt;/do&amp;gt; 
   &amp;lt;/foreach&amp;gt;
   
   &amp;lt;!-- pass the file list to Cog --&amp;gt;
   &amp;lt;exec program="python"&amp;gt;
            &amp;lt;arg value="cog.py" /&amp;gt;
            &amp;lt;arg value="-r" /&amp;gt;
            &amp;lt;arg value="@fileList.txt" /&amp;gt;
   &amp;lt;/exec&amp;gt;
   
   &amp;lt;!-- clean up --&amp;gt;
   &amp;lt;delete file="fileList.txt" failonerror="true"/&amp;gt;
&amp;lt;/target&amp;gt;   &lt;/pre&gt;
I'm digging into this stuff in earnest starting this week, so I'll post again when I find the next naive mistake.&lt;img src ="http://blogs.acceleration.net/ryan/aggbug/637.aspx" width = "1" height = "1" /&gt;</description><body xmlns="http://www.w3.org/1999/xhtml">I followed my own advice on <a href="http://blogs.acceleration.net/ryan/articles/577.aspx">code generation</a>, and found that my build
   file didn't scale at all to a larger project, taking about a minute to run the codegen task on a couple hundred files.  I guessed that 
   most of the time was being spent in the <code><a href="http://nant.sourceforge.net/release/latest/help/tasks/exec.html">exec</a></code> task, 
   which was instantiating the python interpreter, and that just seemed like a lot of overhead.  Lucky for me, 
   <a href="http://www.nedbatchelder.com/">Ned</a> is a smart guy, and one of <a href="http://www.nedbatchelder.com/code/cog/">Cog</a>'s options is
   to take a file containing a list of files to process.  So, now I can iterate over my project, make a text file (fileList.txt) containing the path to each file
   I want to run the codegen for, and then pass that fileList.txt to Cog at the end, only having to exec python once.  That reduced the build time from 
   64.7s to 3.2s.  Not to shabby for 10 minutes worth of work.<br /><br />
   Here's the updated <code>codegen</code> nant target.  The rest of the build file remains the same.
   <pre class="Code">
&lt;target name="codegen"&gt;
   
   &lt;!-- if there's an old one, delete it.--&gt;
   &lt;delete file="fileList.txt" if="${file::exists('fileList.txt')}"/&gt;      
   
   &lt;!-- generate the new file list --&gt;
   &lt;foreach item="File" property="filename"&gt; 
      &lt;in&gt; 
         &lt;items&gt;
            &lt;include name="**.cs" /&gt;
            &lt;include name="**.js" /&gt;
            &lt;include name="**.xul" /&gt;
         &lt;/items&gt; 
      &lt;/in&gt; 
      &lt;do&gt; 
         &lt;echo file="fileList.txt" message="${filename}" append="true"/&gt;
      &lt;/do&gt; 
   &lt;/foreach&gt;
   
   &lt;!-- pass the file list to Cog --&gt;
   &lt;exec program="python"&gt;
            &lt;arg value="cog.py" /&gt;
            &lt;arg value="-r" /&gt;
            &lt;arg value="@fileList.txt" /&gt;
   &lt;/exec&gt;
   
   &lt;!-- clean up --&gt;
   &lt;delete file="fileList.txt" failonerror="true"/&gt;
&lt;/target&gt;   </pre>
I'm digging into this stuff in earnest starting this week, so I'll post again when I find the next naive mistake.<img src ="http://blogs.acceleration.net/ryan/aggbug/637.aspx" width = "1" height = "1" /></body></item><item><dc:creator>Ryan</dc:creator><title>Solution to Python path problems</title><link>http://blogs.acceleration.net/ryan/archive/2005/02/09/632.aspx</link><pubDate>Wed, 09 Feb 2005 15:57:00 GMT</pubDate><guid>http://blogs.acceleration.net/ryan/archive/2005/02/09/632.aspx</guid><description>An obstacle to centralizing code-generation routines (for use with &lt;a href="http://www.nedbatchelder.com/code/cog/"&gt;COG&lt;/a&gt; or otherwise) is the
   python path.  First of all, if you're not familiar with them, check out my previous post about 
   &lt;a href="http://blogs.acceleration.net/ryan/archive/2005/01/10/472.aspx"&gt;python packages.&lt;/a&gt;

   &lt;h2&gt;The problem:&lt;/h2&gt;
   When running a statement like &lt;code&gt;import ADW&lt;/code&gt;, the Python interpreter looks for a file named "ADW.py", or a package 
   named "ADW" in the &lt;code&gt;sys.path&lt;/code&gt;.  From the python &lt;a href="http://www.python.org/doc/current/lib/module-sys.html"&gt;&lt;code&gt;sys&lt;/code&gt; module docs:&lt;/a&gt;
   &lt;blockquote&gt;
&lt;dl&gt;&lt;dt&gt;&lt;b&gt;&lt;tt id="l2h-359" xml:id="l2h-359"&gt;path&lt;/tt&gt;&lt;/b&gt;&lt;/dt&gt;
&lt;dd&gt;
&lt;a id="l2h-360" xml:id="l2h-360"&gt;&lt;/a&gt;  A list of strings that specifies the search path for modules.
  Initialized from the environment variable &lt;a class="envvar" id="l2h-386" xml:id="l2h-386"&gt;PYTHONPATH&lt;/a&gt;, plus an
  installation-dependent default.

&lt;p&gt;
As initialized upon program startup,
  the first item of this list, &lt;code&gt;path[0]&lt;/code&gt;, is the directory
  containing the script that was used to invoke the Python
  interpreter.  If the script directory is not available (e.g.  if the
  interpreter is invoked interactively or if the script is read from
  standard input), &lt;code&gt;path[0]&lt;/code&gt; is the empty string, which directs
  Python to search modules in the current directory first.  Notice
  that the script directory is inserted &lt;em&gt;before&lt;/em&gt; the entries
  inserted as a result of &lt;a class="envvar" id="l2h-387" xml:id="l2h-387"&gt;PYTHONPATH&lt;/a&gt;.

&lt;/p&gt;&lt;p&gt;
A program is free to modify this list for its own purposes.

&lt;/p&gt;&lt;p&gt;

&lt;span class="versionnote"&gt;Changed in version 2.3:
Unicode strings are no longer ignored.&lt;/span&gt;

&lt;/p&gt;&lt;/dd&gt;&lt;/dl&gt;
   &lt;/blockquote&gt;
   So, to have one group of python files used from different directories, we could manually append to &lt;code&gt;sys.path&lt;/code&gt;, to be sure that no matter what
   project we work on, our set of python packages is in scope, but this gets very messy.  We don't want to add 
   &lt;code&gt;sys.path.append('C:\\Documents and Settings\\etc')&lt;/code&gt; to every project.  Hard-coding absolute paths will complicate multiple people working on
   the python modules.
   
   &lt;h2&gt;The solution:&lt;/h2&gt;
   Python has a directory in its install root called &lt;code&gt;libs/site-packages&lt;/code&gt;.  This directory is always in the &lt;code&gt;sys.path&lt;/code&gt;, and it is 
   intended as a place for third-party packages to be installed on a system.  &lt;a href="http://spambayes.sourceforge.net/"&gt;SpamBayes&lt;/a&gt; installs 
   there, as well as a few others.  Any packages in here are always importable.  For more information check out the Python Enhancement Proposal (PEP)
   describing &lt;a href="http://www.python.org/peps/pep-0250.html"&gt;&lt;code&gt;site-packages&lt;/code&gt;&lt;/a&gt;.
   
   &lt;h2&gt;How we'll use it:&lt;/h2&gt;
   The desired configuration is to have the Visual Studio project containing all the python files reside in a 
   &lt;code&gt;libs/site-packages&lt;/code&gt; subdirectory.  That way, we can include that project in any other solution, and everything just works.  To 
   accomplish that, get the python solution from source control to the &lt;code&gt;libs/site-packages&lt;/code&gt; dir.  Since the project is stored a 
   directory lower than the solution, it works out the way we want.&lt;img src ="http://blogs.acceleration.net/ryan/aggbug/632.aspx" width = "1" height = "1" /&gt;</description><body xmlns="http://www.w3.org/1999/xhtml">An obstacle to centralizing code-generation routines (for use with <a href="http://www.nedbatchelder.com/code/cog/">COG</a> or otherwise) is the
   python path.  First of all, if you're not familiar with them, check out my previous post about 
   <a href="http://blogs.acceleration.net/ryan/archive/2005/01/10/472.aspx">python packages.</a>

   <h2>The problem:</h2>
   When running a statement like <code>import ADW</code>, the Python interpreter looks for a file named "ADW.py", or a package 
   named "ADW" in the <code>sys.path</code>.  From the python <a href="http://www.python.org/doc/current/lib/module-sys.html"><code>sys</code> module docs:</a>
   <blockquote>
<dl><dt><b><tt id="l2h-359" xml:id="l2h-359">path</tt></b></dt>
<dd>
<a id="l2h-360" xml:id="l2h-360"></a>  A list of strings that specifies the search path for modules.
  Initialized from the environment variable <a class="envvar" id="l2h-386" xml:id="l2h-386">PYTHONPATH</a>, plus an
  installation-dependent default.

<p>
As initialized upon program startup,
  the first item of this list, <code>path[0]</code>, is the directory
  containing the script that was used to invoke the Python
  interpreter.  If the script directory is not available (e.g.  if the
  interpreter is invoked interactively or if the script is read from
  standard input), <code>path[0]</code> is the empty string, which directs
  Python to search modules in the current directory first.  Notice
  that the script directory is inserted <em>before</em> the entries
  inserted as a result of <a class="envvar" id="l2h-387" xml:id="l2h-387">PYTHONPATH</a>.

</p><p>
A program is free to modify this list for its own purposes.

</p><p>

<span class="versionnote">Changed in version 2.3:
Unicode strings are no longer ignored.</span>

</p></dd></dl>
   </blockquote>
   So, to have one group of python files used from different directories, we could manually append to <code>sys.path</code>, to be sure that no matter what
   project we work on, our set of python packages is in scope, but this gets very messy.  We don't want to add 
   <code>sys.path.append('C:\\Documents and Settings\\etc')</code> to every project.  Hard-coding absolute paths will complicate multiple people working on
   the python modules.
   
   <h2>The solution:</h2>
   Python has a directory in its install root called <code>libs/site-packages</code>.  This directory is always in the <code>sys.path</code>, and it is 
   intended as a place for third-party packages to be installed on a system.  <a href="http://spambayes.sourceforge.net/">SpamBayes</a> installs 
   there, as well as a few others.  Any packages in here are always importable.  For more information check out the Python Enhancement Proposal (PEP)
   describing <a href="http://www.python.org/peps/pep-0250.html"><code>site-packages</code></a>.
   
   <h2>How we'll use it:</h2>
   The desired configuration is to have the Visual Studio project containing all the python files reside in a 
   <code>libs/site-packages</code> subdirectory.  That way, we can include that project in any other solution, and everything just works.  To 
   accomplish that, get the python solution from source control to the <code>libs/site-packages</code> dir.  Since the project is stored a 
   directory lower than the solution, it works out the way we want.<img src ="http://blogs.acceleration.net/ryan/aggbug/632.aspx" width = "1" height = "1" /></body></item><item><dc:creator>Ryan</dc:creator><title>Code Generation with Python, Cog, and Nant</title><link>http://blogs.acceleration.net/ryan/archive/2005/01/25/578.aspx</link><pubDate>Tue, 25 Jan 2005 16:14:00 GMT</pubDate><guid>http://blogs.acceleration.net/ryan/archive/2005/01/25/578.aspx</guid><description>I posted an article about how I do &lt;a href="http://blogs.acceleration.net/ryan/articles/577.aspx"&gt;Code Generation with Python, Cog, and Nant&lt;/a&gt;.  
&lt;br /&gt;
Check it out.&lt;img src ="http://blogs.acceleration.net/ryan/aggbug/578.aspx" width = "1" height = "1" /&gt;</description><body xmlns="http://www.w3.org/1999/xhtml">I posted an article about how I do <a href="http://blogs.acceleration.net/ryan/articles/577.aspx">Code Generation with Python, Cog, and Nant</a>.  
<br />
Check it out.<img src ="http://blogs.acceleration.net/ryan/aggbug/578.aspx" width = "1" height = "1" /></body></item><item><dc:creator>Ryan</dc:creator><title>Python packages</title><link>http://blogs.acceleration.net/ryan/archive/2005/01/10/472.aspx</link><pubDate>Mon, 10 Jan 2005 19:04:00 GMT</pubDate><guid>http://blogs.acceleration.net/ryan/archive/2005/01/10/472.aspx</guid><description>So we're using Python to do the next version of our code generator, and so I've been learning a hell of a
   lot about this language recently.  Notably, I've been fighting with a good way to reference things from different files.
   Coming from the C# world, where everything has its own type, specifying what you wanted to use wasn't 
   difficult, but it was often very redundant.  Specifying what you want in Python is a little looser.  Here's the evolution
   of ways I found.
   &lt;ol&gt;
      &lt;li&gt;&lt;b&gt;Putting everything in the path and praying to the gods of naming conflicts&lt;/b&gt;&lt;br /&gt;
      In python, you have a &lt;code&gt;sys.path&lt;/code&gt;, which is analogous to your system PATH variables.  Python will search
      the &lt;code&gt;sys.path&lt;/code&gt; variable for the class or variable, just like running "cmd" on a DOS prompt searches 
      the %PATH% until it finds cmd.exe.  So, with that in mind, I put this at the top of every file:
   &lt;pre class="Code"&gt;
import sys
sys.path.append('./')
sys.path.append('../')
   &lt;/pre&gt;
      That way, things are always visible.  Of course, after importing a few files, the &lt;code&gt;sys.path&lt;/code&gt; had multiple
      entries for './' and '../', which seemed really dirty.  Also, we're moving to this language to get more
      dynamism, and copy/pasting the same line of code everywhere was kinda defeating the purpose.  Also, if I ever wanted to use
      the same name in two places, it would have a conflict and die.  So, I
      hit up some mailing lists and documentation, and came up with a slightly safer way.
      &lt;/li&gt;
      &lt;li&gt;&lt;b&gt;Use a &lt;code&gt;__init__.py&lt;/code&gt; to automatically add all the paths&lt;/b&gt;&lt;br /&gt;
      You can put a &lt;code&gt;__init__.py&lt;/code&gt; in a directory, which makes that directory a &lt;a href="http://www.python.org/doc/current/tut/node8.html#SECTION008400000000000000000"&gt;package&lt;/a&gt;.
      In there I had a function that added a directory to &lt;code&gt;sys.path&lt;/code&gt;, first checking if it existed already, so I 
      wouldn't get any messy duplicates.  This proved unreliable, and worked depending on where I started the 
      python interpreter from.  This also required copy/pasting about to ensure that all subdirectories would
      include everything properly.  Still too much of a mess, so sent a &lt;a href="http://mail.python.org/pipermail/tutor/2005-January/034666.html"&gt;request&lt;/a&gt; 
      to the &lt;a href="http://mail.python.org/mailman/listinfo/tutor"&gt;python tutor mailing list&lt;/a&gt;.  After some 
      helpful replies and sitting up with &lt;a title="Nathan's blog" href="http://blogs.acceleration.net/birdman/"&gt;Nathan&lt;/a&gt; methodically testing things, we found something clean and promptly
      got drunk.
      &lt;/li&gt;
      &lt;li&gt;&lt;b&gt;Use &lt;code&gt;__init__.py&lt;/code&gt; files and the &lt;code&gt;__all__&lt;/code&gt; variable to specify the contents of a package, and import using the full dotted module name.&lt;/b&gt;&lt;br /&gt;
      By sticking a &lt;code&gt;__init__.py&lt;/code&gt; in each directory, that enables me to use the path to the file as a way to identify it.
      So, with the file structure:
      &lt;ul&gt;
         &lt;li&gt;/One
            &lt;ul&gt;
               &lt;li&gt;__init__.py&lt;/li&gt;
               &lt;li&gt;A.py&lt;/li&gt;
            &lt;/ul&gt;
         &lt;/li&gt;
         &lt;li&gt;/Two
            &lt;ul&gt;
               &lt;li&gt;__init__.py&lt;/li&gt;
               &lt;li&gt;B.py&lt;/li&gt;
            &lt;/ul&gt;
         &lt;/li&gt;
      &lt;/ul&gt;
      In file A.py, I can reference things in B.py by saying:
      &lt;pre class="Code"&gt;import Two.B&lt;/pre&gt;
      In a nutshell, we need to walk the namespace hierarchy and import each file, so we can
      define an &lt;code&gt;__all__&lt;/code&gt; in the &lt;code&gt;__init__.py&lt;/code&gt; file, and use that for our reflective needs.
      See the python docs for more info on &lt;a href="http://www.python.org/doc/current/tut/node8.html#SECTION008410000000000000000"&gt;&lt;code&gt;__all__&lt;/code&gt;&lt;/a&gt;.      
      &lt;/li&gt;
   &lt;/ol&gt;
   So, that is that, and now I'm ready to get back to actually programming.  Woo!&lt;img src ="http://blogs.acceleration.net/ryan/aggbug/472.aspx" width = "1" height = "1" /&gt;</description><body xmlns="http://www.w3.org/1999/xhtml">So we're using Python to do the next version of our code generator, and so I've been learning a hell of a
   lot about this language recently.  Notably, I've been fighting with a good way to reference things from different files.
   Coming from the C# world, where everything has its own type, specifying what you wanted to use wasn't 
   difficult, but it was often very redundant.  Specifying what you want in Python is a little looser.  Here's the evolution
   of ways I found.
   <ol>
      <li><b>Putting everything in the path and praying to the gods of naming conflicts</b><br />
      In python, you have a <code>sys.path</code>, which is analogous to your system PATH variables.  Python will search
      the <code>sys.path</code> variable for the class or variable, just like running "cmd" on a DOS prompt searches 
      the %PATH% until it finds cmd.exe.  So, with that in mind, I put this at the top of every file:
   <pre class="Code">
import sys
sys.path.append('./')
sys.path.append('../')
   </pre>
      That way, things are always visible.  Of course, after importing a few files, the <code>sys.path</code> had multiple
      entries for './' and '../', which seemed really dirty.  Also, we're moving to this language to get more
      dynamism, and copy/pasting the same line of code everywhere was kinda defeating the purpose.  Also, if I ever wanted to use
      the same name in two places, it would have a conflict and die.  So, I
      hit up some mailing lists and documentation, and came up with a slightly safer way.
      </li>
      <li><b>Use a <code>__init__.py</code> to automatically add all the paths</b><br />
      You can put a <code>__init__.py</code> in a directory, which makes that directory a <a href="http://www.python.org/doc/current/tut/node8.html#SECTION008400000000000000000">package</a>.
      In there I had a function that added a directory to <code>sys.path</code>, first checking if it existed already, so I 
      wouldn't get any messy duplicates.  This proved unreliable, and worked depending on where I started the 
      python interpreter from.  This also required copy/pasting about to ensure that all subdirectories would
      include everything properly.  Still too much of a mess, so sent a <a href="http://mail.python.org/pipermail/tutor/2005-January/034666.html">request</a> 
      to the <a href="http://mail.python.org/mailman/listinfo/tutor">python tutor mailing list</a>.  After some 
      helpful replies and sitting up with <a title="Nathan's blog" href="http://blogs.acceleration.net/birdman/">Nathan</a> methodically testing things, we found something clean and promptly
      got drunk.
      </li>
      <li><b>Use <code>__init__.py</code> files and the <code>__all__</code> variable to specify the contents of a package, and import using the full dotted module name.</b><br />
      By sticking a <code>__init__.py</code> in each directory, that enables me to use the path to the file as a way to identify it.
      So, with the file structure:
      <ul>
         <li>/One
            <ul>
               <li>__init__.py</li>
               <li>A.py</li>
            </ul>
         </li>
         <li>/Two
            <ul>
               <li>__init__.py</li>
               <li>B.py</li>
            </ul>
         </li>
      </ul>
      In file A.py, I can reference things in B.py by saying:
      <pre class="Code">import Two.B</pre>
      In a nutshell, we need to walk the namespace hierarchy and import each file, so we can
      define an <code>__all__</code> in the <code>__init__.py</code> file, and use that for our reflective needs.
      See the python docs for more info on <a href="http://www.python.org/doc/current/tut/node8.html#SECTION008410000000000000000"><code>__all__</code></a>.      
      </li>
   </ol>
   So, that is that, and now I'm ready to get back to actually programming.  Woo!<img src ="http://blogs.acceleration.net/ryan/aggbug/472.aspx" width = "1" height = "1" /></body></item><item><dc:creator>Ryan</dc:creator><title>Python's lambda considered completely useless?</title><link>http://blogs.acceleration.net/ryan/archive/2005/01/03/449.aspx</link><pubDate>Mon, 03 Jan 2005 15:46:00 GMT</pubDate><guid>http://blogs.acceleration.net/ryan/archive/2005/01/03/449.aspx</guid><description>We're starting to use &lt;a href="http://www.python.org"&gt;Python&lt;/a&gt; in earnest now, for some prime development purposes, and
    I'm looking into usages of the &lt;a href="http://docs.python.org/tut/node6.html#SECTION006750000000000000000"&gt;&lt;code&gt;lambda&lt;code&gt;&lt;/code&gt;&lt;/code&gt;&lt;/a&gt; keyword.
In short, &lt;code&gt;lambda&lt;/code&gt; is there to let you define anonymous functions, basically a shorthand for making little helpers to simplify your code.
So, you can say something like:
&lt;pre class="Code"&gt;
&amp;gt;&amp;gt;&amp;gt;def doStuff():
      sumSquares = lambda x,y: x*x + y*y
      print sumSquares(1,1)
&amp;gt;&amp;gt;&amp;gt;doStuff()
2
&lt;/pre&gt;
The problem is I want my helper functions to do more than return a value, and Python doesn't think I should be able to do that.  Specifically,
I want to write a little helper to union two &lt;a href="http://docs.python.org/lib/typesmapping.html"&gt;dictionaries&lt;/a&gt;.  I wanted to do this:
&lt;pre class="Code"&gt;
&amp;gt;&amp;gt;&amp;gt;def addAttributes(h1, h2):
      append = lambda k,v: h1[k] = v
      [append(k,v) for k,v in h2.items()]
&lt;/pre&gt;
Unfortunately, I "&lt;code&gt;can't assign to lambda&lt;/code&gt;".  That might be for the best, as a singular "addAttribute" function isn't a &lt;i&gt;bad&lt;/i&gt; thing to add,
but I don't like a language telling me "No" unless it's Prolog.  Naturally, &lt;a title="Nathan's blog" href="http://blogs.acceleration.net/birdman/"&gt;Nathan&lt;/a&gt; is quick to point out that this can be done easily in Lisp.&lt;img src ="http://blogs.acceleration.net/ryan/aggbug/449.aspx" width = "1" height = "1" /&gt;</description><body xmlns="http://www.w3.org/1999/xhtml">We're starting to use <a href="http://www.python.org">Python</a> in earnest now, for some prime development purposes, and
    I'm looking into usages of the <a href="http://docs.python.org/tut/node6.html#SECTION006750000000000000000"><code>lambda<code></code></code></a> keyword.
In short, <code>lambda</code> is there to let you define anonymous functions, basically a shorthand for making little helpers to simplify your code.
So, you can say something like:
<pre class="Code">
&gt;&gt;&gt;def doStuff():
      sumSquares = lambda x,y: x*x + y*y
      print sumSquares(1,1)
&gt;&gt;&gt;doStuff()
2
</pre>
The problem is I want my helper functions to do more than return a value, and Python doesn't think I should be able to do that.  Specifically,
I want to write a little helper to union two <a href="http://docs.python.org/lib/typesmapping.html">dictionaries</a>.  I wanted to do this:
<pre class="Code">
&gt;&gt;&gt;def addAttributes(h1, h2):
      append = lambda k,v: h1[k] = v
      [append(k,v) for k,v in h2.items()]
</pre>
Unfortunately, I "<code>can't assign to lambda</code>".  That might be for the best, as a singular "addAttribute" function isn't a <i>bad</i> thing to add,
but I don't like a language telling me "No" unless it's Prolog.  Naturally, <a title="Nathan's blog" href="http://blogs.acceleration.net/birdman/">Nathan</a> is quick to point out that this can be done easily in Lisp.<img src ="http://blogs.acceleration.net/ryan/aggbug/449.aspx" width = "1" height = "1" /></body></item></channel></rss>