[Python-ideas] Partial operator (and 'third-party methods' and 'piping') [was Re: Function composition (was no subject)]

[Ivan Levkivskyi]

Dear Guido,

1. The longest program that I had written in Haskell was 4 lines.

2. You don't need to accept anything, everything is already accepted.
Namely,

@one
@two
@three
def fun(x):
    ...

already means fun = one(two(three(fun)))

Also now we have @ operator.

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.

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:

@deco(arg)
def fun(x):
    ...

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".

4. Since you don't want this in stdlib, let's move this discussion to Numpy
lists.

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.

Date: Mon, 11 May 2015 07:41:01 -0700

> From: Guido van Rossum <guido at python.org>
> To: "python-ideas at python.org" <python-ideas at python.org>
> Subject: Re: [Python-ideas] Partial operator (and 'third-party
>         methods' and 'piping') [was Re: Function composition (was no
> subject)]
> Message-ID:
>         <CAP7+vJJsRUD2_nA_NCQuB2smteYGiEbUbOyt=
> z-XyLCosTpp1g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> As long as I'm "in charge" the chances of this (or anything like it) being
> accepted into Python are zero. I get a headache when I try to understand
> code that uses function composition, and I end up having to laboriously
> rewrite it using more traditional call notation before I move on to
> understanding what it actually does. Python is not Haskell, and perhaps
> more importantly, Python users are not like Haskel users. Either way, what
> may work out beautifully in Haskell will be like a fish out of water in
> Python.
>
> I understand that it's fun to try to sole this puzzle, but evolving Python
> is more than solving puzzles. Enjoy debating the puzzle, but in the end
> Python will survive without the solution.
>
> --
> --Guido van Rossum (python.org/~guido)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150511/a72ddd3d/attachment.html>