[Python-ideas] Anonymous blocks (again):

[Jonathan Eunice]

In the real world, I'm not sure that there ever is a truly clean statement 
/ 
expression divide. 

    server = DataServe(...)
    server.start()

vies with 

    server = DataServe(...).start()

or

    server = DataServe(..., start=True)

And while there are lot of places where Python tries to make something 
very a statement rather than an expression (e.g. print, import, raise, or 
assert), one doesn't have to go very far to find variations on these that 
are
functional. py3 itself changed its game on print.

I myself do not find modest uses of fluency any less clear or explicit, and 
I believe it can improve the clarity of some logically-combined activities.
But I'd certainly agree that the aggressive functional chaining you can 
find 
highly functional languages, or in JS, which I'll caricature as:

    d.find(...).filter(...).more(...).last().render()

can be pretty off-putting and opaque. Through a few functional
for-loops in there, as JS often does, and it's downright ugly.

I don't want to take the blocks and closures discussion off-track; I'm not 
advocating hyper-fluency; and I freely admit that a language's omissions 
and constraints can be easily as important as the features it provides. 

I'm all about optimizing the macro result, so if having a few more vertical
lines is the constraint that makes the total code more comprehensible, 
c'est la vie.

But it does seem, to me at least, that there's a connection with some of 
the 
issues people bang into trying to specify block context and the fact that
while Python constructors return a object than can be directly used, that
very few of the update methods do. 


On Monday, May 13, 2013 5:07:03 PM UTC-4, Andrew Barnert wrote:
>
> On May 13, 2013, at 13:19, Jonathan Eunice <jonatha... at gmail.com<javascript:>> 
> wrote: 
>
> > That many Python functions don't produce useful values makes 
> > it difficult or impossible to do "chained" or "fluent" operations a la 
> > JavaScript or Perl. 
>
> Fluency and a clean expression/statement divide are almost directly 
> contrary goals. 
>
> Similarly, reducing "vertical" code and making all structure explicit are 
> almost directly contrary goals. 
>
> So; 
>
> > I love that Python avoids "expression soup" and long run-on 
> > invocations, but the lack of appreciable support for "fluency" or even 
> > a smidgeon of functional style seems to regularly "verticalize" 
> > Python code 
>
> 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. 
>
> 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. 
>
> > , with several lines required do common things, such as 
> > fully construct / initialize / setup an object.   
>
> 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. 
>
> _______________________________________________ 
> Python-ideas mailing list 
> Python... at python.org <javascript:> 
> http://mail.python.org/mailman/listinfo/python-ideas 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130513/cc849898/attachment.html>