<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: More Python and C# idioms: Finding the difference between two lists</title>
	<atom:link href="http://blog.jonudell.net/2009/10/22/more-python-and-c-idioms-finding-the-difference-between-two-list/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.jonudell.net/2009/10/22/more-python-and-c-idioms-finding-the-difference-between-two-list/</link>
	<description>Strategies for Internet citizens</description>
	<lastBuildDate>Mon, 13 Feb 2012 06:40:07 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: csharptalk.com</title>
		<link>http://blog.jonudell.net/2009/10/22/more-python-and-c-idioms-finding-the-difference-between-two-list/#comment-130587</link>
		<dc:creator><![CDATA[csharptalk.com]]></dc:creator>
		<pubDate>Tue, 27 Oct 2009 12:58:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.jonudell.net/?p=1976#comment-130587</guid>
		<description><![CDATA[quite good article.

thanks
csharptalk.com]]></description>
		<content:encoded><![CDATA[<p>quite good article.</p>
<p>thanks<br />
csharptalk.com</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Chermside</title>
		<link>http://blog.jonudell.net/2009/10/22/more-python-and-c-idioms-finding-the-difference-between-two-list/#comment-130581</link>
		<dc:creator><![CDATA[Michael Chermside]]></dc:creator>
		<pubDate>Mon, 26 Oct 2009 23:43:46 +0000</pubDate>
		<guid isPermaLink="false">http://blog.jonudell.net/?p=1976#comment-130581</guid>
		<description><![CDATA[I like the convenience of C#&#039;s &quot;.Except&quot; - someone in a hurry might not think of the sets immediately, but would certainly bother to look at the list&#039;s methods.

Of course, this only works because you&#039;re using the built-in list type which has rich features. The python approach works on pretty much anything you can iterate over, which is handy for those of us who sometimes use OTHER data structures besides the built-in ones.]]></description>
		<content:encoded><![CDATA[<p>I like the convenience of C#&#8217;s &#8220;.Except&#8221; &#8211; someone in a hurry might not think of the sets immediately, but would certainly bother to look at the list&#8217;s methods.</p>
<p>Of course, this only works because you&#8217;re using the built-in list type which has rich features. The python approach works on pretty much anything you can iterate over, which is handy for those of us who sometimes use OTHER data structures besides the built-in ones.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Amit Patel</title>
		<link>http://blog.jonudell.net/2009/10/22/more-python-and-c-idioms-finding-the-difference-between-two-list/#comment-130560</link>
		<dc:creator><![CDATA[Amit Patel]]></dc:creator>
		<pubDate>Sun, 25 Oct 2009 18:58:42 +0000</pubDate>
		<guid isPermaLink="false">http://blog.jonudell.net/?p=1976#comment-130560</guid>
		<description><![CDATA[The OO syntax (noun.verb) is great when there&#039;s one noun. When there are zero or two or more it doesn&#039;t work as nicely, and the functional syntax (verb (noun, noun, noun)) works better. When there&#039;s just one noun, you can dispatch on the type of that, which also means you can control namespaces.

For dispatching the alternative not limited to one noun is multimethods. They don&#039;t seem to take off.  For namespaces the alternative isn&#039;t explored as much, but Koenig lookup in C++ is a stab at it.

I think we should also look at sentences in spoken languages. We tend to always have a verb, and then we have some nouns. So the functional approach seems like a better match. However at least in English the verb often occurs after the subject, so noun.verb is a better order.

Noun.verb also gives better completion in IDEs, because the noun is drawn from a limited namespace (locals and globals) and then the verb can also be drawn from a limited namespace (only the methods defined on the type of the noun).

As far as my preference, I am not a big fan of uniformity. I like things to look different syntactically so that I can easily distinguish them when scanning code. I don&#039;t have a strong opinion for set difference though.]]></description>
		<content:encoded><![CDATA[<p>The OO syntax (noun.verb) is great when there&#8217;s one noun. When there are zero or two or more it doesn&#8217;t work as nicely, and the functional syntax (verb (noun, noun, noun)) works better. When there&#8217;s just one noun, you can dispatch on the type of that, which also means you can control namespaces.</p>
<p>For dispatching the alternative not limited to one noun is multimethods. They don&#8217;t seem to take off.  For namespaces the alternative isn&#8217;t explored as much, but Koenig lookup in C++ is a stab at it.</p>
<p>I think we should also look at sentences in spoken languages. We tend to always have a verb, and then we have some nouns. So the functional approach seems like a better match. However at least in English the verb often occurs after the subject, so noun.verb is a better order.</p>
<p>Noun.verb also gives better completion in IDEs, because the noun is drawn from a limited namespace (locals and globals) and then the verb can also be drawn from a limited namespace (only the methods defined on the type of the noun).</p>
<p>As far as my preference, I am not a big fan of uniformity. I like things to look different syntactically so that I can easily distinguish them when scanning code. I don&#8217;t have a strong opinion for set difference though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon Udell</title>
		<link>http://blog.jonudell.net/2009/10/22/more-python-and-c-idioms-finding-the-difference-between-two-list/#comment-130427</link>
		<dc:creator><![CDATA[Jon Udell]]></dc:creator>
		<pubDate>Fri, 23 Oct 2009 00:30:53 +0000</pubDate>
		<guid isPermaLink="false">http://blog.jonudell.net/?p=1976#comment-130427</guid>
		<description><![CDATA[&gt; set(L1).difference(L2)

Oh, so there&#039;s the noun-verb pattern. Thanks!]]></description>
		<content:encoded><![CDATA[<p>&gt; set(L1).difference(L2)</p>
<p>Oh, so there&#8217;s the noun-verb pattern. Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David W</title>
		<link>http://blog.jonudell.net/2009/10/22/more-python-and-c-idioms-finding-the-difference-between-two-list/#comment-130426</link>
		<dc:creator><![CDATA[David W]]></dc:creator>
		<pubDate>Fri, 23 Oct 2009 00:13:43 +0000</pubDate>
		<guid isPermaLink="false">http://blog.jonudell.net/?p=1976#comment-130426</guid>
		<description><![CDATA[Hey Jon,

Python sets are wonderful, but they can be a little deceiving, particularly in the memory usage department. They also require that contained objects are immutable (having meaningful order and hash values).

For these reasons, and especially for larger collections that are approaching memory limits, the merge algorithm is a great alternative. http://pastie.org/666041 is an implementation I use for diffing large lists of integers in a Google AppEngine application (memory limit ~60mb). This algorithm only requires memory to store the differences, rather than also including intermediary sets.

Another useful set-related trick is, if you use set&#039;s methods rather than its operator overloads, you may directly pass any sequence as the right operand without first converting it to a set:

    set(L1) - set(L2)

Becomes:

    set(L1).difference(L2)]]></description>
		<content:encoded><![CDATA[<p>Hey Jon,</p>
<p>Python sets are wonderful, but they can be a little deceiving, particularly in the memory usage department. They also require that contained objects are immutable (having meaningful order and hash values).</p>
<p>For these reasons, and especially for larger collections that are approaching memory limits, the merge algorithm is a great alternative. <a href="http://pastie.org/666041" rel="nofollow">http://pastie.org/666041</a> is an implementation I use for diffing large lists of integers in a Google AppEngine application (memory limit ~60mb). This algorithm only requires memory to store the differences, rather than also including intermediary sets.</p>
<p>Another useful set-related trick is, if you use set&#8217;s methods rather than its operator overloads, you may directly pass any sequence as the right operand without first converting it to a set:</p>
<p>    set(L1) &#8211; set(L2)</p>
<p>Becomes:</p>
<p>    set(L1).difference(L2)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

