Re: [Python-ideas] Dollar operator suggestion

[Koos Zevenhoven]

On Fri, Oct 27, 2017 at 8:46 AM, Mike Müller 
wrote:

> This already exists in Coconut:
> http://coconut.readthedocs.io/en/master/HELP.html#function-composition
>
>
Quite funny to read that. It seems like they have made something like what
I proposed in the 2015 function composition threads, but without what I
considered improvements to it. I summarize the proposal below, but here's
also a link to it:

https://mail.python.org/pipermail/python-ideas/2015-May/033482.html

Indeed, a discussion was going on where many people were interested in
function composition syntax. Different variants had been proposed, and IMO
one of the most notable suggestions had been using the new matrix
multiplication operator. For example:

  from numpy import sqrt, mean, square

  rms = sqrt @ mean @ square

​  rms(values)  # == sqrt(mean(square(values)))​

And this can of course already be implemented for custom callables which
implement __matmul__.

But my email (linked above, and which might be a bit hard to read because
of the interleaved references to my previous proposal) was essentially
about something like this:

Assuming bar is a function that accepts at least one argument, make
foo..bar equivalent to types.MethodType(bar, foo). In other words, it would
create a bound method out of bar, with foo as self.

Not only would it allow calling a method which is not defined within the
class:

  values..square()

but it would also directly allow this:

  values..square()..mean(axis=2)..sqrt()

And even when the left-hand expression becomes the second argument for a
function/method:

car_door..car_key.turn() # equivalent to CarKey.turn(car_key, car_door)


-- Koos


PS. As you can see in the email linked above, I was already prepared to
just abandon the idea, because most likely it would be rejected. But what I
was not prepared for was the amount of *nonsense* arguments that were
thrown against it in that thread and elsewhere, and the whole thing got
turned into some kind of weird puzzle.




> From http://coconut-lang.org/:
> > Coconut is a functional programming language that compiles to Python.
> > Since all valid Python is valid Coconut, using Coconut will only extend
> > and enhance what you're already capable of in Python.
>
> Mike
>
> Am 26.10.17 um 13:06 schrieb Yan Pas:
> > I've looked up this feature in haskell. Dollar sign operator is used to
> avoid
> > parentheses.
> >
> > Rationalle:
> > Python tends to use functions instead of methods ( e.g.len([1,2,3])
> instead of
> > [1,2,3].len() ). Sometimes the expression inside parentheses may become
> big
> > and using a lot of parentheses may tend to bad readability. I suggest the
> > following syntax:
> >
> > len $ [1,2,3]
> >
> > Functions map be also  chained:
> >
> > len $ list $ map(...)
> >
> > This operator may be used for function composition too:
> >
> > foo = len $ set $
> > in the same as
> > foo = lambda *as,**kas : len(set(*as, **kas))
> > in current syntax
> >
> > Regards,
> > Yan
> >
>



-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dollar operator suggestion

[Mike Müller]

This already exists in Coconut:
http://coconut.readthedocs.io/en/master/HELP.html#function-composition

From http://coconut-lang.org/:
> Coconut is a functional programming language that compiles to Python. 
> Since all valid Python is valid Coconut, using Coconut will only extend
> and enhance what you're already capable of in Python.

Mike

Am 26.10.17 um 13:06 schrieb Yan Pas:
> I've looked up this feature in haskell. Dollar sign operator is used to avoid
> parentheses.
> 
> Rationalle:
> Python tends to use functions instead of methods ( e.g.len([1,2,3]) instead of
> [1,2,3].len() ). Sometimes the expression inside parentheses may become big 
> and using a lot of parentheses may tend to bad readability. I suggest the
> following syntax:
> 
> len $ [1,2,3]
> 
> Functions map be also  chained:
> 
> len $ list $ map(...)
> 
> This operator may be used for function composition too:
> 
> foo = len $ set $
> in the same as
> foo = lambda *as,**kas : len(set(*as, **kas))
> in current syntax
> 
> Regards,
> Yan
> 
> 
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
> 

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dollar operator suggestion

[Nick Coghlan]

On 27 October 2017 at 02:23, Chris Barker  wrote:

>
>
> On Thu, Oct 26, 2017 at 6:32 AM, Paul Moore  wrote:
>
>>
>> Procedural languages, and Python in particular, simply don't work like
>> that. Functions have arbitrary numbers of arguments,
>
>
> And can return an arbitrary number of values. OK, technically a single
> tuple of values, but that does complicate the whole simple chaining thing.
>
> In short -- Python is not a functional language, even though is supports a
> number of functional idioms.
>

https://bugs.python.org/issue1506122 has a brief discussion of the
non-syntactic variant of this proposal:

functools.compose(len, set, str)(foo) => -> len(set(str(foo)))

The main concerns that resulted in the suggestion being rejected are:

* it isn't clear to folks that aren't already familiar with FP why the call
order for the composed functions should be right to left
* it isn't clear why every function other than the rightmost one must
accept a single positional arg
* it isn't clear why every function other than the leftmost one must return
a single result

And it doesn't make sense to provide something more general, because if
you're writing genuinely functional code, you do tend to abide by those
restrictions.

So given that our position is "We don't even want to add this to the
standard library, because the learning curve for using it successfully is
too steep", it's even less likely we'd be willing to add syntax for the
operation.

By contrast, "FP-for-Python" libraries like toolz [1] can make familiarity
with those kinds of concepts and a willingness to abide by the related
conventions a pre-requisite for using them. It's just opt-in, the same way
that learning to define your own classes (rather than importing existing
ones defined elsewhere) is opt-in.

Cheers,
Nick.

[1] https://toolz.readthedocs.io/en/latest/

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dollar operator suggestion

[Chris Barker]

On Thu, Oct 26, 2017 at 6:32 AM, Paul Moore  wrote:

>
> Procedural languages, and Python in particular, simply don't work like
> that. Functions have arbitrary numbers of arguments,


And can return an arbitrary number of values. OK, technically a single
tuple of values, but that does complicate the whole simple chaining thing.

In short -- Python is not a functional language, even though is supports a
number of functional idioms.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dollar operator suggestion

[Paul Moore]

On 26 October 2017 at 13:53, Daniel Moisset  wrote:
> This is to clarify that this si NOT about function composition, just an 
> alternate
> application syntax

The idea is already dead, based on the quote from Guido, but this
makes it even more clear that it's inappropriate for Python. As you
said (in part that I trimmed) Haskell uses single-argument functions
plus currying to implement function calls. This is extremely common
for functional languages, as it matches the theoretical basis much
better. As you point out, the shell pipeline model is actually quite
similar (a single input, chain of processing model).

Procedural languages, and Python in particular, simply don't work like
that. Functions have arbitrary numbers of arguments, currying is not
built in, composition is not a fundamental operation in the same way.
Although it's possible to explain how a `$` style syntax would work,
it doesn't fit naturally into the language - certainly not naturally
enough to warrant being part of the language syntax.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dollar operator suggestion

[Daniel Moisset]

Expanding on the comments of the OP (to give more information, not
necessarily to support or be against it):

The "$" operator in Haskell is not a composition operator, it's essentially
the same as python's apply builtin (the python2 builtin, removed for python
3), but with an operator syntax; the main trick behind it is that it's
right associative, so you get that:

len $ set $ str $ foo => len $ (set $ (str $ foo)) -> len(set(str(foo)))

It looks a bit funky, and it works only reasonably with single-argument
functions (which in haskell doesn't matter given that it uses currying that
makes all function one argument functions with partial application). The
best way to think about it for non Haskellers is that it's exactly like the
"|" operators un UNIX-like shells, but with the reverse order; in UNIX, run
foo, filter the output through str, then set, then len would read like:

foo | str | set | len, which is the same as above but right to left. This
is to clarify that this si NOT about function composition, just an
alternate application syntax

The second part of the example in the post, where composition is discussed
actually relies in a completely orthogonal feature of Haskell  that allows
to define partial operator applications as functions, for example you can
define:
half = (/ 2) -- same as lambda x: x/2, so half 4 => 2
next = (+ 1) -- same as lambda x: x + 1, so next 7 => 8
invert = (1 /) -- same as lambda x: 1 / x, so invert 4 => 0.25

So this implies a new way of writing anonymous functions besides lambdas.
To make the second part of the proposal work, both features should be
present

Now going into the discussion itself, the second feature is much more
invasive on the syntax+implementation (and also backwards comptibility,
given that stuff like "(+ 1)" already mean something different in python).
The first feature by itself shouldn't break stuff, and even if different to
what we're used to is not very unidiomatic (it leads to cleaner code,
although its meaning is definitely not very discoverable).

To get a rough idea on how that could work, take a look at
https://gist.github.com/dmoisset/bd43b8c0ce26c9cff0ad297b7e1ba5f9 ; I just
used python ** operator because that's the only right associative one.
Something similar provided in the default function type (and at a low
level) could work. I'd probably would like to see some code samples where
this is applied to check that it's worth the trouble.

D.


On 26 October 2017 at 12:06, Yan Pas  wrote:

> I've looked up this feature in haskell. Dollar sign operator is used to
> avoid parentheses.
>
> Rationalle:
> Python tends to use functions instead of methods ( e.g. len([1,2,3])
> instead of [1,2,3].len() ). Sometimes the expression inside parentheses
> may become big  and using a lot of parentheses may tend to bad readability.
> I suggest the following syntax:
>
> len $ [1,2,3]
>
> Functions map be also  chained:
>
> len $ list $ map(...)
>
> This operator may be used for function composition too:
>
> foo = len $ set $
> in the same as
> foo = lambda *as,**kas : len(set(*as, **kas))
> in current syntax
>
> Regards,
> Yan
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
Daniel F. Moisset - UK Country Manager - Machinalis Limited
www.machinalis.co.uk 
Skype: @dmoisset T: + 44 7398 827139

1 Fore St, London, EC2Y 9DT

Machinalis Limited is a company registered in England and Wales. Registered
number: 10574987.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dollar operator suggestion

[Thomas Jollans]

On 2017-10-26 13:06, Yan Pas wrote:
> I've looked up this feature in haskell. Dollar sign operator is used to
> avoid parentheses.
> 
> Rationalle:
> Python tends to use functions instead of methods ( e.g.len([1,2,3])
> instead of [1,2,3].len() ). Sometimes the expression inside parentheses
> may become big  and using a lot of parentheses may tend to bad
> readability. I suggest the following syntax:
> 
> len $ [1,2,3]

I see absolutely no benefit adding this syntax when we already have a
perfectly good function calling syntax.

> 
> Functions map be also  chained:
> 
> len $ list $ map(...)

Function composition has been discussed at length in the past, e.g.
https://mail.python.org/pipermail/python-ideas/2015-May/thread.html#33287

I'd like to highlight one key message:

https://mail.python.org/pipermail/python-ideas/2015-May/033491.html

Guido van Rossum wrote (May 11, 2015):
> 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.


That old python-ideas thread could be of interest to you.

Best

Thomas


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dollar operator suggestion

[Rhodri James]

On 26/10/17 12:06, Yan Pas wrote:

I've looked up this feature in haskell. Dollar sign operator is used to
avoid parentheses.


If I understand your example correctly, it does no such thing.  "A $ B" 
appears to mean "apply callable A to object B", at least the way you 
portray it below.  I don't speak Haskell so I can't comment on the original.



Rationalle:
Python tends to use functions instead of methods ( e.g. len([1,2,3])
instead of [1,2,3].len() ). Sometimes the expression inside parentheses may
become big  and using a lot of parentheses may tend to bad readability.


If you have that sort of legibility problem, it suggests that you are 
trying to do far too much on a single line.  New syntax won't help with 
that (in fact it will make it worse IMHO).



I suggest the following syntax:

len $ [1,2,3]


How is this better or easier to read than "len([1,2,3])" ?

What do you do for functions with two or more arguments?  The obvious 
thing would be to make the right-hand side of the $ operator a tuple, 
and whoops, there are your parentheses again.


I don't think this proposal achieves your aim, and I dislike it for a 
lot of other reasons.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Dollar operator suggestion

[Stephan Houben]

Why not a functional syntax, i.e.

compose(f, g, h)

rather than f $ g $ h

Advantage: you can do it today.
Without need to convince Guido to add more line noise to the language.

https://gist.github.com/stephanh42/6c9158c2470832a675fad7658048be9d

Stephan


2017-10-26 13:06 GMT+02:00 Yan Pas :

> I've looked up this feature in haskell. Dollar sign operator is used to
> avoid parentheses.
>
> Rationalle:
> Python tends to use functions instead of methods ( e.g. len([1,2,3])
> instead of [1,2,3].len() ). Sometimes the expression inside parentheses
> may become big  and using a lot of parentheses may tend to bad readability.
> I suggest the following syntax:
>
> len $ [1,2,3]
>
> Functions map be also  chained:
>
> len $ list $ map(...)
>
> This operator may be used for function composition too:
>
> foo = len $ set $
> in the same as
> foo = lambda *as,**kas : len(set(*as, **kas))
> in current syntax
>
> Regards,
> Yan
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Dollar operator suggestion

[Yan Pas]

I've looked up this feature in haskell. Dollar sign operator is used to
avoid parentheses.

Rationalle:
Python tends to use functions instead of methods ( e.g. len([1,2,3])
instead of [1,2,3].len() ). Sometimes the expression inside parentheses may
become big  and using a lot of parentheses may tend to bad readability. I
suggest the following syntax:

len $ [1,2,3]

Functions map be also  chained:

len $ list $ map(...)

This operator may be used for function composition too:

foo = len $ set $
in the same as
foo = lambda *as,**kas : len(set(*as, **kas))
in current syntax

Regards,
Yan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/