[Python-ideas] (no subject)

[Ivan Levkivskyi]

On May 7, 2015 9:46 AM, "Andrew Barnert" <abarnert at yahoo.com> wrote:
>
> On May 6, 2015, at 18:13, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> >
> > Ivan Levkivskyi writes:
> >
> >> Ok, I will try inspecting all existing approaches to find the one
> >> that seems more "right" to me :)
> >
> > If you do inspect all the approaches you can find, I hope you'll keep
> > notes and publish them, perhaps as a blog article.
> >
> >> In any case that approach could be updated by incorporating matrix
> >> @ as a dedicated operator for compositions.
> >
> > I think rather than "dedicated" you mean "suggested".  One of Andrew's
> > main points is that you're unlikely to find more than a small minority
> > agreeing on the "right" approach, no matter which one you choose.
>
> Whatever wording you use, I do think it's likely that at least some of
the existing libraries would become much more readable just by using @ in
place of what they currently use. Even better,
> It may also turn out that the @ notation just "feels right" with one
solution to the argument problem and wrong with another, narrowing down the
possibility space.
>
> So, I think it's definitely worth pushing the experiments if someone has
the time and inclination, so I'm glad Ivan has volunteered.
>

Thank you for encouraging me. It will be definitely an interesting
experience to do this.

> >> At least, it seems that Erik from astropy likes this idea and it is
> >> quite natural for people with "scientific" background.
>
> I forgot to say before, but: it's great to have input from people coming
from the MATLAB-y scientific/numeric world like him (I think) rather than
just the Haskell/ML-y mathematical/CS world like you (Stephen, I think), as
we usually get in these discussions. If there's one option that's
universally obviously right to everyone in the first group, maybe everyone
in the second group can shut up and deal with it. If not (which I think is
likely, but I'll keep an open mind), well, at least we've got broader
viewpoints and more data for Ivan's summary.
>
> > Sure, but as he also points out, when you know that you're going to be
> > composing only functions of one argument, the Unix pipe symbol is also
> > quite natural (as is Haskell's operator-less notation).  While one of
> > my hobbies is category theory (basically, the mathematical theory of
> > composable maps for those not familiar with the term), I find the Unix
> > pipeline somehow easier to think about than abstract composition,
> > although I believe they're equivalent (at least as composition is
> > modeled by category theory).
>
> I think you're right that they're equivalent in theory.
>
> But I feel like they're also equivalent in usability and readability (as
in for 1/3 simple cases they're both fine, for 1/3 compose looks better,
for 1/3 rcompose), but I definitely can't argue for that.
>
> What always throws me is that most languages that offer both choose
different precedence (and sometimes associativity, too) for them. The
consequence seems to be that when I just use compose and rcompose operators
without thinking about it, I always get them right, but as soon as I ask
myself "which one is like shell pipes?" or "why did I put parens here?" I
get confused and have to go take a break before I can write any more code.
Haskell's operatorless notation is nice because it prevents me from
noticing what I'm doing and asking myself those questions. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150507/d3201639/attachment.html>