[Python-ideas] Anonymous blocks (again):

[Haoyi Li]

I do not think expression soup is particularly bad, it's just Javascript's
implementation (as usual) that is pretty borked. In Scala, expression
chaining lets you do some pretty nice things:

      memory.take(freePointer)
            .grouped(10)
            .map(_.fold("")(_+"\t"+_))
            .reduce(_+"\n"+_)


This code converts a flat array of ints into pretty 10-ints-per-row heap
dumps, and is probably nicer than most things you would write using for
loops and variables.

In general, method chaining is the same as having an implicit "this" object
that you are operating on without needing to specify it (since it gets
returned by each method). Apart from saving syntax (less tokens to write)
this also reduces the number of possible ways you can do things. I mean, if
you write this:

memory.take(freePointer)
memory.grouped(10)
memory.map(_.map(_+""))
memory.map(_.reduce(_+"\t"+_))
memory.reduce(_+"\n"+_)


It's about the same; but how many times have you seen code like this:

memory.take(freePointer)
// some comment
memory.grouped(10)
unrelatedthing.dostuff()
memory.map(_.map(_+""))
unrelatedthing.domorestuff()
/**
 * SOME BIG COMMENT
 * i am cow
 * hear me moo
 * i weight twice as much as you
 * and i look good on the barbecue
 */
do_stuff_with_cows()
memory.map(_.reduce(_+"\t"+_))
memory.reduce(_+"\n"+_)


Which makes it a huge pain to figure out what is going on with memory?
Method chaining *prevents* this sort of thing from happening in the first
place, which is really nice. Even if I try to avoid this, I haven't seen
any code base where this hasn't happened in various places, causing endless
headaches.


On Mon, May 13, 2013 at 9:36 PM, Steven D'Aprano <steve at pearwood.info>wrote:

> On 14/05/13 03:23, Juancarlo Añez wrote:
>
>> On Mon, May 13, 2013 at 11:58 AM, Terry Jan Reedy <tjreedy at udel.edu>
>> wrote:
>>
>>  I disagree that the above is unpythonic. In Python, functions are objects
>>> like everything else. Define them, pass them to functions, like anything
>>> else. 'Unpythonic' is treating functions as special, other than that they
>>> are called (have a call method).
>>>
>>
>>
>> I beg to disagree. Functions are objects in python, but they get
>> particular
>> treatment.
>>
>> You can do:
>>
>> def f():
>>      pass
>> x = f
>>
>>
>> But you can't do:
>>
>> x = def(): pass
>>
>
>
> That has nothing to do with *function objects*, and everything to do with
> the *keyword* def being a statement. If you avoid "def", you can do this:
>
> x = lambda: None
>
>
> or even this:
>
> from types import FunctionType
> x = FunctionType(code, globals, name, argdefs, closure)
>
>
> Creating functions in this way is not exactly convenient, but it is
> possible.
>
>
> There is a sense in which functions (and classes, and modules) are
> "different", not because Python chooses to treat them differently, but
> because they are inherently different. They are complex, almost free-form
> compound objects, and there is no "nice" syntax for creating them inside an
> expression. The closest Python comes to is lambda for functions, and that
> is limited to a single expression.
>
> But regardless of the difficulty of creating a function object, once you
> have one, it is a first class object. Anything you can do with any other
> object, you can do with a function object. I'm with Terry on this: the code
> snippet you gave, where a function object is passed to another function, is
> a standard Python idiom and perfectly pythonic.
>
> It's not uncommon to have to create data before you use it, even when you
> could create it in-place where you use it. E.g. we might choose to write:
>
> data = [lots of items here]
> x = some_value()
> result = func(x, data)
>
>
> instead of:
>
> result = func(some_value(), [lots of items here])
>
>
> to make the function call more readable, or to keep to some maximum line
> length, or in order to re-use some of the values. So even when we *can*
> embed values in a call, often we choose not to. The fact that you don't
> have a choice when it comes to functions is not a major problem. Even if
> you could write:
>
> result = func(def (): lots of code goes here)
>
>
> you probably shouldn't.
>
>
>
> --
> Steven
>
> ______________________________**_________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/**mailman/listinfo/python-ideas<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/1360bf0f/attachment-0001.html>