Home Original page

[Python-ideas] Method chaining notation

Haoyi Li haoyi.sg at gmail.com
Sun Feb 23 06:27:22 CET 2014 
> The other means you're doing declarative stuff, transforming objects into
new temporary objects. That distinction is huge

I guess that's where people disagree. I think the distinction is not huge.
Whether imperatively constructing something or "declaratively" (???) doing
transformations, the *meaning* of the code is the same: start from some
*foo* and do *some stuff *on *foo *in sequence until the *foo *is what I
want.

Whether it's implemented using mutation or allocation/garbage-collection is
an implementation detail that clouds our view of a higher-level semantic:
initializing an object with some stuff. In fact, this distinction is so
meaningless that many languages/runtimes will turn one into the other as an
optimization, because the semantics are exactly the same.




On Sat, Feb 22, 2014 at 9:06 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> On Feb 22, 2014, at 18:48, Chris Angelico <rosuav at gmail.com> wrote:
>
> > On Sun, Feb 23, 2014 at 1:25 PM, Nick Coghlan <ncoghlan at gmail.com>
> wrote:
> >> That *looks* like it should be a data transformation pipeline, but
> >> it's not - each step in the chain is mutating the original object,
> >> rather than creating a new one. That's a critical *problem* with the
> >> idea, not a desirable feature.
> >
> > Except that it doesn't. The idea of using a different operator is that
> > it should clearly be mutating the original object. It really IS
> > obvious, at a glance, that it's going to be returning the existing
> > object, because that operator means it will always be.
>
> The difference between the look of nested statements and giant expressions
> in Python is much larger than the difference between the look of . and ->.
> One structure means you're doing imperative stuff, mutating one value on
> each line. The other means you're doing declarative stuff, transforming
> objects into new temporary objects. That distinction is huge, and the fact
> that it's immediately visible in Python i's one of the strengths of Python
> over most other "multi-paradigm" languages.
>
> > I believe that naming things that don't matter is a bad idea. We don't
> > write code like this:
> >
> > five = 5
> > two = 2
> > print("ten is",five*two)
>
> But in real life code, this would be something like rows * columns, and
> even if rows and columns are constant, they're constants you might want to
> change in a future version of the code, so you _would_ name them.
>
> And if, as you say, they're actually function calls, not constants, I
> think most people would write:
>
> rows = consoleobj.getparam('ROWS')
> cols = consoleobj.getparam('COLS')
> cells = rows * cols
>
> ... rather than try to cram it all in one line.
>
> > because the intermediate values are completely insignificant. It's
> > much better to leave them unnamed. (Okay, they're trivial here, but
> > suppose those were function calls.) In a GTK-based layout, you'll end
> > up creating a whole lot of invisible widgets whose sole purpose is to
> > control the layout of other widgets. In a complex window, you might
> > easily have dozens of those. (Same happens in Tkinter, from what I
> > gather, but I haven't much looked into that.) Naming those widgets
> > doesn't improve readability - in fact, it damages it, because you're
> > left wondering which insignificant box is which. Leaving them unnamed
> > and just part of a single expression emphasizes their insignificance.
>
> All you're arguing here is that PyGtk is badly designed, or that Gtk is
> not a good match for Python, so you have to write wrappers. There's no
> reason the wrapper has to be fluent instead of declarative.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140222/88458575/attachment.html>
More information about the Python-ideas mailing list