<story><title>Python Idioms [pdf]</title><url>http://safehammad.com/downloads/python-idioms-2014-01-16.pdf</url></story><parent_chain><item><author>crazygringo</author><text>Interesting philosophical points.&lt;p&gt;To me personally, testing for &amp;#x27;truthy&amp;#x27; and &amp;#x27;falsy&amp;#x27; values, or relying on exceptions rather than checking values in advance, feels like sloppy and imprecise programming.&lt;p&gt;A string being empty or not, or an array having items or not, or a boolean being true or false, are all qualitatively totally different things to me -- and just because Python &lt;i&gt;can&lt;/i&gt; treat them the same, doesn&amp;#x27;t mean a programmer &lt;i&gt;should&lt;/i&gt; take advantage of that fact. Sometimes it&amp;#x27;s possible to &lt;i&gt;over&lt;/i&gt;-simplify things in a way that obfuscates instead of clarifying.&lt;p&gt;When I read:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    if name and pets and owners
&lt;/code&gt;&lt;/pre&gt;
I have no intuitive idea of what that means, of what&amp;#x27;s going on in the program. When I read&lt;p&gt;&lt;pre&gt;&lt;code&gt;    if name != &amp;#x27;&amp;#x27; and len(pets) &amp;gt; 0 and owners != {}
&lt;/code&gt;&lt;/pre&gt;
I understand it exactly.&lt;p&gt;But by this point, I&amp;#x27;ve come to understand that, for a lot of people, it seems to be the opposite. It seems to be more of a philosophical difference, not right&amp;#x2F;wrong.</text></item></parent_chain><comment><author>bcoates</author><text>It&amp;#x27;s a dynamic-typing thing. In some hypothetical static-strong-non-duck version of Python,&lt;p&gt;&lt;pre&gt;&lt;code&gt;  if name != &amp;#x27;&amp;#x27; and len(pets) &amp;gt; 0 and owners != {}
&lt;/code&gt;&lt;/pre&gt;
would tell you that name is a non-empty string, pets has values, and owners is a non-empty dict (except it doesn&amp;#x27;t work, as pdonis noticed).&lt;p&gt;But Python allows immoral implicit conversions, so that&amp;#x27;s not what that line means! If name is a function, pets is the value &amp;#x27;7&amp;#x27; and owners is a list, the test passes.&lt;p&gt;&lt;pre&gt;&lt;code&gt;  if name and pets and owners
&lt;/code&gt;&lt;/pre&gt;
Would pass as well, but it has the advantage of not implying it does more than it does: all you can infer from the test passing is that none of name,pets,owners are special falsy values.&lt;p&gt;If you actually wanted to test what the longer line is implying, you&amp;#x27;d write something like&lt;p&gt;&lt;pre&gt;&lt;code&gt;  if isinstance(name, str) and isinstance(pets, list) and isinstance(owners, set) and name and pets and owners
&lt;/code&gt;&lt;/pre&gt;
(don&amp;#x27;t do this, it violates duck-typing and LBYL)</text></comment>
<story><title>Python Idioms [pdf]</title><url>http://safehammad.com/downloads/python-idioms-2014-01-16.pdf</url></story><parent_chain><item><author>crazygringo</author><text>Interesting philosophical points.&lt;p&gt;To me personally, testing for &amp;#x27;truthy&amp;#x27; and &amp;#x27;falsy&amp;#x27; values, or relying on exceptions rather than checking values in advance, feels like sloppy and imprecise programming.&lt;p&gt;A string being empty or not, or an array having items or not, or a boolean being true or false, are all qualitatively totally different things to me -- and just because Python &lt;i&gt;can&lt;/i&gt; treat them the same, doesn&amp;#x27;t mean a programmer &lt;i&gt;should&lt;/i&gt; take advantage of that fact. Sometimes it&amp;#x27;s possible to &lt;i&gt;over&lt;/i&gt;-simplify things in a way that obfuscates instead of clarifying.&lt;p&gt;When I read:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    if name and pets and owners
&lt;/code&gt;&lt;/pre&gt;
I have no intuitive idea of what that means, of what&amp;#x27;s going on in the program. When I read&lt;p&gt;&lt;pre&gt;&lt;code&gt;    if name != &amp;#x27;&amp;#x27; and len(pets) &amp;gt; 0 and owners != {}
&lt;/code&gt;&lt;/pre&gt;
I understand it exactly.&lt;p&gt;But by this point, I&amp;#x27;ve come to understand that, for a lot of people, it seems to be the opposite. It seems to be more of a philosophical difference, not right&amp;#x2F;wrong.</text></item></parent_chain><comment><author>prawks</author><text>&amp;gt; it&amp;#x27;s possible to over-simplify things in a way that obfuscates instead of clarifying&lt;p&gt;While this is true, I think it&amp;#x27;s important to keep in mind that a big benefit of being able to handle a situation programatically in different ways is that you, as a programmer, are more able to accurately describe &lt;i&gt;intent&lt;/i&gt;.&lt;p&gt;For example, I think it&amp;#x27;s foolish to &lt;i&gt;always&lt;/i&gt; catch exceptions instead of checking beforehand (look-before-you-leap). However, being able to do either allows me to more accurately represent the intent of a statement. Blindly following rules is almost always sure to lead to poor decisions.&lt;p&gt;If I&amp;#x27;m retrieving an element from an array and I know that for the majority of possible application states there will be an element there, I can just access it, and handle an exception (because it&amp;#x27;s an &amp;quot;exceptional&amp;quot; case). However if I&amp;#x27;m expecting that it could go either way in typical circumstances, then I might more explicitly check the index in the array to illustrate my intent that yes, there are two distinct paths here and that is how the program&amp;#x27;s control flows naturally.&lt;p&gt;Of course all of these things are only worthwhile if the reader can see and interpret them as purposeful decisions rather than coincidence. Conveying that is something else entirely.</text></comment>