In the real world, I'm not sure that there ever is a truly clean statement / <div>expression divide. </div><div><br></div><div><font face="courier new, monospace">    server = DataServe(...)</font></div><div><font face="courier new, monospace">    server.start()</font></div><div><br></div><div>vies with </div><div><br></div><div><font face="courier new, monospace">    server = DataServe(...).start()</font></div><div><br></div><div>or</div><div><br></div><div><font face="courier new, monospace">    server = DataServe(..., start=True)</font></div><div><br></div><div>And while there are lot of places where Python tries to make something </div><div>very a statement rather than an expression (e.g. <font face="courier new, monospace">print</font>, <font face="courier new, monospace">import</font>, <font face="courier new, monospace">raise</font>, or </div><div><font face="courier new, monospace">assert</font>), one doesn't have to go very far to find variations on these that are</div><div>functional. py3 itself changed its game on <font face="courier new, monospace">print</font>.</div><div><br></div><div>I myself do not find modest uses of fluency any less clear or explicit, and </div><div>I believe it can improve the clarity of some logically-combined activities.</div><div>But I'd certainly agree that the aggressive functional chaining you can find </div><div>highly functional languages, or in JS, which I'll caricature as:</div><div><br></div><div>   <font face="courier new, monospace"> d.find(...).filter(...).more(...).last().render(</font>)</div><div><br></div><div>can be pretty off-putting and opaque. Through a few functional</div><div>for-loops in there, as JS often does, and it's downright ugly.</div><div><br></div><div>I don't want to take the blocks and closures discussion off-track; I'm not </div><div>advocating hyper-fluency; and I freely admit that a language's omissions </div><div>and constraints can be easily as important as the features it provides. </div><div><br></div><div>I'm all about optimizing the macro result, so if having a few more vertical</div><div>lines is the constraint that makes the total code more comprehensible, </div><div>c'est la vie.</div><div><br></div><div>But it does seem, to me at least, that there's a connection with some of the </div><div>issues people bang into trying to specify block context and the fact that</div><div>while Python constructors return a object than can be directly used, that</div><div>very few of the update methods do. </div><div><br></div><div><br>On Monday, May 13, 2013 5:07:03 PM UTC-4, Andrew Barnert wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On May 13, 2013, at 13:19, Jonathan Eunice <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="8OYNO99mXx4J">jonatha...@gmail.com</a>> wrote:
<br>
<br>> That many Python functions don't produce useful values makes 
<br>> it difficult or impossible to do "chained" or "fluent" operations a la 
<br>> JavaScript or Perl. 
<br>
<br>Fluency and a clean expression/statement divide are almost directly contrary goals.
<br>
<br>Similarly, reducing "vertical" code and making all structure explicit are almost directly contrary goals.
<br>
<br>So;
<br>
<br>> I love that Python avoids "expression soup" and long run-on 
<br>> invocations, but the lack of appreciable support for "fluency" or even
<br>> a smidgeon of functional style seems to regularly "verticalize" 
<br>> Python code
<br>
<br>If you made Python fluent, you would allow, and maybe even encourage, JS-style "expression soup". It's a tradeoff, and I think Python made the right choice here.
<br>
<br>I've got a lot of logic that I migrate back and forth between Python and JS, and it's definitely true that a 3-line JS function often becomes a 5-line Python function and vice versa. But the Python function is nevertheless usually faster to read, so I don't think this is a problem.
<br>
<br>> , with several lines required do common things, such as 
<br>> fully construct / initialize / setup an object.  
<br>
<br>Often the answer to that is that the right API for a Python class isn't the same as the right API for a similar JS prototype. For example, because pythonic style makes much more use of exceptions than typical JS style, you don't need multistage initialization nearly as often.
<br>
<br>______________________________<wbr>_________________
<br>Python-ideas mailing list
<br><a href="javascript:" target="_blank" gdf-obfuscated-mailto="8OYNO99mXx4J">Python...@python.org</a>
<br><a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/<wbr>mailman/listinfo/python-ideas</a>
<br></blockquote></div>