[Python-ideas] Syntactic sugar to declare partial functions

Fri Aug 10 20:59:34 EDT 2018

[Neil Girdhar]

> >  ... I don't find the google-ablilty argument super strong because
> there are many constructs that are difficult to google, but still pretty
> great (e.g. comprehensions).
> Not that it matters, but comprehension is a standard term in mathematics
> and computer science apparently:

> https://en.wikipedia.org/wiki/List_comprehension
> https://en.wikipedia.org/wiki/Set-builder_notation

The point I was trying to make is: If you were to read a set comprehension
for the first time, not knowing what it was, what would you google?
It's not an easily searchable construct, but it's still an elegant, fairly
easy to comprehend feature.

This is actually a pretty good example of where I stand. Of course we use
words like 'comprehensions' when talking about language features, partly
because it's easier than "that expression that builds a list, set, or
dictionary" and partly because we often discuss how other languages
implemented the same general feature. That doesn't mean that the syntax has
to contain the word 'comprehension':

make_initials = lambda person: "".join(generator(domain=person.names,
predicate=bool, term=lambda name: name[0]))
initials = list.comprehension(domain=people, predicate=lambda person:
any(person.names), term=make_initials)

Borrowing from math notation and/or jargon, as comprehensions do, is fine,
especially if it's common enough to be taught in grade-school. Set-builder
notation is beyond what I learned in grade-school, but Python does more
than  'borrow' from set builder notation. It uses familiar words like
"for", "in", and "if", in place of that little epsilon (∈) and bar and
logical conjugation operator (*∧*) which I think help make them
understandable.

[Neil Girdhar]

> I disagree with you though when it comes to avoiding the technical terms.
> It's easier for people new to a field to learn the jargon of that field
> than it is to try to make it easier for them and by essentially creating a
> whole lot more technical jargon.

I'm willing to concede that that's probably true in this case. I think the
term "partial function application" is fairly clear rather than
jargon-for-jargon's sake. I could see someone thinking it meant that the
function is partially run, but that's a pretty minor worry. I'm sure
without looking it up, people would assume all sorts of things about what
func.given could mean. I also think the case of someone running into either
usage without some pretty glaring context clues about what's going on is
pretty unlikely.

I won't concede that lambda was an optimal choice. Even a reuse of the
keyword "def" would have been better because it would clearly relate it to
function declaration:

hand = sorted(pocket + community, key=def card: card.suit)[-5:]

It's literally short for "define function", so it makes sense.
My other complaint about lambdas, that they should be arranged logic first,
does go against pretty much all other implementations of anonymous functions
<https://en.wikipedia.org/wiki/Anonymous_function#Examples>, but I still
think it makes more sense:

hand = sorted(pocket + community, key=card.suit from card)[-5:]

There are several possible variations of that concept. I think most of them
would be better than the current syntax.

An alternate form of lambda is probably never going to come and I'm OK with
that. It's just my go-to anti-jargon example. Anonymous functions are not a
confusing concept, yet people get caught up on it surprisingly frequently.
I think the name is partly to blame.

On Fri, Aug 10, 2018 at 5:42 PM, Neil Girdhar <mistersheik at gmail.com> wrote:

>
>
> On Fri, Aug 10, 2018 at 6:21 PM Abe Dillon <abedillon at gmail.com> wrote:
>
>> [Neil Girdhar]
>>
>> I prefer partial since many programmers studied computer science
>>
>>
>> Many did not. I studied electrical engineering and wouldn't have been
>> able to tell you what the word 'partial' meant four years ago even though
>> I've been programming in one form or another since the late nineties. Many
>> programmers are scientists, engineers, financial analysts, etc. I'm pretty
>> sure I know what a closure is or what currying is, but if you put me on the
>> spot, I'd probably turn to Wikipedia to make sure I don't screw up the
>> definition.
>>
>> [Neil Girdhar]
>>
>>> It makes the concepts easier to google.
>>
>>
>> That can be an important criteria, but it can also be a red-herring. If
>> an implementation is clear enough, few people would have to google it. If,
>> however, you use obscure enough words like "lambda", people will google it
>> every day and still find it confusing. The ternary expression is difficult
>> to google if you don't know the jargon "ternary", but there's less of a
>> need to google it because it's pretty obvious how it works based simply on
>> its implementation.
>>
>> [Steven D'Aprano]
>>
>>> It's a clear, *generic* meaning that doesn't have any association with
>>> partial application.
>>> We'd be trying to create that association from scratch.
>>
>>
>> Sure, that's a good point. I don't think that sounds like such a big
>> problem, but I also don't hate 'partial'. I just prefer 'given'.
>> At any rate, I don't find the google-ablilty argument super strong
>> because there are many constructs that are difficult to google, but still
>> pretty great (e.g. comprehensions).
>>
> Not that it matters, but comprehension is a standard term in mathematics
> and computer science apparently:
>
> https://en.wikipedia.org/wiki/List_comprehension
> https://en.wikipedia.org/wiki/Set-builder_notation
>
>
>> [Steven D'Aprano]
>>
>> > Words like 'partial', 'curry', 'lambda', and 'closure' are fine
>>> > for text books, published papers, and technical discussion,
>>> And programmers.
>>>
>>
>> Yes, technical discussion among programmers.
>>
>> [Steven D'Aprano]
>>
>> Programming is a technical skill with its own jargon. Classes,
>>> inheritence, exceptions, trampolining, processes, threads, protocols,
>>> imports, decorator, builders... we are happy with all those, why should
>>> we fear partial and lambda?
>>
>>
>> I get that programming carries it's own jargon and I understand that it
>> has a beneficial function. It can facilitate concise communication of
>> nuanced concepts. It can also be a needlessly confusing way to convey
>> otherwise simple concepts. In the latter case, it can feel like the intent
>> is to create an air of superiority through esoteric language. I feel like
>> "curry" and "lambda" are needlessly un-descriptive and confusing. "partial"
>> really isn't that bad, I just prefer "given" because I think it's pretty
>> clear. I've never heard of "trampolining", but if I had to guess: it's
>> probably related to recursion that involves more than one function?
>>
>> I suspect that most programmers couldn't describe the difference between
>> a type and a class.
>> I suspect that most programmers couldn't tell you the difference between
>> an exception or an error.
>> I know that lots of programmers refer to the "__init__" method as a
>> "constructor" instead of an "initializer".
>>
>> Precision is less of a problem In a programming language. `func.given`
>> doesn't have dozens of possible meanings. It's meaning has to be completely
>> unambiguous to the machine.
>>
>> [Steven D'Aprano]
>>
>> > but I think
>>> > they would (or do in the case of 'lambda') harm Python.
>>> That's an extreme overreaction.
>>
>>
>> Extreme? I thought it was a rather benign opinion. I'm not exactly
>> frothing at the mouth here. It's not like I'm declaring holy war on Python
>> for using the word 'lambda'. I just think it was a mistake (and thatdeath
>> should come to all non-believers).
>>
>> [Steven D'Aprano]
>>
>> Do you mean to imply that there are people who looked at Python, loved
>>> the language, but decided to use something else because they didn't like
>>>
>>> the choice of the keyword "lambda"?
>>
>>
>> No. Not at all. Is that what you got out of my sentence? Am I really the
>> one being extreme?
>>
>
> I didn't think you were being extreme at all.  I think you're making a
> reasonable point about keeping things simple.
>
> I disagree with you though when it comes to avoiding the technical terms.
> It's easier for people new to a field to learn the jargon of that field
> than it is to try to make it easier for them and by essentially creating a
> whole lot more technical jargon.  (Even if that jargon uses common words.)
>
> Your idea for "given" isn't obviously doing a partial function
> application.  Someone might wonder if "given" is setting thread local
> storage, or setting attributes on a callable class, or opening context
> managers at call time…
>
>
>>
>> [Steven D'Aprano]
>>
>>> If not, in what way is Python harmed? Would it be faster if the keyword
>>> was "function", or use less memory, or more expressive?
>>
>>
>> I didn't realize I'd hit such a nerve. I think there are better ways that
>> anonymous functions could have been implemented.  I've already said in past
>> discussions, I think the expression should come before the signature
>> because the signature is often obvious from context so placing it before
>> the logic is kinda noisy. I don't know what the best syntax would have
>> been, but I refuse to believe that an esoteric word from an esoteric branch
>> of calculus with an arbitrary etymology was the absolute best choice
>> available. I think the harm that choice caused is relatively minor, but I
>> don't think it was a great choice. I'm truly sorry if I hurt your feelings.
>>
>> [Steven D'Aprano]
>>
>> Remember that to millions of programmers in the world, "function" is
>>> just as much an obscure foreign piece of jargon they have to memorise as
>>>
>>> "lambda" is to English-speakers.
>>
>>
>> Maybe we should use Egyptian Hieroglyphs then. Even the playing field. It
>> doesn't matter anyway, right? It's all nonsense to someone...
>>
>> Honestly, I don't think 'partial' is that bad. I just wanted to support
>> your own comment:
>>
>>
>> although possibly a less jargon name would be nicer:
>>>     add1 = add.given(1)
>>
>>
>> But you seem to have some grudge against me. I don't get all the outrage
>> over what I thought was a fairly benign post.
>> Did I do something to make you so angry at me? I'd like to resolve
>> whatever it is instead of having to deal with this every time I post.
>>
>> On Fri, Aug 10, 2018 at 2:09 AM, Steven D'Aprano <steve at pearwood.info>
>> wrote:
>>
>>> On Thu, Aug 09, 2018 at 01:32:00PM -0500, Abe Dillon wrote:
>>> > I'd like to push for the less jargon-y `func.given()` version if this
>>> gains
>>> > traction. Not only is it shorter, it's a much more common term with a
>>> clear
>>> > meaning.
>>>
>>> It's a clear, *generic* meaning that doesn't have any association with
>>> partial application.
>>>
>>> https://www.google.com/search?q=function+given
>>>
>>> We'd be trying to create that association from scratch.
>>>
>>>
>>> > Words like 'partial', 'curry', 'lambda', and 'closure' are fine
>>> > for text books, published papers, and technical discussion,
>>>
>>> And programmers.
>>>
>>> Programming is a technical skill with its own jargon. Classes,
>>> inheritence, exceptions, trampolining, processes, threads, protocols,
>>> imports, decorator, builders... we are happy with all those, why should
>>> we fear partial and lambda?
>>>
>>>
>>> > but I think
>>> > they would (or do in the case of 'lambda') harm Python.
>>>
>>> That's an extreme overreaction.
>>>
>>> Do you mean to imply that there are people who looked at Python, loved
>>> the language, but decided to use something else because they didn't like
>>> the choice of the keyword "lambda"?
>>>
>>> If not, in what way is Python harmed? Would it be faster if the keyword
>>> was "function", or use less memory, or more expressive?
>>>
>>> Remember that to millions of programmers in the world, "function" is
>>> just as much an obscure foreign piece of jargon they have to memorise as
>>> "lambda" is to English-speakers.
>>>
>>>
>>> --
>>> Steve
>>> _______________________________________________
>>> 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/
>>>
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "python-ideas" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/python-ideas/jOMinivFCcQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> python-ideas+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>> _______________________________________________
>> 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/
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "python-ideas" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/
>> topic/python-ideas/jOMinivFCcQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> python-ideas+unsubscribe at googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> _______________________________________________
> 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/20180810/1a4b6445/attachment-0001.html>