Re: [Python-ideas] Syntactic sugar to declare partial functions

[Chris Barker - NOAA Federal via Python-ideas]

>
> Do we often call functools.partial on arbitrary callable objects that we
> don't know in advance?

For my part, I don’t think I’ve ever used partial in production code.
It just seems easier to simply fo it by hand with a closure ( Am I
using that term right? I still don’t quite get the terminology)

And if I had a callable class instance I wanted to “customize”, I’d
likely use an OO approach — parameterize the instance, or subclass.

So yeah, partial is probably used primarily with “regular” functions.

But then, I don’t know that we need any easier syntax anyway — maybe
I’d be more likely to use it, but it kind of feels like a feature
that’s there so we can write more functional code for the sake of
writing more functional code.

If someone’s really interested in this, a search on gitHub or
something to see how it’s used in the wild could be enlightening.

-CHB
___
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] Syntactic sugar to declare partial functions

[Steven D'Aprano]

On Mon, Aug 13, 2018 at 07:46:49PM +0200, Stefan Behnel wrote:
> Michel Desmoulin schrieb am 09.08.2018 um 18:59:
> > I'd rather have functools.partial() to be added as a new method on
> > function objects.
[...]
> > add_2 = add.partial(2)
> 
> Except that this only works for functions, not for other callables.
> Meaning, code that uses this for anything but its self-defined functions
> will break as soon as someone passes in a callable object that is not a
> function.

That's an excellent point.

If it were important to cover those use-cases, we could add a partial 
method to types, methods, builtin-functions etc. But I suspect that 
doing that would increase the cost of this proposed feature past the 
point where it is worthwhile.

Do we often call functools.partial on arbitrary callable objects that we 
don't know in advance? (Not a rhetorical question.) I know I don't -- 
all the times I've called partial, I've known what the callable was, and 
it was always a function I created with def. But maybe others do 
something differently.

I don't mind writing this:

# only a minor inconvenience
spam = func.partial(arg)
eggs = functools.partial(callable, arg)

given that I knew upfront that func was a function and callable was not. 
But if I didn't know, the utility of a partial method would be hugely 
reduced, and I'd just use functools.partial for everything.



-- 
Steve
___
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] Syntactic sugar to declare partial functions

[Chris Angelico]

On Tue, Aug 14, 2018 at 7:58 AM, Greg Ewing  wrote:
> Chris Angelico wrote:
>>
>> No, lambda calculus isn't on par with brakes - but anonymous functions
>> are, and if they're called "lambda", you just learn that.
>
>
> It's like saying that people would find it easier to learn to
> drive if "brakes" were called "stoppers" or something. I don't
> think that's true.

Reminds me of this:

"So, there's some buttons on the floor. Pedals. Uhh That's the
"go" pedal... That, I believe, is the stopper... and this... this
doesn't do anything"
-- Wreck It Ralph, trying to figure a car out.

I'm pretty certain he didn't do any better that way than if he'd used
words like "accelerator" and "brake". In fact, this supports my
assertion that it's not the terminology that bites you - it's the
concepts behind it. Even if he'd known that the other pedal was called
the "clutch", it wouldn't have helped him much without knowing how to
use it...

Whether you spell it "function(arg) {...}" or "lambda arg: ...", it's
the semantics that are hardest to learn.

ChrisA
___
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] Syntactic sugar to declare partial functions

[MRAB]

On 2018-08-14 02:46, Michael Selik wrote:



On Mon, Aug 13, 2018, 5:48 PM Greg Ewing > wrote:


Chris Angelico wrote:
 > No, lambda calculus isn't on par with brakes - but anonymous
functions
 > are, and if they're called "lambda", you just learn that.

It's like saying that people would find it easier to learn to
drive if "brakes" were called "stoppers" or something. I don't
think that's true.


There isn't much jargon involved in learning to drive and most of it is 
natural: left turn, right turn, blinkers, etc.


Compare this with learning to sail. I still don't remember which side is 
starboard.




"Starboard" is the side on which was the "steerboard", the large "board" 
or oar used for steering the boat, a predecessor of the rudder. Most 
people are right-handed, so it was put on the right-hand side of the boat.


Given that, it made sense to tie the boat up to a jetty on its 
unobstructed left-hand side, the "port" side.


Starboard = right, port = left.

___
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] Syntactic sugar to declare partial functions

[David Mertz]

Pedantically, Python's lambda isn't even the same thing as in the lambda
calculus. The mathematical abstraction is always curried, and neither
Python nor most languages that use the spelling 'lambda' do that.

So even assuming users must learn technical vocabulary, this is an
inaccurate such term. 'def' or 'func' would be less deceptive here for
anonymous functions.

The burden of learning the word lambda—and unlearning it's meaning in
mathematical logic if you happened to have used that—it's not huge. But
it's more than zero. And probably more than leaning 'function'.

On Mon, Aug 13, 2018, 8:49 PM Greg Ewing 
wrote:

> Chris Angelico wrote:
> > No, lambda calculus isn't on par with brakes - but anonymous functions
> > are, and if they're called "lambda", you just learn that.
>
> It's like saying that people would find it easier to learn to
> drive if "brakes" were called "stoppers" or something. I don't
> think that's true.
>
> --
> Greg
>
>
> ___
> 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] Syntactic sugar to declare partial functions

[Michael Selik]

On Mon, Aug 13, 2018, 5:48 PM Greg Ewing 
wrote:

> Chris Angelico wrote:
> > No, lambda calculus isn't on par with brakes - but anonymous functions
> > are, and if they're called "lambda", you just learn that.
>
> It's like saying that people would find it easier to learn to
> drive if "brakes" were called "stoppers" or something. I don't
> think that's true.
>

There isn't much jargon involved in learning to drive and most of it is
natural: left turn, right turn, blinkers, etc.

Compare this with learning to sail. I still don't remember which side is
starboard.

>
___
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] Syntactic sugar to declare partial functions

[Greg Ewing]

Chris Angelico wrote:

No, lambda calculus isn't on par with brakes - but anonymous functions
are, and if they're called "lambda", you just learn that.


It's like saying that people would find it easier to learn to
drive if "brakes" were called "stoppers" or something. I don't
think that's true.

--
Greg


___
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] Syntactic sugar to declare partial functions

[Abe Dillon]

[Steven D'Aprano]

> - I accept that there've been a few cases where I could have
>   chosen my words better, and consequently I've rubbed Abe
>   the wrong way; sorry about that Abe, as I said earlier (and
>   I meant it) I have no grudge against you.


Thank you. I hold no grudge against you either. I'm sorry for all the drama.

[Steven D'Aprano]

> - The most important technical issue I wanted to get from my
>   discussion with Abe has been solved, I now believe that I
>   understand what harm he feels was caused by chosing the name
>   "lambda" over some alternative.
> - Namely (if I have understood Abe correctly) its the lost
>   opportunity to have a better name.


Yes. That's pretty much it. In hindsight, I should have realized that the
word "harm" carries a much more sever context in the programming community
given all the "X considered harmful" articles out there.

[Steven D'Aprano]

>  - Which seems to me to be so slight a harm that I don't think
>   it gives us any guidance at all as to whether "partial" or
>   "given" would make a better name for this proposed feature.


I consider jargon for jargon's sake to be a poor reason to choose one term
over a much more common term, however; I don't consider all jargon equal. I
think "anonymous function" is far more descriptive than "lambda". I think
you're ultimately right, however; that this doesn't guide the decision of
"partial" over "given" very much because "partial" is not all that obscure.
"partial function application" is fairly clear and as you said, Python
wouldn't be trying to create an association from scratch.

[Steven D'Aprano]

> It certainly has not been helped by people fanning the flames of
> argument by calling this a "toxic forum".


At that point I felt like I had expressed that you came off as antagonistic
toward me, had my feelings brushed off, then had multiple people ganging up
on me about something I thought I had clearly articulated.

I don't want to start a big fuss about it, but now both you and Stephen
Turnbull have not-so-subtly referred to me indirectly like this. This time
is fairly benign, but Turnbull's remark comes off as a passive-aggressive
way of calling me toxic. I hope this isn't a sign of things to come where
it's fine to passive-aggressively sling mud, but being direct is considered
"crossing the line", because I find passive aggression far more insulting.
I'm not an eight-year-old and people hiding behind the plausible
deniability that even thinly veiled passive aggression affords them
frustrates me. As I said early on: I'd rather resolve issues than have them
continue to fester. Passive aggression does the exact opposite.

[Steven D'Aprano]

> We should assume good faith. Before flying off the handle and taking
> offense, we should assume misunderstanding (on either or both party),
> accidental poor choice of wording, or merely robust debate rather than
> malice. We ought to be careful about making assumptions about people's
> motives from their responses. Email is a notoriously bad medium for
> judging people's motivation.
> The rest that follows is detail, responding to a few specific points
> which I deem relevant but not essential.


Those are wise words and I'll try to adhere to them in the future. I would
like to amend, that when someone signals that they feel like you're being
aggressive towards them, it's a good idea to apologize. It's a simple act
that can diffuse a lot of tension.

[Steven D'Aprano]

> > I explained my position on lambda as fully as I care to in my response to
> > Niel if you care to read it.
> I did read it. Just because I didn't respond to it directly doesn't mean
> I didn't read it.


I didn't mean that as an accusation that you hadn't read it. I'm sorry it
came off that way.

[Steven D'Aprano]

> You say you object to the name, but then suggest a change that is
> idependent of that name.


Yes, I can see how that could lead to confusion. I'm sorry.

I do, indeed, have two mostly separate objections to 'lambda':
1) I think it's a bad name
2) I think it's a sub-optimal form

The only relevance of the form is that it sort-of illustrates a broader
name-space to explore. For instance, the alternative name 'def' doesn't
really make sense in the reversed order:

hand = sorted(cards, key=def card: card.suit)  # this kinda works, at least
I think it's better than 'lambda'

hand = sorted(cards, key=(card.suit def card)  # this is... not as good

[Steven D'Aprano]

> > [Steven D'Aprano]
> >
> > > How can we insist that 3/4 of the world learn English words to use
> Python
> >
> > Do you really think that 3/4 of the world learns English just to write
> > Python?
> That's not what I wrote. There's a difference between these two
> positions:
> - needing to learn to read English words to use Python;
> - using Python is the only reason to learn English.
> I said the first, not the second.


I don't mean to come off as combative, but that is a direct quote, and I
didn't try to take it out of con

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Greg Ewing]

Abe Dillon wrote:

[Bruce Leban]

Lambda calculus IS computer science.

It's a foundation of computer science. That doesn't mean it "IS" 
computer science.  Set theory is a foundation of computer science. It's

still it's own discipline.


Lambda calculus is considered a part of computers science,
because it was invented specifically for the purpose of modelling
computation. Set theory wasn't.

--
Greg
___
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] Syntactic sugar to declare partial functions

[Steven D'Aprano]

TL;DR

- I accept that there've been a few cases where I could have 
  chosen my words better, and consequently I've rubbed Abe
  the wrong way; sorry about that Abe, as I said earlier (and
  I meant it) I have no grudge against you.

- The most important technical issue I wanted to get from my
  discussion with Abe has been solved, I now believe that I
  understand what harm he feels was caused by chosing the name
  "lambda" over some alternative.

- Namely (if I have understood Abe correctly) its the lost
  opportunity to have a better name.

- Which seems to me to be so slight a harm that I don't think
  it gives us any guidance at all as to whether "partial" or 
  "given" would make a better name for this proposed feature.

(So much drama for so little gain.)

Even after all these years of seeing people over-react to minor 
perceived slights (whether real or not), I cannot believe how quickly 
this one has degenerated into antagonism and over-reaction, and over so 
little. It certainly has not been helped by people fanning the flames of 
argument by calling this a "toxic forum".

We should assume good faith. Before flying off the handle and taking 
offense, we should assume misunderstanding (on either or both party), 
accidental poor choice of wording, or merely robust debate rather than 
malice. We ought to be careful about making assumptions about people's 
motives from their responses. Email is a notoriously bad medium for 
judging people's motivation.

The rest that follows is detail, responding to a few specific points 
which I deem relevant but not essential.

*

*

*

On Sun, Aug 12, 2018 at 10:31:36PM -0500, Abe Dillon wrote:

> I explained my position on lambda as fully as I care to in my response to
> Niel if you care to read it.


I did read it. Just because I didn't respond to it directly doesn't mean 
I didn't read it.

You say you object to the name, but then suggest a change that is 
idependent of that name. You talked about the placement of the function 
signature, wanting to put the body of the lambda first, before the 
parameter list. That has nothing to do with the choice of name "lambda", 
which is what I thought you were objecting too as it was too jargony. 
Moving the parameter list to the end of the expression is idependent of 
the keyword "lambda".


> I only think lambda harms Python in so far as
> there were better alternatives that communicate their intention much better
> and are more readable. That's an opinion. If you must know, i'm not
> currently frothing at the mouth as I state it.

Nobody has accused you of frothing at the mouth.

You seem to be talking about "opportunity costs" in a sense. Its not so
much that the name lambda does harm in and of itself, but that another
choice could be *even better* and do *even more good*.

Is that a reasonable description of your position?


> My original post was agreeing with you. Supporting your own words. If you
> don't agree with my position that we should avoid jargon for jargon's sake,

And don't imagine for a second I'm not aware of the irony.


> then what exactly did you mean when you said, "although possibly a less
> jargon name would be nicer?" Can you articulate why you think it might be
> nicer to use a less jargon name?

I meant exactly what I said. *Possibly* a less jargon name would be
nicer. Or possibly not. I was opening the issue up for further
discussion, not nailing my colours to the mast as champion for the idea.


> What about my saying it all of a sudden
> makes it an "extreme overreaction"?

Now you're quoting me out of context. It was your claim that the name
"lambda" does harm to Python that I described that way.

In hindsight, I wish I had left off the adjective "extreme".


[...]
> Notice: I never said "real, significant, non-trivial harm" anywhere in this
> entire discussion.

In fairness, you did say "minor" harm, so I'll accept that my emphasis 
on real significant etc was questionable.

I don't know where the boundary between minor and trivial lies and I 
think people can disagree on this point. So I'll accept that here I read 
more into your words than were actually there. Sorry about that.


[...]
> [Steven D'Aprano]
> 
> > How can we insist that 3/4 of the world learn English words to use Python
> 
> Do you really think that 3/4 of the world learns English just to write
> Python?

That's not what I wrote. There's a difference between these two 
positions:

- needing to learn to read English words to use Python;

- using Python is the only reason to learn English.

I said the first, not the second.


> [Steven D'Aprano]
> 
> > ...if we aren't even willing to move out of our own comfort zone to
> > the extent of learning accurate jargon terms from our own profession?
> 
> Very few of us are computer scientists by profession. That's not even where
> 'lambda' comes from. In computer science, it's called an "anonymous
> function". "lambda" comes from lambda calculus.

Where it comes from is not really

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Chris Angelico]

On Tue, Aug 14, 2018 at 6:26 AM, Abe Dillon  wrote:
> [Chris Angelico]
>>
>> > The whole point of a programming language is to bridge the gap between
>> > machine code and natural language (in Python's case English, as with
>> > most
>> > other languages). It's to make reading and writing code easier through
>> > abstraction, not to create ivory towers through the use of esoteric
>> > jargon.
>> > It's not supposed to make a cool kids club for people privileged enough
>> > to
>> > study CS in college. At least that's not my goal.
>> The whole point of a car is to make driving easier through abstracting
>> away the internal details of petrochemical propulsion, but if someone
>> says "I don't want to know about 'gears' or 'brakes' or any of these
>> technical terms", you wouldn't want them driving on the roads you're
>> on. There is a certain level of comprehension that you can't avoid.
>> (If you don't know anything about how to use a car, you can still ride
>> in one, but you can't drive it; and you don't need to understand about
>> anonymous functions in order to operate a computer, but you'll need
>> them to program effectively.)
>
>
> This was originally in response to Bruce Leban's assertion: "If using lambda
> as a keyword leads people to go and learn about lambda calculus that is a
> good thing."
>
> Are you saying that knowing "what lambda calculus is" is as important to
> programming in Python as knowing "what breaks are" is to driving? If so, I
> don't think that analogy holds water. I don't think lambda calculus is
> fundamental to knowing how to write a program. I don't even think anonymous
> functions are fundamental to writing a program. I think a programmer could
> go their whole life without ever knowing what a lambda expression is and
> still manage to write plenty of very useful code.

No, lambda calculus isn't on par with brakes - but anonymous functions
are, and if they're called "lambda", you just learn that. In fact, I
would say that the word "lambda" is the least troublesome part of
anonymous functions, callbacks, and related topics.

It's the same with "partial". Actually, I didn't think of that as
"partial application" but as "partial specification of parameters". If
you can grok the concept that you can take a function, lock some of
its parameters, and get back another function, then you should be able
to learn a word to associate with it.

ChrisA
___
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] Syntactic sugar to declare partial functions

[Abe Dillon]

[Chris Angelico]

> > The whole point of a programming language is to bridge the gap between
> > machine code and natural language (in Python's case English, as with most
> > other languages). It's to make reading and writing code easier through
> > abstraction, not to create ivory towers through the use of esoteric
> jargon.
> > It's not supposed to make a cool kids club for people privileged enough
> to
> > study CS in college. At least that's not my goal.
> The whole point of a car is to make driving easier through abstracting
> away the internal details of petrochemical propulsion, but if someone
> says "I don't want to know about 'gears' or 'brakes' or any of these
> technical terms", you wouldn't want them driving on the roads you're
> on. There is a certain level of comprehension that you can't avoid.
> (If you don't know anything about how to use a car, you can still ride
> in one, but you can't drive it; and you don't need to understand about
> anonymous functions in order to operate a computer, but you'll need
> them to program effectively.)


This was originally in response to Bruce Leban's assertion: "If using
lambda as a keyword leads people to go and learn about lambda calculus that
is a good thing."

Are you saying that knowing "what lambda calculus is" is as important to
programming in Python as knowing "what breaks are" is to driving? If so, I
don't think that analogy holds water. I don't think lambda calculus is
fundamental to knowing how to write a program. I don't even think anonymous
functions are fundamental to writing a program. I think a programmer could
go their whole life without ever knowing what a lambda expression is and
still manage to write plenty of very useful code.

It seems to me like the whole point of this discussion has turned into
getting me to repent and profess my undying love for lambda expressions.
I'm sorry to disappoint.

Maybe we should split off this discussion into a thread where people can
keep badgering me to come up with an objective proof that Python's lambda
expressions are not the best implementation possible. Then, at least, we
can stop polluting this thread with this tangent.

It doesn't seem to matter how many times I try to point this out, but my
original comment should be read as: "I like Steven's idea. I prefer `given`
to `partial`." I'm sorry I even brought up lambda. I'm truly sorry to all
those who wanted to seriously discuss alternatives to functools.partial.

On Mon, Aug 13, 2018 at 2:17 PM, Chris Angelico  wrote:

> On Tue, Aug 14, 2018 at 5:08 AM, Abe Dillon  wrote:
> > The whole point of a programming language is to bridge the gap between
> > machine code and natural language (in Python's case English, as with most
> > other languages). It's to make reading and writing code easier through
> > abstraction, not to create ivory towers through the use of esoteric
> jargon.
> > It's not supposed to make a cool kids club for people privileged enough
> to
> > study CS in college. At least that's not my goal.
>
> The whole point of a car is to make driving easier through abstracting
> away the internal details of petrochemical propulsion, but if someone
> says "I don't want to know about 'gears' or 'brakes' or any of these
> technical terms", you wouldn't want them driving on the roads you're
> on. There is a certain level of comprehension that you can't avoid.
> (If you don't know anything about how to use a car, you can still ride
> in one, but you can't drive it; and you don't need to understand about
> anonymous functions in order to operate a computer, but you'll need
> them to program effectively.)
>
> > As someone who has taught Python professionally, I can say that there is
> a
> > strange mental block regarding lambda expressions. Pretty much every
> student
> > I've had has struggled with lambda expressions, even those who grasp
> > similarly complex constructs like decorators with ease. This includes
> > students who learned english as a second language. I can only attribute
> that
> > to the word 'lambda' being confusing as hell.
>
> As someone who currently teaches both Python AND JavaScript
> professionally, I can say that there is a strange mental block
> regarding anonymous functions, and it's nothing to do with the word
> "lambda". In JavaScript, anonymous functions are created with the word
> "function" (same word as is used for declared functions), and there
> are just as many points of confusion as there are with Python.
>
> ChrisA
> ___
> 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] Syntactic sugar to declare partial functions

[MRAB]

On 2018-08-13 20:08, Abe Dillon wrote:

[Bruce Leban]

Lambda calculus IS computer science.

It's a foundation of computer science. That doesn't mean it "IS" 
computer science. Set theory is a foundation of computer science. It's 
still it's own discipline.



[snip]
The word "is" can mean, among other things, class membership or 
identify. Bruce was talking about class membership, not identity.

___
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] Syntactic sugar to declare partial functions

[Chris Angelico]

On Tue, Aug 14, 2018 at 5:08 AM, Abe Dillon  wrote:
> The whole point of a programming language is to bridge the gap between
> machine code and natural language (in Python's case English, as with most
> other languages). It's to make reading and writing code easier through
> abstraction, not to create ivory towers through the use of esoteric jargon.
> It's not supposed to make a cool kids club for people privileged enough to
> study CS in college. At least that's not my goal.

The whole point of a car is to make driving easier through abstracting
away the internal details of petrochemical propulsion, but if someone
says "I don't want to know about 'gears' or 'brakes' or any of these
technical terms", you wouldn't want them driving on the roads you're
on. There is a certain level of comprehension that you can't avoid.
(If you don't know anything about how to use a car, you can still ride
in one, but you can't drive it; and you don't need to understand about
anonymous functions in order to operate a computer, but you'll need
them to program effectively.)

> As someone who has taught Python professionally, I can say that there is a
> strange mental block regarding lambda expressions. Pretty much every student
> I've had has struggled with lambda expressions, even those who grasp
> similarly complex constructs like decorators with ease. This includes
> students who learned english as a second language. I can only attribute that
> to the word 'lambda' being confusing as hell.

As someone who currently teaches both Python AND JavaScript
professionally, I can say that there is a strange mental block
regarding anonymous functions, and it's nothing to do with the word
"lambda". In JavaScript, anonymous functions are created with the word
"function" (same word as is used for declared functions), and there
are just as many points of confusion as there are with Python.

ChrisA
___
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] Syntactic sugar to declare partial functions

[Abe Dillon]

[Bruce Leban]

> Lambda calculus IS computer science.

It's a foundation of computer science. That doesn't mean it "IS" computer
science. Set theory is a foundation of computer science. It's still it's
own discipline.

 [Bruce Leban]

> Rejecting lambda as CS is as bad as rejecting the + operator because
> that's mathematics.

This is a complete misunderstanding of my argument.

Not all programmers are computer scientists. In fact, not all programmers
are professional. Many, including myself, came from engineering. Many came
from other scientific fields. Many came from finance and all sorts of
fields. Many are teenagers who just want to build a cool website or a video
game or scrape song lyrics for their favorite bands.

The whole point of a programming language is to bridge the gap between
machine code and natural language (in Python's case English, as with most
other languages). It's to make reading and writing code easier through
abstraction, not to create ivory towers through the use of esoteric jargon.
It's not supposed to make a cool kids club for people privileged enough to
study CS in college. At least that's not my goal.

[Bruce Leban]

> Lambda calculus is a model of computation. It was invented about 30 years
> before the name "computer science" but is nonetheless foundational computer
> science.


Yes. I know.

[Bruce Leban]

> If using lambda as a keyword leads people to go and learn about lambda
> calculus that is a good thing.


I don't think the point of Python is to force people to eat their
vegetables. You might think it's a good thing if everyone learns about
Turing machines and the Halting problem and Kolmogorov Complexity and X86
machine code, etc. but that's not what Python is for. I may think that
everyone should learn what I learned in college about electromagnetics and
semiconductor physics, etc. But I'm not arrogant enough to force that on
people who just want to use abstract tools to get some job done.

I didn't realize that my distaste for 'lambda' was such an unheard-of
opinion. I could have sworn that the likes of Guido Van Rossum and Raymond
Hetinger also found the term at least a little troublesome.

As someone who has taught Python professionally, I can say that there is a
strange mental block regarding lambda expressions. Pretty much every
student I've had has struggled with lambda expressions, even those who
grasp similarly complex constructs like decorators with ease. This includes
students who learned english as a second language. I can only attribute
that to the word 'lambda' being confusing as hell.

[Bruce Leban]

> And as to saying a lambda function is an "anonymous function": the
> anonymity is not a property of the function.


Yes, It is:

>>> def func(x): return x*x
>>> func.__name__
'func'
>>> func = lambda x: x*x
>>> func.__name__
''

[Bruce Leban]

> If I assign it to a name, it's no longer anonymous.


That's not how variable assignment works in Python. The name of the
variable doesn't become an attribute of the object assigned to the variable.

[Bruce Leban]

> I can legitimately argue that + in Python is not the + in mathematics
> because the Python mathematical operators operate on integers and floats,
> not real numbers. Therefore we should use a different word like "floatadd".
> Of course not.


My whole point was to be less pedantic, not more pedantic. Pragmatism
should prevail over pedantry. This is why, as I've stated earlier, I know
that lambda expressions aren't going to change any time soon and I'm fine
with that. I consider it a bit of a wart, but whatever. I'm getting really
tired of having to defend this opinion.

Also, this argument makes no sense. Just because there isn't a way to
represent all real numbers in a computer, doesn't mean that integer,
floating point, and fractional addition become different kinds of addition.

On Mon, Aug 13, 2018 at 1:09 PM, Chris Angelico  wrote:

> On Tue, Aug 14, 2018 at 4:00 AM, Bruce Leban  wrote:
> > And as to saying a lambda function is an "anonymous function": the
> anonymity
> > is not a property of the function. If I assign it to a name, it's no
> longer
> > anonymous. Really a "lambda" or "lambda function" is just a function, but
> > "lambda" is a synecdoche for "function created with a lambda expression".
>
> True, but at that point, you get into hairy points of definitions.
> Which of these functions is anonymous?
>
> def do_stuff(callback): ...
>
> do_stuff(do_stuff)
> do_stuff(lambda: 42)
> do_stuff(callback=lambda: 42)
>
> Obviously do_stuff itself has a name. When you pass it a parameter, it
> can access that as "callback", which means the function has been
> assigned to a name. Does it cease to be anonymous? What if you use a
> keyword argument?
>
> Within Python, there's a fairly clear definition: if there is
> something in the source code which sets the function's __name__
> attribute, it's not an anonymous function. So anonymous functions come
> from:
>
> * Lambda expressions, always called 

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Chris Angelico]

On Tue, Aug 14, 2018 at 4:00 AM, Bruce Leban  wrote:
> And as to saying a lambda function is an "anonymous function": the anonymity
> is not a property of the function. If I assign it to a name, it's no longer
> anonymous. Really a "lambda" or "lambda function" is just a function, but
> "lambda" is a synecdoche for "function created with a lambda expression".

True, but at that point, you get into hairy points of definitions.
Which of these functions is anonymous?

def do_stuff(callback): ...

do_stuff(do_stuff)
do_stuff(lambda: 42)
do_stuff(callback=lambda: 42)

Obviously do_stuff itself has a name. When you pass it a parameter, it
can access that as "callback", which means the function has been
assigned to a name. Does it cease to be anonymous? What if you use a
keyword argument?

Within Python, there's a fairly clear definition: if there is
something in the source code which sets the function's __name__
attribute, it's not an anonymous function. So anonymous functions come
from:

* Lambda expressions, always called ""
* Comprehensions/genexps, always called "" etc
* Callable objects that aren't functions (or classes, since those have names)
* Maybe something else that I've forgotten.

You're absolutely right that a "lambda function" isn't really a thing,
in the same way that Python doesn't have "raw strings" (only "raw
string literals", which are literals which result in perfectly
ordinary strings). But the anonymity of them is a somewhat measurable
feature, even if it isn't very important. The distinction between
"lambda functions" and "def functions" is important to style guides,
but otherwise shouldn't matter.

ChrisA
___
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] Syntactic sugar to declare partial functions

[Bruce Leban]

On Sun, Aug 12, 2018 at 8:31 PM, Abe Dillon  wrote:

>
> [Steven D'Aprano]
>
>> ...if we aren't even willing to move out of our own comfort zone to
>> the extent of learning accurate jargon terms from our own profession?
>
>
> Very few of us are computer scientists by profession. That's not even
> where 'lambda' comes from. In computer science, it's called an "anonymous
> function". "lambda" comes from lambda calculus.
>

Lambda calculus IS computer science. Rejecting lambda as CS is as bad as
rejecting the + operator because that's mathematics. I can legitimately
argue that + in Python is not the + in mathematics because the Python
mathematical operators operate on integers and floats, not real numbers.
Therefore we should use a different word like "floatadd". Of course not.

Lambda calculus is a model of computation. It was invented about 30 years
before the name "computer science" but is nonetheless foundational computer
science. If using lambda as a keyword leads people to go and learn about
lambda calculus that is a good thing.

And as to saying a lambda function is an "anonymous function": the
anonymity is not a property of the function. If I assign it to a name, it's
no longer anonymous. Really a "lambda" or "lambda function" is just a
function, but "lambda" is a synecdoche for "function created with a lambda
expression".

--- Bruce
___
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] Syntactic sugar to declare partial functions

[Stefan Behnel]

Michel Desmoulin schrieb am 09.08.2018 um 18:59:
> I'd rather have functools.partial() to be added as a new method on
> function objects.
> 
>> from functools import partial
>>
>> def add(x:int,y:int)->int:
>> returnx +y
>>
>> add_2 = partial(add,2)
> 
> Would become:
> 
> add_2 = add.partial(2)

Except that this only works for functions, not for other callables.
Meaning, code that uses this for anything but its self-defined functions
will break as soon as someone passes in a callable object that is not a
function.

Stefan

___
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] Syntactic sugar to declare partial functions

[Alex Walters]

> -Original Message-
> From: Python-ideas  list=sdamon@python.org> On Behalf Of Abe Dillon
> Sent: Monday, August 13, 2018 12:56 AM
> To: Chris Angelico 
> Cc: Python-Ideas 
> Subject: Re: [Python-ideas] Syntactic sugar to declare partial functions
> 
> [Alex Walters]
> 
> 
>   He is questioning the concept that the lambda keyword has caused
> any harm.  You assert that it caused minor harm.  Minor harm can still be 
> real,
> significant, and non-trivial.
> 
> What, exactly, is the difference between "minor" and "non-trivial" and when
> did I say the harm was "significant and non-trivial"?
> 
> [Alex Walters]
> 
> 
>   You will find no evidence to support your argument.
> 
> 
> You could read what I wrote to Neil Girdhar who was able to engage with me
> without implying that I've lost my mind.

I never said or implied that you lost your mind.  Only that you were wrong.  It 
is possible to be wrong and sane.  However if you really insist that the two 
are one in the same... you might actually need to seek out professional help.

> 
> [Chris Angelico]
> 
> 
>   If your reaction was extreme, saying so isn't attacking you.
> 
> Is this a hypothetical now? I said "I think they would (or do in the case of
> 'lambda') harm Python." I wasn't aware the word "harm" was something only
> deranged maniacs use.
> 
> 
> [Chris Angelico]
> 
> 
>   Explain, please, what the HARM is that comes from the use of the
> word
>   "lambda".
> 
> 
> I HAVE.
> 
> [Chris Angelico]
> 
> 
>   Also, the signature is most decidedly NOT obvious from context
> 
> Who decided this? It's been decided by some committee? When you write a
> key function, you don't know how many arguments are going to be passed?
> 
> [Chris Angelico]
> 
> 
>   nor is it insignificant.
> 
> 
> I never said it was. I just said that the logic is more important from the
> standpoint of the reader.
> 
> [Chris Angelico]
> 
> 
>   Putting it first gives context to the body of the
>   function. Python made the correct choice here.
> 
> 
> I disagree.
> 
> This forum is looking more and more toxic. I've explained myself over and
> over again. I just wanted to +1 Steven's original comment. This is 
> ridiculous. I
> guess I've pissed of the good-old-boys by calling out Steven's unnecessary
> condescension. Great. It looks like Python is in fantastic hands.
> 
> On Sun, Aug 12, 2018 at 10:50 PM, Chris Angelico  <mailto:ros...@gmail.com> > wrote:
> 
> 
>   On Mon, Aug 13, 2018 at 1:31 PM, Abe Dillon  <mailto:abedil...@gmail.com> > wrote:
>   > [Steven D'Aprano]
>   >>
>   >> Just because I challenge your statements doesn't mean I'm
> attacking you.
>   >
>   >
>   > No. Telling me I'm having an extreme overreaction means you're
> attacking me.
> 
>   If your reaction was extreme, saying so isn't attacking you.
> 
>   > [Steven D'Aprano]
>   >>
>   >> You've said that the choice of keyword, "lambda", has caused
> harm. Given
>   >> the chance to clarify what you meant, you stood by your
> comment that the
>   >> choice of keyword "lambda" has done real, significant, non-trivial
> harm
>   >> to Python (the language, or the community).
>   >
>   >
>   > What are you talking about? I explained exactly what I meant:
>   >
>   >> 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.
>   >
>   >
>   > Notice: I never said "real, significant, non-trivial harm" anywhere in
> this
>   > entire discussion. I never said anything close to that. Stop jamming
>   > bullshit in my mouth to suit your narrative

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Abe Dillon]

[Chris Angelico]

> lst.onselect = anonfunc(print(target_item))
> What's target_item? If you can't see the signature and see that it's a
> parameter, you should look externally for it.


If you're not even going to read the explanation I've already given, then I
have no reason to respond. Your example looks nothing like what I've
suggested and this whole conversation is being derailed by your need to win
the argument.

On Mon, Aug 13, 2018 at 12:04 AM, Chris Angelico  wrote:

> On Mon, Aug 13, 2018 at 2:56 PM, Abe Dillon  wrote:
> > [Chris Angelico]
> >>
> >> Also, the signature is most decidedly NOT obvious from context
> >
> > Who decided this? It's been decided by some committee? When you write a
> key
> > function, you don't know how many arguments are going to be passed?
>
> lst.onselect = anonfunc(print(target_item))
>
> What's target_item? If you can't see the signature and see that it's a
> parameter, you should look externally for it. What are the parameters
> to an onselect function? Doesn't that seem important enough to see the
> signature up front?
>
> It's not just *how many* arguments are being passed. It's what they're
> called, too. You cannot interpret the body of a function without
> knowing that. Hiding that off to the end would make the language
> worse, not better.
>
> Plus, can you name any similar language that does that? Every other
> language I can think of has the parameters before the body. While this
> isn't a clinching argument by any means (Python has a different
> argument order for the ternary if operator, for instance), it's
> indicative.
>
> ChrisA
> ___
> 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] Syntactic sugar to declare partial functions

[Chris Angelico]

On Mon, Aug 13, 2018 at 2:56 PM, Abe Dillon  wrote:
> [Chris Angelico]
>>
>> Also, the signature is most decidedly NOT obvious from context
>
> Who decided this? It's been decided by some committee? When you write a key
> function, you don't know how many arguments are going to be passed?

lst.onselect = anonfunc(print(target_item))

What's target_item? If you can't see the signature and see that it's a
parameter, you should look externally for it. What are the parameters
to an onselect function? Doesn't that seem important enough to see the
signature up front?

It's not just *how many* arguments are being passed. It's what they're
called, too. You cannot interpret the body of a function without
knowing that. Hiding that off to the end would make the language
worse, not better.

Plus, can you name any similar language that does that? Every other
language I can think of has the parameters before the body. While this
isn't a clinching argument by any means (Python has a different
argument order for the ternary if operator, for instance), it's
indicative.

ChrisA
___
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] Syntactic sugar to declare partial functions

[Abe Dillon]

[Alex Walters]

> He is questioning the concept that the lambda keyword has caused any
> harm.  You assert that it caused minor harm.  Minor harm can still be real,
> significant, and non-trivial.

What, exactly, is the difference between "minor" and "non-trivial" and when
did I say the harm was "significant and non-trivial"?

[Alex Walters]

> You will find no evidence to support your argument.
>
You could read what I wrote to Neil Girdhar who was able to engage with me
without implying that I've lost my mind.

[Chris Angelico]

> If your reaction was extreme, saying so isn't attacking you.

Is this a hypothetical now? I said "*I think* they would (or do in the case
of 'lambda') harm Python." I wasn't aware the word "harm" was something
only deranged maniacs use.

[Chris Angelico]

> Explain, please, what the HARM is that comes from the use of the word
> "lambda".


I HAVE.

[Chris Angelico]

> Also, the signature is most decidedly NOT obvious from context

Who decided this? It's been decided by some committee? When you write a key
function, you don't know how many arguments are going to be passed?

[Chris Angelico]

> nor is it insignificant.


I never said it was. I just said that the logic is more important from the
standpoint of the reader.

[Chris Angelico]

> Putting it first gives context to the body of the
> function. Python made the correct choice here.


I disagree.

This forum is looking more and more toxic. I've explained myself over and
over again. I just wanted to +1 Steven's original comment. This is
ridiculous. I guess I've pissed of the good-old-boys by calling out
Steven's unnecessary condescension. Great. It looks like Python is in
fantastic hands.

On Sun, Aug 12, 2018 at 10:50 PM, Chris Angelico  wrote:

> On Mon, Aug 13, 2018 at 1:31 PM, Abe Dillon  wrote:
> > [Steven D'Aprano]
> >>
> >> Just because I challenge your statements doesn't mean I'm attacking you.
> >
> >
> > No. Telling me I'm having an extreme overreaction means you're attacking
> me.
>
> If your reaction was extreme, saying so isn't attacking you.
>
> > [Steven D'Aprano]
> >>
> >> You've said that the choice of keyword, "lambda", has caused harm. Given
> >> the chance to clarify what you meant, you stood by your comment that the
> >> choice of keyword "lambda" has done real, significant, non-trivial harm
> >> to Python (the language, or the community).
> >
> >
> > What are you talking about? I explained exactly what I meant:
> >
> >> 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.
> >
> >
> > Notice: I never said "real, significant, non-trivial harm" anywhere in
> this
> > entire discussion. I never said anything close to that. Stop jamming
> > bullshit in my mouth to suit your narrative that I'm "extremely
> > overreacting". It's not cute.
>
> Explain, please, what the HARM is that comes from the use of the word
> "lambda". In contrast, using the word "function" does definitely have
> harm, because you can no longer use the name "function" as a variable
> or parameter.
>
> Also, the signature is most decidedly NOT obvious from context, nor is
> it insignificant. Putting it first gives context to the body of the
> function. Python made the correct choice here.
>
> > [Steven D'Aprano]
> >>
> >> But we ought to "check our privilege", as they say. I think that if we
> >> as a community automatically reject any word because it isn't "plain
> >> English", that would be a sign of unexamined privilege and quite rude to
> >> boot.
> >
> >
> > Rude? Who would it be rude to if we had chosen "anonfunc" instead of
> > "lambda"?
>
> No, but it's no less jargonny.
>
> > Very few of us are computer scientists by profession. That's not even
> where
> > 'lambda' comes from. In computer science, it's called an "anonymous
> > function". "lambda" comes from lambda calculus.
>
> https://en.wikipedia.org/wiki/Anonymous_function
>
> "In computer programming, an anonymous function (function literal,
> lambda abstraction, or lambda expression) is a function definition
> that is not bound to an identifier."
>
> So... I would say "lambda" is very firmly connected with anonymous
> functions.
>
> ChrisA
> ___
> 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 

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Chris Angelico]

On Mon, Aug 13, 2018 at 1:31 PM, Abe Dillon  wrote:
> [Steven D'Aprano]
>>
>> Just because I challenge your statements doesn't mean I'm attacking you.
>
>
> No. Telling me I'm having an extreme overreaction means you're attacking me.

If your reaction was extreme, saying so isn't attacking you.

> [Steven D'Aprano]
>>
>> You've said that the choice of keyword, "lambda", has caused harm. Given
>> the chance to clarify what you meant, you stood by your comment that the
>> choice of keyword "lambda" has done real, significant, non-trivial harm
>> to Python (the language, or the community).
>
>
> What are you talking about? I explained exactly what I meant:
>
>> 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.
>
>
> Notice: I never said "real, significant, non-trivial harm" anywhere in this
> entire discussion. I never said anything close to that. Stop jamming
> bullshit in my mouth to suit your narrative that I'm "extremely
> overreacting". It's not cute.

Explain, please, what the HARM is that comes from the use of the word
"lambda". In contrast, using the word "function" does definitely have
harm, because you can no longer use the name "function" as a variable
or parameter.

Also, the signature is most decidedly NOT obvious from context, nor is
it insignificant. Putting it first gives context to the body of the
function. Python made the correct choice here.

> [Steven D'Aprano]
>>
>> But we ought to "check our privilege", as they say. I think that if we
>> as a community automatically reject any word because it isn't "plain
>> English", that would be a sign of unexamined privilege and quite rude to
>> boot.
>
>
> Rude? Who would it be rude to if we had chosen "anonfunc" instead of
> "lambda"?

No, but it's no less jargonny.

> Very few of us are computer scientists by profession. That's not even where
> 'lambda' comes from. In computer science, it's called an "anonymous
> function". "lambda" comes from lambda calculus.

https://en.wikipedia.org/wiki/Anonymous_function

"In computer programming, an anonymous function (function literal,
lambda abstraction, or lambda expression) is a function definition
that is not bound to an identifier."

So... I would say "lambda" is very firmly connected with anonymous functions.

ChrisA
___
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] Syntactic sugar to declare partial functions

[Alex Walters]

> [Steven D'Aprano]
> 
> 
>   You've said that the choice of keyword, "lambda", has caused harm.
> Given
>   the chance to clarify what you meant, you stood by your comment
> that the
>   choice of keyword "lambda" has done real, significant, non-trivial
> harm
>   to Python (the language, or the community).
> 
> 
> What are you talking about? I explained exactly what I meant:
> 
> 
> 
>   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.
> 
> 
> Notice: I never said "real, significant, non-trivial harm" anywhere in this
> entire discussion. I never said anything close to that. Stop jamming bullshit 
> in
> my mouth to suit your narrative that I'm "extremely overreacting". It's not
> cute.
> 

He is questioning the concept that the lambda keyword has caused any harm.  You 
assert that it caused minor harm.  Minor harm can still be real, significant, 
and non-trivial.  Has the keyword choice done any harm aside from mailing list 
jamming, and forum posts.  I believe he is asserting that it hasn't.  The 
burden of proof would be on you that it has caused any level of harm to the 
language of community, the criteria being that the harm be real, significant 
(if minor) and non-trivial.

You will find no evidence to support your argument.  You might find evidence 
that functional programming techniques are less useful with anonymous functions 
in python due to the restriction to only use expressions, but that isn't what 
is being argued.

___
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] Syntactic sugar to declare partial functions

[Abe Dillon]

[Steven D'Aprano]

> Just because I challenge your statements doesn't mean I'm attacking you.


No. Telling me I'm having an extreme overreaction means you're attacking
me. Pushing the narrative that I'm irrational by enumerating the least
charitable interpretations of my words possible then claiming you were just
discussing *ideas* is disingenuous. I don't know who you think you're
kidding, Steven. You could have simply asked me what I meant. It would have
been much easier. All those extra words serve a very clear purpose and
everyone knows it, so you can stop acting "sad and worried" when someone
calls you out.

I explained my position on lambda as fully as I care to in my response to
Niel if you care to read it. I only think lambda harms Python in so far as
there were better alternatives that communicate their intention much better
and are more readable. That's an opinion. If you must know, i'm not
currently frothing at the mouth as I state it.

My original post was agreeing with you. Supporting your own words. If you
don't agree with my position that we should avoid jargon for jargon's sake,
then what exactly did you mean when you said, "although possibly a less
jargon name would be nicer?" Can you articulate why you think it might be
nicer to use a less jargon name? What about my saying it all of a sudden
makes it an "extreme overreaction"?

[Steven D'Aprano]

> You've said that the choice of keyword, "lambda", has caused harm. Given
> the chance to clarify what you meant, you stood by your comment that the
> choice of keyword "lambda" has done real, significant, non-trivial harm
> to Python (the language, or the community).


What are you talking about? I explained exactly what I meant:

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.


Notice: I never said "real, significant, non-trivial harm" anywhere in this
entire discussion. I never said anything close to that. Stop jamming
bullshit in my mouth to suit your narrative that I'm "extremely
overreacting". It's not cute.

[Steven D'Aprano]

> This is a genuine question. I'm trying to understand your comments, not just
> dismiss them.


If you're so genuinely interested, then how come you couldn't be bothered
to read my explaination above?

[Steven D'Aprano]

> Presumably you fear the same thing will happen again if we choose
> "partial" (otherwise, why raise the issue?).


There is no issue. I've already conceded that. Please read the conversation
that followed with Neil Girdhar. I was simply stating a preference and
trying to articulate my reasoning behind that preference.

My whole intent was to +1 your alternative and say "I prefer given to
partial". That's it.

[Steven D'Aprano]

> Python does have a long-standing tradition of sticking to mostly English
> words, a tradition for which I personally am grateful.


I am too. I'd like that to continue.

[Steven D'Aprano]

> But we ought to "check our privilege", as they say. I think that if we
> as a community automatically reject any word because it isn't "plain
> English", that would be a sign of unexamined privilege and quite rude to
> boot.


Rude? Who would it be rude to if we had chosen "anonfunc" instead of
"lambda"?

[Steven D'Aprano]

> How can we insist that 3/4 of the world learn English words to use Python


Do you really think that 3/4 of the world learns English just to write
Python? Do you think the only english they learn are the built-ins and
standard library of Python? English is a dominant language in business and
programming. That statement is no more "privileged" than the statement that
the US Dollar is the most popular global reserve currency. It's a fact that
I have no control over.

[Steven D'Aprano]

> ...if we aren't even willing to move out of our own comfort zone to
> the extent of learning accurate jargon terms from our own profession?


Very few of us are computer scientists by profession. That's not even where
'lambda' comes from. In computer science, it's called an "anonymous
function". "lambda" comes from lambda calculus.

[Steven D'Aprano]

> If we go down this path... and choose "given" over "partial", we ought to
> be
> clear about the reasons why.


I gave my reasons: it's shorter and less jargon while remaining fairly
clear (in my opinion)

You've already claimed that "possibly a less jargon name would be nicer",
so I don't see the fuss. Apparently it's extreme when I say it.

On Sun, Aug 12, 2018 at 8:06 PM, Steven D'Aprano 
wrot

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Steven D'Aprano]

Answering a few of Abe's comments out of order...

On Fri, Aug 10, 2018 at 05:20:25PM -0500, Abe Dillon wrote:
> I didn't realize I'd hit such a nerve. [...] I'm truly sorry
> if I hurt your feelings.
[...]
> 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.

Have we become so sensitive to disagreement that criticism of ideas is
immediately seen as "angry", "a grudge", "outrage"? If so, I find that 
sad and worrying.

My feelings aren't hurt, you haven't hit a nerve, I'm not angry at
anything you wrote, and I'm not holding a grudge. I thought we were
discussing *ideas*, not attacking each other. Just because I challenge 
your statements doesn't mean I'm attacking you.

Moving on...

[...]
> I suspect that most programmers couldn't describe the difference
> between a type and a class.

In Python, there is none.

There is a sense in which types are different from classes, but that
sense is not fundamental, and in practice many languages blur the lines
between them.


> I suspect that most programmers couldn't tell you the difference 
> between an exception or an error.

There's a school of thought that most programmers can't program.

https://blog.codinghorror.com/why-cant-programmers-program/

But regardless, we don't design Python based on the misunderstandings of
the least competent, most ignorant demographic. That's why we have
exceptions, only some of which are errors, and not

StopIterationError
KeyboardInterruptError
SystemExitError

etc.

I believe that using a well-designed language should gently encourage
the programmer to learn, by example. I didn't know the the functional
programming techniques of map, reduce or partial until I came across
them in Python. I think I'm a better programmer and less ignorant now
than I was for that.

Consequently, when I hear you describing how few programmers know the 
term "partial", what I think is "what a great opportunity for them to 
learn something new!".

Or not, of course. For those of us who don't care for functional 
programming idioms, there's no need to use partial in our own code.


> [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?

Yes, that's what I got out of your sentence. If you don't mean that, I
don't know what you do mean.

You've said that the choice of keyword, "lambda", has caused harm. Given
the chance to clarify what you meant, you stood by your comment that the
choice of keyword "lambda" has done real, significant, non-trivial harm
to Python (the language, or the community). Presumably you fear the same
thing will happen again if we choose "partial" (otherwise, why raise the
issue?).

Harm in what sense? That's what I tried to ask earlier, perhaps not as
clearly as I intended.

If the choice of name "lambda" doesn't repel would-be users, or cause 
bugs, or harm performance, then what harm does it do?

This is a genuine question. I'm trying to understand your comments, not
just dismiss them.

You made a comment much stronger than merely "I don't like the name", 
claiming that the name is harmful. I could just dismiss your comment as 
meaningless hyperbole and ignore it, but I thought to give you the 
respect of assuming that you might be correct but I just wasn't 
understanding why. Hence my question.


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

No, we ought to stick to ASCII, for reasons I've discussed recently in 
other threads. And Python does have a long-standing tradition of 
sticking to mostly English words, a tradition for which I personally am 
grateful.

But we ought to "check our privilege", as they say. I think that if we 
as a community automatically reject any word because it isn't "plain 
English", that would be a sign of unexamined privilege and quite rude to 
boot. How can we insist that 3/4 of the world learn English words to use 
Python, if we aren't even willing to move out of our own comfort zone to 
the extent of learning accurate jargon terms from our own profession?

None of this is to rule out "given". (I think it's certainly better than 
Perl's choice of "assuming".) But if we go down this path (which is by 
no means decided!), and choose "given" over "partial", we ought to be 
clear about the reasons why.


-- 
Steve
__

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

Therefore one can do a decorator that gives .partial:

def partialize(f):
from functools import partial
f.partial = lambda *a, **b: partial(f, *a, **b)
return f

@partialize
def f(x,y):
return x-y

g = f.partial(5)
g(3)

That's the same idea as funcoperators.partially but doesn't return a new
function (which has the advantage of keeping help(f))

Le sam. 11 août 2018 à 14:53, Robert Vanden Eynde  a
écrit :

>
>
> Le sam. 11 août 2018 à 10:34, Vincent Maillol 
> a écrit :
>
>> Hello,
>>
>> Currently the user defined functions are mutables, there can be existed
>> python codes like this:
>>
>> >>> def foo():
>> ... pass
>> ...
>> >>> if not hasattr(foo, 'partial'):
>> ... foo.partial = {}
>> ...
>>
>> Adding a new method to function object can break existing projects, but
>> it is without impact with buit-in functions because they are immutables.
>>
>>
> Or use a decorator like in the lib ?
>
> from funcoperators import partially
>
> @partially
> def f(x, y):
> return x-y
>
> g = f.part(4)
> g(5)
>
> The mutability solution however cannot have a "self" argument :
>
> def f(x,y):
> return x-y
>
> f.stuff = lambda self: self(5, 2)
> f.stuff()  # missing self
>
> One would have to give "f".
>
> f.partial = lambda *a, **b: functools.partial(f, *a, **b)
>
> g = f.partial(4)
> g(5)
>
>
>> 2018-08-09 18:59 GMT+02:00 Michel Desmoulin :
>>
>>> I'd rather have functools.partial() to be added as a new method on
>>> function objects.
>>>
>>> >
>>> > fromfunctools importpartial
>>> >
>>> >
>>> > def add(x:int,y:int)->int:
>>> > returnx +y
>>> >
>>> >
>>> > add_2 = partial(add,2)
>>> >
>>>
>>> Would become:
>>>
>>> add_2 = add.partial(2)
>>>
>>> Nothing to change on the parser, no obscure syntax for future readers,
>>> and we can get the opportunity of rewriting partial() in C as right now
>>> it is amazingly way, way slower than a lambda.
>>> ___
>>> 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 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] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

Le sam. 11 août 2018 à 10:34, Vincent Maillol  a
écrit :

> Hello,
>
> Currently the user defined functions are mutables, there can be existed
> python codes like this:
>
> >>> def foo():
> ... pass
> ...
> >>> if not hasattr(foo, 'partial'):
> ... foo.partial = {}
> ...
>
> Adding a new method to function object can break existing projects, but it
> is without impact with buit-in functions because they are immutables.
>
>
Or use a decorator like in the lib ?

from funcoperators import partially

@partially
def f(x, y):
return x-y

g = f.part(4)
g(5)

The mutability solution however cannot have a "self" argument :

def f(x,y):
return x-y

f.stuff = lambda self: self(5, 2)
f.stuff()  # missing self

One would have to give "f".

f.partial = lambda *a, **b: functools.partial(f, *a, **b)

g = f.partial(4)
g(5)


> 2018-08-09 18:59 GMT+02:00 Michel Desmoulin :
>
>> I'd rather have functools.partial() to be added as a new method on
>> function objects.
>>
>> >
>> > fromfunctools importpartial
>> >
>> >
>> > def add(x:int,y:int)->int:
>> > returnx +y
>> >
>> >
>> > add_2 = partial(add,2)
>> >
>>
>> Would become:
>>
>> add_2 = add.partial(2)
>>
>> Nothing to change on the parser, no obscure syntax for future readers,
>> and we can get the opportunity of rewriting partial() in C as right now
>> it is amazingly way, way slower than a lambda.
>> ___
>> 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 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] Syntactic sugar to declare partial functions

[Vincent Maillol]

Hello,

Currently the user defined functions are mutables, there can be existed
python codes like this:

>>> def foo():
... pass
...
>>> if not hasattr(foo, 'partial'):
... foo.partial = {}
...

Adding a new method to function object can break existing projects, but it
is without impact with buit-in functions because they are immutables.


2018-08-09 18:59 GMT+02:00 Michel Desmoulin :

> I'd rather have functools.partial() to be added as a new method on
> function objects.
>
> >
> > fromfunctools importpartial
> >
> >
> > def add(x:int,y:int)->int:
> > returnx +y
> >
> >
> > add_2 = partial(add,2)
> >
>
> Would become:
>
> add_2 = add.partial(2)
>
> Nothing to change on the parser, no obscure syntax for future readers,
> and we can get the opportunity of rewriting partial() in C as right now
> it is amazingly way, way slower than a lambda.
> ___
> 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] Syntactic sugar to declare partial functions

[Abe Dillon]

[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
, 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  wrote:

>
>
> On Fri, Aug 10, 2018 at 6:21 PM Abe Dillon  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 

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Neil Girdhar]

On Fri, Aug 10, 2018 at 6:21 PM Abe Dillon  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
>> w

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Abe Dillon]

[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).

[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?

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

Hon

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Steven D'Aprano]

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@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Syntactic sugar to declare partial functions

[Jacco van Dorp]

I actually really like the method-on-function-object syntax. +1, for
what it's worth from someone like me.

2018-08-10 0:46 GMT+02:00 Neil Girdhar :
> I prefer partial since many programmers studied computer science, and also
> it makes the concepts easier to google.
>
> Anyway, I don't actually want either a partial member nor new syntax for
> this, but if I had to choose, I'd choose no new syntax.
>
> On Thu, Aug 9, 2018 at 2:32 PM 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. Words like 'partial', 'curry', 'lambda', and 'closure' are
>> fine for text books, published papers, and technical discussion, but I think
>> they would (or do in the case of 'lambda') harm Python. I know the correct
>> term for the 'if-else' expression is a 'ternary' expression, but that
>> doesn't mean Python should have used the word 'ternary' in the syntax.
>>
>> On Thu, Aug 9, 2018 at 12:14 PM, Neil Girdhar 
>> wrote:
>>>
>>> That's a nicer solution to me.
>>>
>>> On Thu, Aug 9, 2018 at 1:00 PM Michel Desmoulin
>>>  wrote:

 I'd rather have functools.partial() to be added as a new method on
 function objects.

 >
 > fromfunctools importpartial
 >
 >
 > def add(x:int,y:int)->int:
 > returnx +y
 >
 >
 > add_2 = partial(add,2)
 >

 Would become:

 add_2 = add.partial(2)

 Nothing to change on the parser, no obscure syntax for future readers,
 and we can get the opportunity of rewriting partial() in C as right now
 it is amazingly way, way slower than a lambda.
 ___
 Python-ideas mailing list
 Python-ideas@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+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> ___
>>> 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 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] Syntactic sugar to declare partial functions

[Neil Girdhar]

I prefer partial since many programmers studied computer science, and also
it makes the concepts easier to google.

Anyway, I don't actually want either a partial member nor new syntax for
this, but if I had to choose, I'd choose no new syntax.

On Thu, Aug 9, 2018 at 2:32 PM 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. Words like 'partial', 'curry', 'lambda', and 'closure' are
> fine for text books, published papers, and technical discussion, but I
> think they would (or do in the case of 'lambda') harm Python. I know the
> correct term for the 'if-else' expression is a 'ternary' expression, but
> that doesn't mean Python should have used the word 'ternary' in the syntax.
>
> On Thu, Aug 9, 2018 at 12:14 PM, Neil Girdhar 
> wrote:
>
>> That's a nicer solution to me.
>>
>> On Thu, Aug 9, 2018 at 1:00 PM Michel Desmoulin <
>> desmoulinmic...@gmail.com> wrote:
>>
>>> I'd rather have functools.partial() to be added as a new method on
>>> function objects.
>>>
>>> >
>>> > fromfunctools importpartial
>>> >
>>> >
>>> > def add(x:int,y:int)->int:
>>> > returnx +y
>>> >
>>> >
>>> > add_2 = partial(add,2)
>>> >
>>>
>>> Would become:
>>>
>>> add_2 = add.partial(2)
>>>
>>> Nothing to change on the parser, no obscure syntax for future readers,
>>> and we can get the opportunity of rewriting partial() in C as right now
>>> it is amazingly way, way slower than a lambda.
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@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+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> ___
>> 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] Syntactic sugar to declare partial functions

[Abe Dillon]

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. Words like 'partial', 'curry', 'lambda', and 'closure' are fine
for text books, published papers, and technical discussion, but I think
they would (or do in the case of 'lambda') harm Python. I know the correct
term for the 'if-else' expression is a 'ternary' expression, but that
doesn't mean Python should have used the word 'ternary' in the syntax.

On Thu, Aug 9, 2018 at 12:14 PM, Neil Girdhar  wrote:

> That's a nicer solution to me.
>
> On Thu, Aug 9, 2018 at 1:00 PM Michel Desmoulin 
> wrote:
>
>> I'd rather have functools.partial() to be added as a new method on
>> function objects.
>>
>> >
>> > fromfunctools importpartial
>> >
>> >
>> > def add(x:int,y:int)->int:
>> > returnx +y
>> >
>> >
>> > add_2 = partial(add,2)
>> >
>>
>> Would become:
>>
>> add_2 = add.partial(2)
>>
>> Nothing to change on the parser, no obscure syntax for future readers,
>> and we can get the opportunity of rewriting partial() in C as right now
>> it is amazingly way, way slower than a lambda.
>> ___
>> Python-ideas mailing list
>> Python-ideas@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+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> ___
> 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] Syntactic sugar to declare partial functions

[Neil Girdhar]

That's a nicer solution to me.

On Thu, Aug 9, 2018 at 1:00 PM Michel Desmoulin 
wrote:

> I'd rather have functools.partial() to be added as a new method on
> function objects.
>
> >
> > fromfunctools importpartial
> >
> >
> > def add(x:int,y:int)->int:
> > returnx +y
> >
> >
> > add_2 = partial(add,2)
> >
>
> Would become:
>
> add_2 = add.partial(2)
>
> Nothing to change on the parser, no obscure syntax for future readers,
> and we can get the opportunity of rewriting partial() in C as right now
> it is amazingly way, way slower than a lambda.
> ___
> Python-ideas mailing list
> Python-ideas@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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
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] Syntactic sugar to declare partial functions

[Michel Desmoulin]

I'd rather have functools.partial() to be added as a new method on
function objects.

>
> fromfunctools importpartial
>
>
> def add(x:int,y:int)->int:
> returnx +y
>
>
> add_2 = partial(add,2)
>

Would become:

add_2 = add.partial(2)

Nothing to change on the parser, no obscure syntax for future readers,
and we can get the opportunity of rewriting partial() in C as right now
it is amazingly way, way slower than a lambda.
___
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] Syntactic sugar to declare partial functions

[Neil Girdhar]

By the way, these are not "partial functions", and shouldn't be called 
that.  These are "partial function applications".

On Saturday, August 4, 2018 at 12:03:50 PM UTC-4, Fabrizio Messina wrote:
>
>  
> Hello, I would like to propose a new method to create a partial function.
>
> At the moment we have to load the *partial* function from the *functool* 
> library, and apply it to an existing function, e.g. 
>
> from functools import partial
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
>
> add_2 = partial(add, 2)
>
>
>
> While partial expose the mechanism excellently its instantiation method 
> is, at times, not very friendly, I would like to propose a syntactic sugar 
> to create partial functions, in the case you create a partial function 
> using *curly braces*:
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
> add_2 = add{2}
>
>
> At the moment this causes SyntaxError so the change is retro-compatible.
>
> In the case of key word arguments we could have:
>
> sort_by_x = sort{key=lambda element: element.x}
>
>
> That could be good as it would be an easy way to pre-load functions 
> without having to eagerly compute it, but without needing to pass the 
> entire function parameters to to other scopes.
>
>
> # prepare the function
> get_sorted_users: Callable[[], Iterator[User]] = sort{users, key=lambda 
> user: user.creation_date}
>
> # continue with job at hand
> ...
>
> # some where else, maybe another process
> sorted_users = list(get_sorted_users())
>
>
>
> Even create a factory method on the fly:
> @dataclass
> class Product:
> name: str
> category: Category
> price: Decimal
>
>
> smartphone_factory = Product{category=smartphone_category}
>
>
>
> Now all this can already be done with partial, but adding this syntactic 
> sugar would reduce the perception of `partial` as an advanced feature, 
> alleviating the use of closures created only for the sake of avoiding an 
> explicit partial.
>
> In my opinion this syntactic sugar has a lot of potential adoption seen 
> the general interest in functional programming.
>
___
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] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

You can read the other functionalities on the project page :
https://pypi.org/project/funcoperators/

And if you want to solve the "can't partial from right that allows to use
the Ellipsis '...' :

# the built-in "pow" doesn't take keyword arguments, so partial can't be
used.

from funcoperators import elipartial, bracket

square = elipartial (pow, ..., 2)  # = pow(something, 2)

square(3)  # 9

@bracket
def f(x,y,z):
return x - y + 2 * z

r = f(1,2,3)
g = f[1, ..., 3]  # g = a function with one argument: y
r = g(2)

bracket merges the concept of partiallymulti, and elipartial. Partially
Multi allowing to write f[1, 2] as a sugar for f[1][2] (which is different
than partial(f, (1,2)) ).

Le dim. 5 août 2018 à 00:18, Daniel.  a écrit :

> That's an awesome library! Congratulation for doing this and thanks for
> sharing!
>
> Em sáb, 4 de ago de 2018 às 13:42, Robert Vanden Eynde <
> robertv...@gmail.com> escreveu:
>
>> The funcoperators lib on pypi does exactly that:
>>
>> from funcoperators import partially
>>
>> @partially
>> def add(x: int, y: int) -> int:
>> return x + y
>>
>> add_2 = add[2]
>>
>> @partiallymulti
>> def stuff(x,y,z):
>> return x - y + 2*z
>>
>> sort = partially(sorted)
>> sort_by_x = sort.key(key=lambda element: element.x)
>>
>> The ".key" means "give a keyword argument".
>> The ".val" or [] gives a positional argument.
>> The ".part" accept positional and keyword arguments.
>>
>> Le sam. 4 août 2018 à 18:03, Fabrizio Messina  a
>> écrit :
>>
>>>
>>> Hello, I would like to propose a new method to create a partial function.
>>>
>>> At the moment we have to load the *partial* function from the *functool*
>>> library, and apply it to an existing function, e.g.
>>>
>>> from functools import partial
>>>
>>>
>>> def add(x: int, y: int) -> int:
>>> return x + y
>>>
>>>
>>> add_2 = partial(add, 2)
>>>
>>>
>>>
>>> While partial expose the mechanism excellently its instantiation method
>>> is, at times, not very friendly, I would like to propose a syntactic sugar
>>> to create partial functions, in the case you create a partial function
>>> using *curly braces*:
>>>
>>>
>>> def add(x: int, y: int) -> int:
>>> return x + y
>>>
>>> add_2 = add{2}
>>>
>>>
>>> At the moment this causes SyntaxError so the change is retro-compatible.
>>>
>>> In the case of key word arguments we could have:
>>>
>>> sort_by_x = sort{key=lambda element: element.x}
>>>
>>>
>>> That could be good as it would be an easy way to pre-load functions
>>> without having to eagerly compute it, but without needing to pass the
>>> entire function parameters to to other scopes.
>>>
>>>
>>> # prepare the function
>>> get_sorted_users: Callable[[], Iterator[User]] = sort{users, key=lambda
>>> user: user.creation_date}
>>>
>>> # continue with job at hand
>>> ...
>>>
>>> # some where else, maybe another process
>>> sorted_users = list(get_sorted_users())
>>>
>>>
>>>
>>> Even create a factory method on the fly:
>>> @dataclass
>>> class Product:
>>> name: str
>>> category: Category
>>> price: Decimal
>>>
>>>
>>> smartphone_factory = Product{category=smartphone_category}
>>>
>>>
>>>
>>> Now all this can already be done with partial, but adding this syntactic
>>> sugar would reduce the perception of `partial` as an advanced feature,
>>> alleviating the use of closures created only for the sake of avoiding an
>>> explicit partial.
>>>
>>> In my opinion this syntactic sugar has a lot of potential adoption seen
>>> the general interest in functional programming.
>>> ___
>>> 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/
>>
>
>
> --
> “If you're going to try, go all the way. Otherwise, don't even start. ..."
>   Charles Bukowski
>
___
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] Syntactic sugar to declare partial functions

[Daniel.]

That's an awesome library! Congratulation for doing this and thanks for
sharing!

Em sáb, 4 de ago de 2018 às 13:42, Robert Vanden Eynde 
escreveu:

> The funcoperators lib on pypi does exactly that:
>
> from funcoperators import partially
>
> @partially
> def add(x: int, y: int) -> int:
> return x + y
>
> add_2 = add[2]
>
> @partiallymulti
> def stuff(x,y,z):
> return x - y + 2*z
>
> sort = partially(sorted)
> sort_by_x = sort.key(key=lambda element: element.x)
>
> The ".key" means "give a keyword argument".
> The ".val" or [] gives a positional argument.
> The ".part" accept positional and keyword arguments.
>
> Le sam. 4 août 2018 à 18:03, Fabrizio Messina  a
> écrit :
>
>>
>> Hello, I would like to propose a new method to create a partial function.
>>
>> At the moment we have to load the *partial* function from the *functool*
>> library, and apply it to an existing function, e.g.
>>
>> from functools import partial
>>
>>
>> def add(x: int, y: int) -> int:
>> return x + y
>>
>>
>> add_2 = partial(add, 2)
>>
>>
>>
>> While partial expose the mechanism excellently its instantiation method
>> is, at times, not very friendly, I would like to propose a syntactic sugar
>> to create partial functions, in the case you create a partial function
>> using *curly braces*:
>>
>>
>> def add(x: int, y: int) -> int:
>> return x + y
>>
>> add_2 = add{2}
>>
>>
>> At the moment this causes SyntaxError so the change is retro-compatible.
>>
>> In the case of key word arguments we could have:
>>
>> sort_by_x = sort{key=lambda element: element.x}
>>
>>
>> That could be good as it would be an easy way to pre-load functions
>> without having to eagerly compute it, but without needing to pass the
>> entire function parameters to to other scopes.
>>
>>
>> # prepare the function
>> get_sorted_users: Callable[[], Iterator[User]] = sort{users, key=lambda
>> user: user.creation_date}
>>
>> # continue with job at hand
>> ...
>>
>> # some where else, maybe another process
>> sorted_users = list(get_sorted_users())
>>
>>
>>
>> Even create a factory method on the fly:
>> @dataclass
>> class Product:
>> name: str
>> category: Category
>> price: Decimal
>>
>>
>> smartphone_factory = Product{category=smartphone_category}
>>
>>
>>
>> Now all this can already be done with partial, but adding this syntactic
>> sugar would reduce the perception of `partial` as an advanced feature,
>> alleviating the use of closures created only for the sake of avoiding an
>> explicit partial.
>>
>> In my opinion this syntactic sugar has a lot of potential adoption seen
>> the general interest in functional programming.
>> ___
>> 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/
>


-- 
“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski
___
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] Syntactic sugar to declare partial functions

[Steven D'Aprano]

On Sat, Aug 04, 2018 at 09:03:50AM -0700, Fabrizio Messina wrote:

> At the moment we have to load the *partial* function from the *functool* 
> library, and apply it to an existing function
[...]

> While partial expose the mechanism excellently its instantiation method is, 
> at times, not very friendly,

I disagree with *both* of those statements.

As an implementation of partial function application, partial() has a 
couple of weaknesses:

- no support for applying arguments from the right, except by keyword;

- no automatic or easy way to inherit docstrings from the original
  function;

- even if you manually set the partial function object's docstring,
  help() ignores it. (That's possibly not partial's fault.)


On the other hand, I think that

   partial(func, arg, kw=value)

is plenty friendly.



> I would like to propose a syntactic sugar to 
> create partial functions, in the case you create a partial function using 
> *curly 
> braces*:
[...]

> add_2 = add{2}

Too obscure. What do curly braces have to do with partial function 
application? It seems pretty arbitrary.

I know that ultimately ALL conventions are arbitrary, but we already 
have a couple of very strong conventions for curly braces (dicts and 
sets) and mathematicians have a few strong conventions for partial 
function application and currying, neither of which uses curly brackets.

Besides, if we ever did support some sort of function-call-like syntax 
using braces spam{...} I would hope it would be for something more 
important than partial function application.


You should consider prior art:

- Scala uses a special value, which when passed to a function, 
  returns a new function:

  # using Python syntax
  def add(a, b): return a+b

  add1 = add(1, _)  # like partial(add, 1)


- Perl6 gives all functions an "assuming" method:

  add1 = add.assuming(1)


- ML and Haskell define all functions as single-argument functions.
  Multiple arguments are actually just syntactic sugar:

  func(a, b, c)  # syntactic sugar for func(a)(b)(c)

  so partial application from the left is trivial:

  add1 = add(1)


- but most other languages that I know of use a function or keyword 
  "partial" (or sometimes, and inaccurately, "curry").



> Now all this can already be done with partial,

Indeed it can.


> but adding this syntactic 
> sugar would reduce the perception of `partial` as an advanced feature, 
> alleviating the use of closures created only for the sake of avoiding an 
> explicit partial.

I don't think that is the case. I think that partial, and currying, are 
both relatively advanced features. Many programmers never quite grasp, 
or become comfortable with, functions as values.


If we were to push partial application as a mainstream technique, and 
I'm not saying we should, but if we did, my vote would be to give 
function (and method) objects a partial method:

add1 = add.partial(1)

although possibly a less jargon name would be nicer:

add1 = add.given(1)



-- 
Steve
___
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] Syntactic sugar to declare partial functions

[Jonathan Fine]

Here's my opinion, in a nutshell.

A diet with a small amount of sugar is healthy. But too much sugar is not.
https://www.nhs.uk/live-well/eat-well/how-does-sugar-in-our-diet-affect-our-health/

I have a similar attitude to syntactic sugar. Sometimes helpful.
https://news.ycombinator.com/item?id=16216994

Sometimes, perhaps not helpful.
https://github.com/benthor/dictator
https://github.com/czheo/syntax_sugar_python

Every programming construct has semantics.  Here's a suggestion.

If you're proposing a syntax change, give a pure Python implementation
of the semantics. For example (not tested).

The construction
>>> EXP_1 or EXP_2
is equivalent to
>>> OR(lambda: EXP_1, lambda:EXP_2)
where we have
>>> def OR(fn_1, fn_2):
>>> ...val = fn_1()
>>> ...if val: return val
>>> ...return fn_2()

And if your proposal works with current Python, write and publish a
pure Python implementation. And help others use it, listening to their
feedback. So do it on github or the like, with an issue tracker.

In short, if you have a proposal, publish some working code that
implements the proposal.

-- 
Jonathan
___
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] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

> @partiallymulti
> def stuff(x,y,z):
> return x - y + 2*z
>

f = stuff[1,2]
f(4)
___
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] Syntactic sugar to declare partial functions

[Robert Vanden Eynde]

The funcoperators lib on pypi does exactly that:

from funcoperators import partially

@partially
def add(x: int, y: int) -> int:
return x + y

add_2 = add[2]

@partiallymulti
def stuff(x,y,z):
return x - y + 2*z

sort = partially(sorted)
sort_by_x = sort.key(key=lambda element: element.x)

The ".key" means "give a keyword argument".
The ".val" or [] gives a positional argument.
The ".part" accept positional and keyword arguments.

Le sam. 4 août 2018 à 18:03, Fabrizio Messina  a
écrit :

>
> Hello, I would like to propose a new method to create a partial function.
>
> At the moment we have to load the *partial* function from the *functool*
> library, and apply it to an existing function, e.g.
>
> from functools import partial
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
>
> add_2 = partial(add, 2)
>
>
>
> While partial expose the mechanism excellently its instantiation method
> is, at times, not very friendly, I would like to propose a syntactic sugar
> to create partial functions, in the case you create a partial function
> using *curly braces*:
>
>
> def add(x: int, y: int) -> int:
> return x + y
>
> add_2 = add{2}
>
>
> At the moment this causes SyntaxError so the change is retro-compatible.
>
> In the case of key word arguments we could have:
>
> sort_by_x = sort{key=lambda element: element.x}
>
>
> That could be good as it would be an easy way to pre-load functions
> without having to eagerly compute it, but without needing to pass the
> entire function parameters to to other scopes.
>
>
> # prepare the function
> get_sorted_users: Callable[[], Iterator[User]] = sort{users, key=lambda
> user: user.creation_date}
>
> # continue with job at hand
> ...
>
> # some where else, maybe another process
> sorted_users = list(get_sorted_users())
>
>
>
> Even create a factory method on the fly:
> @dataclass
> class Product:
> name: str
> category: Category
> price: Decimal
>
>
> smartphone_factory = Product{category=smartphone_category}
>
>
>
> Now all this can already be done with partial, but adding this syntactic
> sugar would reduce the perception of `partial` as an advanced feature,
> alleviating the use of closures created only for the sake of avoiding an
> explicit partial.
>
> In my opinion this syntactic sugar has a lot of potential adoption seen
> the general interest in functional programming.
> ___
> 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/