<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Dear Guido,<br><br></div>1. The longest program that I had written in Haskell was 4 lines.<br><br></div>2. You don't need to accept anything, everything is already accepted. Namely,<br><br></div>@one<br></div>@two<br></div>@three<br></div>def fun(x):<br>    ...<br><br></div>already means fun = one(two(three(fun)))<br><br></div>Also now we have @ operator. <br><br></div>3. My idea in its current state is to overload @ to allow piping of arbitrary transformers of iterables, not only multiplication of matrices. Semantics is the same: matrix is something that takes a vector and returns a vector and multiplication of matrices is exactly "piping" the corresponding transformations.<br><br></div>I now think one does not need any partial applications or something similar. The rules should be the same as for decorators. If I write:<br><br></div>@deco(arg)<br></div>def fun(x):<br>    ...<br><br></div>it is my duty to be sure that deco(arg) evaluates to something that takes one function and returns one function. Same should be for vector-transformers, each should be "one vector in - one out".<br><br></div>4. Since you don't want this in stdlib, let's move this discussion to Numpy lists.<br><br></div>5. I never thought that evolving Python is solving puzzles. My intention was helping people that might have same problems with me. If it is not the best place to do so, sorry for disturbing.<br><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">Date: Mon, 11 May 2015 07:41:01 -0700<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>><br>
To: "<a href="mailto:python-ideas@python.org">python-ideas@python.org</a>" <<a href="mailto:python-ideas@python.org">python-ideas@python.org</a>><br>
Subject: Re: [Python-ideas] Partial operator (and 'third-party<br>
        methods' and 'piping') [was Re: Function composition (was no subject)]<br>
Message-ID:<br>
        <CAP7+vJJsRUD2_nA_NCQuB2smteYGiEbUbOyt=<a href="mailto:z-XyLCosTpp1g@mail.gmail.com">z-XyLCosTpp1g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
As long as I'm "in charge" the chances of this (or anything like it) being<br>
accepted into Python are zero. I get a headache when I try to understand<br>
code that uses function composition, and I end up having to laboriously<br>
rewrite it using more traditional call notation before I move on to<br>
understanding what it actually does. Python is not Haskell, and perhaps<br>
more importantly, Python users are not like Haskel users. Either way, what<br>
may work out beautifully in Haskell will be like a fish out of water in<br>
Python.<br>
<br>
I understand that it's fun to try to sole this puzzle, but evolving Python<br>
is more than solving puzzles. Enjoy debating the puzzle, but in the end<br>
Python will survive without the solution.<br>
<br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
</blockquote><div> </div><br></div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>