Syntactic sugar to declare partial functions

[Fabrizio Messina]

 

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.

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

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

[Robert Vanden Eynde]

@partiallymulti

def stuff(x,y,z):

    return x - y + 2*z

f = stuff[1,2]

f(4)

[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

[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

[Daniel.]

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

--

“If you're going to try, go all the way. Otherwise, don't even start. ..."
  Charles Bukowski

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

[Neil Girdhar]

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

[Abe Dillon]

[Steven D'Aprano]

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)

I like this version. It gets my +1 because reaching for partial always feels like more of a hassle than it should be. I would imagine an object that implements a __call__ method would also have to implement a `given` method to support this functionality. Also, stateful decorators that are implemented as a class with a __call__ method that might make this a little confusing, but I still support the idea.

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

[Neil Girdhar]

That's a nicer solution to me.

--

---
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and all its topics, send an email to python-ideas...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jacco van Dorp]

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

[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

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

Honestly, I don't think 'partial' is that bad. I just wanted to support your own comment:

although possibly a less jargon name would be nicer:
    add1 = add.given(1)

But you seem to have some grudge against me. I don't get all the outrage over what I thought was a fairly benign post.
Did I do something to make you so angry at me? I'd like to resolve whatever it is instead of having to deal with this every time I post.

[Neil Girdhar]

On Fri, Aug 10, 2018 at 6:21 PM Abe Dillon <abed...@gmail.com> wrote:

[Neil Girdhar]

I prefer partial since many programmers studied computer science

 
Many did not. I studied electrical engineering and wouldn't have been able to tell you what the word 'partial' meant four years ago even though I've been programming in one form or another since the late nineties. Many programmers are scientists, engineers, financial analysts, etc. I'm pretty sure I know what a closure is or what currying is, but if you put me on the spot, I'd probably turn to Wikipedia to make sure I don't screw up the definition.

[Neil Girdhar]

It makes the concepts easier to google.

That can be an important criteria, but it can also be a red-herring. If an implementation is clear enough, few people would have to google it. If, however, you use obscure enough words like "lambda", people will google it every day and still find it confusing. The ternary expression is difficult to google if you don't know the jargon "ternary", but there's less of a need to google it because it's pretty obvious how it works based simply on its implementation.

[Steven D'Aprano]

It's a clear, *generic* meaning that doesn't have any association with 
partial application.
We'd be trying to create that association from scratch.

Sure, that's a good point. I don't think that sounds like such a big problem, but I also don't hate 'partial'. I just prefer 'given'.
At any rate, I don't find the google-ablilty argument super strong because there are many constructs that are difficult to google, but still pretty great (e.g. comprehensions).

Not that it matters, but comprehension is a standard term in mathematics and computer science apparently:

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

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

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…

  

--

---
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...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

_______________________________________________
Python-ideas mailing list
Python...@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...@googlegroups.com.

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

To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

--

---
You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/jOMinivFCcQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

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

[Robert Vanden Eynde]

Le sam. 11 août 2018 à 10:34, Vincent Maillol <vincent...@gmail.com> 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)

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

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

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

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

[Chris Angelico]

On Mon, Aug 13, 2018 at 1:31 PM, Abe Dillon <abed...@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 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

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

[Chris Angelico]

On Mon, Aug 13, 2018 at 2:56 PM, Abe Dillon <abed...@gmail.com> 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.

[Ryan Gonzalez]

Now that the discussion has officially devolved into something that has absolutely nothing to do with the original topic, I'd like to point out something: (Note that I have no affiliation with the managers of this mailing list at all and am just posting this as an outsider.)

In Steven D'Aprano's original message, I didn't see anything there as being a personal attack or as having an angry tone, at least based on his normal posting style. Maybe a bit critical and stern, but not really personal. You may have interpreted it as that, but I seriously doubt it was the intention. 

I'd like to propose an alternative to Hanlon's razor, the Internet razor:

Never attribute to malice that which is adequately explained by lack of context in online conversations. 

Online, there is no tone of voice, facial expressions, or extra context to really help distinguish intent. Misinterpreting has been a classic issue that's been around for ages and has only gotten worse. When writing a message, we're responsible for ensuring that the intent is clearly portrayed. When reading a message, we're responsible for correctly interpreting such intent, and everyone is usually better off if, when in doubt, the interpretation leans towards ambiguity over malice. 

--

Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
https://refi64.com/

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

[Abdur-Rahmaan Janhangeer]

it becomes "toxic" only after off-topic. fine list needs just a reminder from time to time !

Abdur-Rahmaan Janhangeer
https://github.com/Abdur-rahmaanJ
Mauritius

[Neil Girdhar]

I don't really want to get involved in this, but I feel like everyone is piling up on Abe unfairly.

On Mon, Aug 13, 2018 at 1:14 AM Ryan Gonzalez <rym...@gmail.com> wrote:

Now that the discussion has officially devolved into something that has absolutely nothing to do with the original topic, I'd like to point out something: (Note that I have no affiliation with the managers of this mailing list at all and am just posting this as an outsider.)

In Steven D'Aprano's original message, I didn't see anything there as being a personal attack or as having an angry tone, at least based on his normal posting style. Maybe a bit critical and stern, but not really personal. You may have interpreted it as that, but I seriously doubt it was the intention. 

When Abe wrote just this: "but I think they would (or do in the case of 'lambda') harm Python" — which is nothing but an opinion.  We're all welcome to our opinions without having to prove them like lawyers.

Steve replied this:  "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?"

To my perhaps tender Canadian ears, that is incredibly abrasive.  Steve could have just explained why he felt differently without slamming Abe's opinion as "an extreme overreaction" and then diving into a set of rhetorical questions that assume an extreme reading of Abe's statement.  

Now, as you say, this is Steve's usual posting style.  But new people don't know him.  I also found him quite abrasive when I started posting here, but then I noticed that it's not personal and he treats everyone this way.

There are some great posters here, and I like to read python-ideas because I learn so much from them: Nick, Antoine, Brett, and Nathaniel to name a few, but there are many more.  I think it's important for newcomers to try to be respectful, but it's also important to treat newcomers with the same kindness you would treat a guest in your home.

Best,

Neil

--

---
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...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

_______________________________________________
Python-ideas mailing list
Python...@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...@googlegroups.com.

[Antoine Pitrou]

On Sun, 12 Aug 2018 23:56:24 -0500
Abe Dillon <abed...@gmail.com> wrote:
>
> 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.

My experience is that this forum was toxic almost from the start,
because it encourages people to engage into the kind of behaviour you
are witnessing now (i.e. largely pointless and semi-agressive
nit-picking which sometimes feels straight out of the well-known
Argument Clinic sketch).

Regards

Antoine.

[Paul Moore]

On Mon, 13 Aug 2018 at 11:30, Antoine Pitrou <soli...@pitrou.net> wrote:
>
> On Sun, 12 Aug 2018 23:56:24 -0500
> Abe Dillon <abed...@gmail.com> wrote:
> >
> > 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.
>
> My experience is that this forum was toxic almost from the start,
> because it encourages people to engage into the kind of behaviour you
> are witnessing now (i.e. largely pointless and semi-agressive
> nit-picking which sometimes feels straight out of the well-known
> Argument Clinic sketch).

IMO, things have got worse over time. As a forum explicitly designed
for discussing speculative ideas, the general tone has become less and
less sympathetic towards people (particularly newcomers, which is
especially unfortunate) expressing ideas which are, shall we say, less
than perfectly thought through. I'm OK with gently pointing out to a
poster that they will need to tighten up their arguments and
assertions as the discussion progresses towards a concrete proposal,
but that's not how things feel any more. In particular there seems to
be an extremely aggressive dislike of anything that seems like
"opinion" which can't be backed up with solid evidence. Certainly we
don't expect proposals based purely on subjective opinion to make it
through to implementation, but we shouldn't be holding the process of
exploring ideas to such rigorous standards.

Anyway, I won't say any more, as I don't really know how we could
change things. And yes, a lot of the above is my view, and is
subjective. Asking me to provide evidence and back up my assertions
sort of proves my point, so please treat it as just that, my opinion,
and take it or leave it on that basis.

Paul

[Nicholas Chammas]

From what I’ve seen on this list in my relatively brief time here, this forum is mostly fine and the participants generally behave like adults. I don’t read every thread, so maybe I don’t have an accurate picture. From what I’ve seen, there is the occasional spat, where people just need to step away from the keyboard for a bit and cool off, but I wouldn’t consider the environment toxic. That seems like too strong a word. 

What I feel we lack are better tools for checking bad behavior and nudging people in the right direction, apart from having discussions like this. 

Temporarily locking threads that have become heated comes to mind. As do temporary bans for rowdy members. As does closing threads that have ceased to serve any good purpose. 

These things would have been pretty handy in several recent and heated discussions, including the PEP 505 one I participated in a couple of weeks ago. 

How much of this is possible on a mailing list? I don’t know. But I remember a year or two ago there was a proposal to move python-ideas to a different format, perhaps a Discourse forum or similar, which would provide some handy administration tools and other UX improvements.

That discussion, ironically, was beset by some of the very animosity that better tooling would help control. (And I learned a bit about email etiquette and top-posting...)

Maybe we need to revive that discussion? Overall, I don’t think we have a people problem on this list as much as we have an administration tooling problem. 

[Abdur-Rahmaan Janhangeer]

normally at above 20+ posts it gets crazy

[Michael Selik]

On Mon, Aug 13, 2018, 5:59 AM Nicholas Chammas <nicholas...@gmail.com> wrote:

Maybe we need to revive that discussion? Overall, I don’t think we have a people problem on this list as much as we have an administration tooling problem. 

+1

Even the fact that "straw poll" votes aren't counted automatically shows that better tools could help.

[Chris Angelico]

How often are straw polls actually needed? The popular vote is almost
entirely meaningless.

ChrisA

[Michael Selik]

Something that limits posts to once per day per thread could be useful, maybe even once per week.

[Michael Selik]

On Mon, Aug 13, 2018, 10:09 AM Chris Angelico <ros...@gmail.com> wrote:

On Tue, Aug 14, 2018 at 3:06 AM, Michael Selik <mi...@selik.org> wrote:
>
>
> On Mon, Aug 13, 2018, 5:59 AM Nicholas Chammas <nicholas...@gmail.com>
> wrote:
>>
>> Maybe we need to revive that discussion? Overall, I don’t think we have a
>> people problem on this list as much as we have an administration tooling
>> problem.
>
>
> +1
>
> Even the fact that "straw poll" votes aren't counted automatically shows
> that better tools could help.
>

How often are straw polls actually needed? The popular vote is almost
entirely meaningless.

That fact is not obvious. It's frustrating to find oneself engaging in meaningless discussion.

[Abe Dillon]

This is a half-baked thought, but perhaps a sub-reddit would facilitate better moderation and we'd get the bonus of threaded discussions and a side-bar for ediquite and other important info.

I know Reddit has a mixed reputation, but some of the best moderated subs like /r/science and /r/neutralpolitics have fantastic discussions.

We could open /r/pythonideas and see if it gains traction.

We also have the skill set to write a pretty good moderation bot.

_______________________________________________

[Abdur-Rahmaan Janhangeer]

some mods warnings or reminders might also help !

[Alex Walters]

> -----Original Message-----
> From: Python-ideas <python-ideas-bounces+tritium-
> list=sdamo...@python.org> On Behalf Of Abe Dillon
> Sent: Monday, August 13, 2018 12:56 AM
> To: Chris Angelico <ros...@gmail.com>
> Cc: Python-Ideas <python...@python.org>
> 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.

> Python...@python.org <mailto:Python...@python.org>
> https://mail.python.org/mailman/listinfo/python-ideas

> <https://mail.python.org/mailman/listinfo/python-ideas>
> Code of Conduct: http://python.org/psf/codeofconduct/

> <http://python.org/psf/codeofconduct/>

[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

[Bruce Leban]

On Sun, Aug 12, 2018 at 8:31 PM, Abe Dillon <abed...@gmail.com> 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

[Chris Angelico]

On Tue, Aug 14, 2018 at 4:00 AM, Bruce Leban <br...@leban.us> 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 "<lambda>"
* Comprehensions/genexps, always called "<listcomp>" 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

[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__
'<lambda>'

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

[Chris Angelico]

On Tue, Aug 14, 2018 at 5:08 AM, Abe Dillon <abed...@gmail.com> 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.

[Stephen J. Turnbull]

Cleaning out the Ccs, presumably subscribed.

Nicholas Chammas writes:

> From what I’ve seen on this list in my relatively brief time here,
> this forum is mostly fine and the participants generally behave
> like adults. I don’t read every thread, so maybe I don’t have an
> accurate picture. From what I’ve seen, there is the occasional
> spat, where people just need to step away from the keyboard for a
> bit and cool off, but I wouldn’t consider the environment
> toxic. That seems like too strong a word.

I would go further, and say that use of the word says more about those
who used it than about the list.

> What I feel we lack are better tools for checking bad behavior and
> nudging people in the right direction, apart from having
> discussions like this.

I disagree. I think this is a scale problem: we have too many people
posting, some of them new or infrequent, to prevent (1) people getting
triggered by one word in an otherwise excellent post and going off in
their replies, (2) intemperate rebuttals to the replies in (1), or (3)
interminably long threads sustained by people who don't yet know when
not to post.

If (1) and (2) can be solved by moderation, then you pretty much have
a toxic channel.

The best solution to (3) is not channel-wide moderation, but killing/
muting the thread or specific posters in your MUA. If you're going to
participate in channels as high-traffic as the Python lists, and still
try to hold down a day job, this is one of the very few features where
I'm willing to say "bite the damn bullet and get a REAL MUA!" It
really improves life. If most people have muted the thread, there's
little to no harm in letting those who still care continue. This also
has the advantage that you don't have to wait for a thread to be of
use to nobody to kill it. You can do that now!

> These things would have been pretty handy in several recent and
> heated discussions, including the PEP 505 one I participated in a
> couple of weeks ago.

PEP 505 was an example of none of the above as far as I can see,
though. I think it's tough to find places where you could invoke a
thread freeze or a poster ban and not get a storm of pushback. And
it's kinda hard to see how killing a thread on an open PEP is useful.

> How much of this is possible on a mailing list?

Poster bans, whether temporary or indefinite, are possible.

Thread freezing or closing are in principle possible, but they'd be
really annoying to posters due to the nature of email, I suspect
(posts would bounce and clutter up your inbox later, rather than
having the "post reply" function disabled in the UI). Nor are they
implemented in GNU Mailman, although spam-checking could probably be
coerced to serve (ban messages where In-Reply-To or References
contains recent IDs in the frozen/closed thread). This would require
some additional scripts for efficient admin, and MUA tooling to
extract References would be nice, but all that doable in an afternoon
or two.

> But I remember a year or two ago there was a proposal to move
> python-ideas to a different format, perhaps a Discourse forum or
> similar, which would provide some handy administration tools and
> other UX improvements.

Going back to that discussion now that Guido is less involved might
get you a different answer. (He was not a fan of Discourse, and while
he told me he likes Zulip at PyCon Cleveland, he also said he sees it
as independent of the function of mailing lists. He also said Mailman
3's HyperKitty forum-like functionality sounds like it will be good
enough for him soon enough, so he'd probably be opposed to moving to
forum software on the "don't break what don't need fixing" principle.
All that is almost moot now.)

> Overall, I don’t think we have a people problem on this list as
> much as we have an administration tooling problem.

That's what @jack says, too. :-/ Sorry, that's a bit too snarky, but
the fundamental problem is that *people* post too much. That's a
*people* problem even though there are no problem people, and the
people that are deciding what to post aren't the admins (unless you'll
accept out-and-out censorship, or an editorial board if you prefer a
euphemism). So I don't see an admin tooling solution here.

Steve

--
Associate Professor Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turn...@sk.tsukuba.ac.jp University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN

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

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

[Chris Angelico]

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.

[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 important. Words change and are
co-opted in new contexts. "Lambda" is rapidly become a standard
programming term, and language agnostic, e.g.:

https://martinfowler.com/bliki/Lambda.html



--
Steve

[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

[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 context. If I did take it out of context, then I'm sorry.
My point was that (and I may be wrong about this)  I don't imagine most non-english speakers who want to write Python learning just enough English to write python.
I imagine that most of them learn a broader vocabulary and thus, discussions about common English words still apply to them.

It would be interesting to know either way, so maybe we should have a poll? I don't know.

[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

[Michael Selik]

On Mon, Aug 13, 2018, 5:48 PM Greg Ewing <greg....@canterbury.ac.nz> 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.

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

[MRAB]

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

[Chris Angelico]

On Tue, Aug 14, 2018 at 7:58 AM, Greg Ewing <greg....@canterbury.ac.nz> 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

[Jonathan Fine]

Hi All

Here's something that's at the core of my approach.

Faced with this sort of problem, I read again
https://www.python.org/psf/codeofconduct/. And then I compare my
intentions, words and actions to the guidelines in this, the Python
Community Code of Conduct. Only when I have, so to speak, regained my
purpose and composure do I consider the conduct of others.

At least, this is what I aspire to do.

--
Jonathan

[Jacco van Dorp]

I'm perhaps the newest and most ignorant subscriber here - I daresay everyone here has superior python knowledge to me, and all my other computing knowledge is inferior to what I can do with python. (and so far, I've had no influence at all on python)

However, this mailing list, generally, does not seem toxic to me at all. I haven't experienced any condescension about my lack of knowledge. While I can acknowledge that there might be superior alternatives to email, I do think the threshold of subscribing and listening in is lower than a lot of other options, like for example subreddits. I for example would have never come if it'd been one of those. 

[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

[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

[Michael Selik]

The conversation about syntactic sugar for ``functools.partial`` led to a question about whether jargon like "lambda" makes the concept of an anonymous function more difficult to learn.

In my own experience teaching, I find that many concepts are easier to introduce if I avoid the Python jargon until after I've explained what it does. This is supported by education research. Some light Googling found a study on the topic [0] that is consistent with my own observations.

Picking good names is hard [1]. It's tempting to use terms based on the origin of the concept, historical odds and ends, or even jokes. This can help someone remember the concept when someone is familiar with the origin, history, or joke, but makes the concept more confusing and hard to remember for others. I recommend trying to buck tradition and pick terms that are as simple as possible, requiring the least context to make sense.

Jargon can be useful for allowing an expert to quickly identify the context of a term [2]. Plain language phrases can easily create namespace collisions. However, someone searching for or reading about Python concepts already knows that the context is Python programming.

Good comparisons can be found in other fields:

* Driving -- brakes vs stoppers

* Sailing -- starboard vs right-side

* Medicine -- postprandial vs after-meal

* Biology -- dinosaur vs direlizard

In the last case, it turns out direbird might have been a better term. I'm not sure if that supports or detracts from my argument.

[0] https://iubmb.onlinelibrary.wiley.com/doi/full/10.1002/bmb.20922

[1] https://martinfowler.com/bliki/TwoHardThings.html

[2] https://www.nngroup.com/articles/specialized-words-specialized-audience/

[Steve Barnes]

On 14/08/2018 20:42, Michael Selik wrote:
>
> Good comparisons can be found in other fields:
> * Driving -- brakes vs stoppers
> * Sailing -- starboard vs right-side
> * Medicine -- postprandial vs after-meal
> * Biology -- dinosaur vs direlizard
>

While NOT wanting to start another fight I feel that I must put my
pedant hat on & point out that the above highlights why domain specific
words are used and their specificity actually highlights important
concepts, i.e.:

* Brakes are used to apply breaking, (i.e. to slow the vehicle,
possibly to a stop), while stoppers STOP something.
* Starboard = to the right when facing the bow (front of the vessel)
not "my right", "your right" or "their right" (which depends on which
way you, I & they are facing).
* postprandial = after Lunch (not after eating any meal or after a snack).
* A dinosaur is specifically an extinct terrible (formerly considered)
lizard where as a Gila Monster is definitely a scary & dangerous (dire)
lizard.

In all of these cases there is a specificity to the word used that is
missing from the alternative offered that will, hopefully, be raised by
the use of that word. Unfortunately many people, when trying to explain
what the word means fail to highlight where it is different (the number
of times that I have heard people "explain" port and starboard as left
and right without mentioning the word bow or forward is countless).

Using a slightly unfamiliar word can cause people to ask, or think
about, why this is different & what the difference is while also drawing
a parallel that can help the user/student to understand & remember the
concept.

Also, picking a label for something, and using it consistently, can
vastly simplify things like manual searches (or on-line searches).

The English language has, historically, always borrowed, co-opted and
sometimes perverted words from other languages to allow distinct
concepts to be expressed concisely - which I personally, (admittedly as
a native speaker), find rather useful.

--
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.

---
This email has been checked for viruses by AVG.
https://www.avg.com

[Stefan Behnel]

Michael Selik schrieb am 14.08.2018 um 21:42:
> This is supported by education research. Some light Googling found a
> study on the topic [0] that is consistent with my own observations.

OTx2, and no offence, but … this is supported by research as well. People
tend to search just long enough to find the link that backs their …
observations. :)

Stefan

[Michael Selik]

On Wed, Aug 15, 2018, 12:06 AM Stefan Behnel <stef...@behnel.de> wrote:

Michael Selik schrieb am 14.08.2018 um 21:42:
> This is supported by education research. Some light Googling found a
> study on the topic [0] that is consistent with my own observations.

OTx2, and no offence, but … this is supported by research as well. People
tend to search just long enough to find the link that backs their …
observations. :)

Of course! No offense taken. I did "light Googling", not a literature review.

[Greg Ewing]

Steve Barnes wrote:
> * Brakes are used to apply breaking,

I hope they actually apply braking, not breaking. :-)

> * A dinosaur is specifically an extinct terrible (formerly considered)
> lizard

Which technically is not a lizard.

--
Greg

[Jonathan Fine]

Steve Barnes and Greg Ewing wrote:

>> * A dinosaur is specifically an extinct terrible (formerly considered)
>> lizard
>
>
> Which technically is not a lizard.

I can't resist. Puffinus puffinus is the scientific name for

(drum roll)

no, not the Atlantic (or common) Puffin but

(off-pitch fanfare)

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

--
Jonathan

[Rhodri James]

On 15/08/18 06:21, Steve Barnes wrote:
> The English language has, historically, always borrowed, co-opted and
> sometimes perverted words from other languages to allow distinct
> concepts to be expressed concisely - which I personally, (admittedly as
> a native speaker), find rather useful.

I think you and Michael are arguing to the same end. He was suggesting
that it's easier to teach a concept by introducing the idea and then a
name for it, rather like the way Python creates objects before binding them.

--
Rhodri James *-* Kynesim Ltd

[Greg Ewing]

Jonathan Fine wrote:
> Puffinus puffinus is the scientific name for

Puff the Magic Dragon?

--
Greg

[MRAB]

On 2018-08-15 09:17, Jonathan Fine wrote:
> Steve Barnes and Greg Ewing wrote:
>
>>> * A dinosaur is specifically an extinct terrible (formerly considered)
>>> lizard
>>
>>
>> Which technically is not a lizard.
>
> I can't resist. Puffinus puffinus is the scientific name for
>
> (drum roll)
>
> no, not the Atlantic (or common) Puffin but
>
> (off-pitch fanfare)
>
> https://en.wikipedia.org/wiki/Manx_shearwater
>

While we're at it, what's the only creature that's known commonly and
only by its scientific name?

[Danilo J. S. Bellini]

On 14 August 2018 at 16:42, Michael Selik <mi...@selik.org> wrote:

In my own experience teaching, I find that many concepts are easier to introduce if I avoid the Python jargon until after I've explained what it does. [...]

"until after" != "forever".

A jargon might be just an acronym, a word or few words, meaningless for someone who doesn't know what it means [sic], but even for this person the jargon is useful: he/she can look for information about it. Teaching the other way around to let the student grasp the "mechanical procedure" before its name doesn't change anything regarding the names.

You can make everyone memorize the algorithm for adding base-10 whole numbers by hand without teaching the students words like "adding" or "sum", not even the "+" symbol. But it would be a confusion if you use any other symbol or word to replace these "maths jargon" ones, and you shouldn't avoid the socially used names/symbols just because you're teaching that stuff for kids who still doesn't know them. And I'm aware of students complaining they can't remember something they've learned (or simply they didn't know someone was talking about what they know, a communication issue) because they didn't know the name (not even for searching in the web, a dictionary, whatever...).

I really regret that I complained when expressions like "modus ponens" and "disjunctive syllogism" were teached to me during a class in 2004, that day I thought these stuff were so obvious that they shouldn't have a name. Until I found, later, that I needed to know these names in order to understand some stuff I was reading. These names might had been hard to memorize, but they were better than arbitrary names that no one else happens to use.

Some of my worst teachers avoided the proper jargon forever, not just "until after" definitions/examples. Several classes here in Brazil tries to teach some concepts by forcing everything to be in Portuguese, like an "ideology of full translation", and sometimes the translated names are meaningless (no social context external to the class uses them). I got somewhat angry when I found that a lot of stuff I knew had other names in every useful social context, and I know who/what I should blame for that.

Terminology is the first step when going into a new domain... an example, marked as "Important unit", can be found at https://www.statistics-made-easy.com/introduction-to-statistics/

This introduction will teach you all the basic terms of statistics. It is important to understand them well before studying the unit about organizing data. The lessons are organized in a way to make the learning process as smooth as possible. Follow the logical order given here to study the lessons.

[...] It's tempting to use terms based on the origin of the concept, historical odds and ends, or even jokes. [...]

Usually, you're not naming something new and unnamed... but sometimes the concept might have more than a single name. I think that's like irregular verbs: they're so common that they "break the patterns"; concepts that are spread/scattered everywhere might have a distinct name in each domain.

Names should be useful to precisely express the concept in social contexts, but there's a context that should never be considered for that: the "teaching" one. If the concept itself isn't known by some people, why care about an alternative "non-jargon" name? A name doesn't belong to a person or a class, but to the people who can use/understand it, and I believe using proper jargon instead of alternative "simplified" names should maximize that.

It's the social expressiveness towards people who already know the concepts that should be emphasized, not some other arbitrary "simplification" goal (e.g. minimize the number of characters, only use English, ...).

IMHO, avoiding jargon sounds like avoiding teaching. In the case of new Python stuff, avoiding the socially standardized terminology is an act of isolation/seclusion.

--

Danilo J. S. Bellini
---------------
"It is not our business to set up prohibitions, but to arrive at conventions." (R. Carnap)

[MRAB]

On 2018-08-15 18:27, MRAB wrote:
> On 2018-08-15 09:17, Jonathan Fine wrote:
>> Steve Barnes and Greg Ewing wrote:
>>
>>>> * A dinosaur is specifically an extinct terrible (formerly considered)
>>>> lizard
>>>
>>>
>>> Which technically is not a lizard.
>>
>> I can't resist. Puffinus puffinus is the scientific name for
>>
>> (drum roll)
>>
>> no, not the Atlantic (or common) Puffin but
>>
>> (off-pitch fanfare)
>>
>> https://en.wikipedia.org/wiki/Manx_shearwater
>>
> While we're at it, what's the only creature that's known commonly and
> only by its scientific name?
>

The answer is boa constrictor.

[Alexandre Brault]

On 2018-08-15 03:32 PM, MRAB wrote:
> On 2018-08-15 18:27, MRAB wrote:
>> On 2018-08-15 09:17, Jonathan Fine wrote:
>>> Steve Barnes and Greg Ewing wrote:
>>>
>>>>>   * A dinosaur is specifically an extinct terrible (formerly
>>>>> considered)
>>>>> lizard
>>>>
>>>>
>>>> Which technically is not a lizard.
>>>
>>> I can't resist. Puffinus puffinus is the scientific name for
>>>
>>> (drum roll)
>>>
>>> no, not the Atlantic (or common) Puffin but
>>>
>>> (off-pitch fanfare)
>>>
>>> https://en.wikipedia.org/wiki/Manx_shearwater
>>>
>> While we're at it, what's the only creature that's known commonly and
>> only by its scientific name?
>>
> The answer is boa constrictor.
>

I would have guessed Tyrannosaurus Rex

[Greg Ewing]

Alexandre Brault wrote:
> On 2018-08-15 03:32 PM, MRAB wrote:
>
>>On 2018-08-15 18:27, MRAB wrote:
>
>>>While we're at it, what's the only creature that's known commonly and
>>>only by its scientific name?
>

> I would have guessed Tyrannosaurus Rex

I would have thought pretty much any dinosaur.

--
Greg

[Abe Dillon]

[Michael Selik]

The conversation about syntactic sugar for ``functools.partial`` led to a question about whether jargon like "lambda" makes the concept of an anonymous function more difficult to learn.

To clarify: The original statement by Steven D'Aprano, "although possibly a less jargon name would be nicer..." indicated to me that he thought there might be situations where less jargon terms are preferable to jargon terms.

The argument I tried to make is, "yes I believe there are cases where a less jargon identifier is preferable and that I believe 'lambda' is an example of a missed opportunity to use a less jargon (maybe 'esoteric' is a better word here?), more descriptive name."

Subjectively, I don't like lambda expressions. I find the word 'lambda' to be an eye-sore in an otherwise very elegant language.

That being said: I believe subjective valuations are rarely devoid of subtle, underlying motivators that are at least grounded in logic if not objective. It's just hard to put your finger on it most of the time. I often try to root out those motivators for why I feel the way I do and articulate them as best I can. At the end of the day, though; I can't always provide a completely objective, logical proof for why I feel the way I do.

For instance: when the iPhone was introduced, a lot of people praised it's subjectively "slick" user interface. I believe that perception of slickness is partly because the iPhone emulated physical interfaces very well so it leveraged people's intuition about the physical world. It was delightfully intuitive.

I believe that part of my distaste for lambda is that it's an esoteric word that doesn't convey any meaning to someone who's never heard of a 'lambda expression' (which was the case for me when I first encountered it). Even after I had heard of a lambda expression, the fact that the word had little other connection to anything relevant in my brain meant that I had to mentally translate it every time I read for a couple of years.

[Steven Barnes]

While NOT wanting to start another fight I feel that I must put my 
pedant hat on & point out that the above highlights why domain specific 
words are used and their specificity actually highlights important 
concepts, i.e.:
  * Brakes are used to apply breaking, (i.e. to slow the vehicle, 
possibly to a stop), while stoppers STOP something.

I don't think this is comparable to calling a car's brakes, "stoppers" for several reasons.

1) What we call something usually relates to how humans communicate to other humans about that thing, not how we actually use the tool.

I'm not against the idea of jargon. It clearly serves a useful purpose for humans to communicate to other humans both concisely and with precision. When I tell someone at work that a service went down and they say, "I'll take a look at the logs", I know they're not talking about lengths of cut or fallen tree. I'm glad humans are so good at deducing context that we don't have to constantly disambiguate everything. I also understand that this practice of overloading words sometimes leads to strange results like "currying". Maybe calling it "signature reduction" would have been too unwieldy and/or caused confusion with the word "reduce" which is often used in the same context.

None of that has to do with how I interact with a car. Few brake pedals say "brake" on them. I don't have to use the word "brake" to slow down my car. Few of the interfaces in my car even have words. There's no lever that says "high beams". There's no dashboard indicator that says "high beams". I don't have to use the phrase "high beams" to turn on my high beams. At the same time, I don't need to use or know the word "ternary" to read or write a ternary expression in Python. I don't think that was a mistake or a missed opportunity to force people to look up the word "ternary".

Sometimes in highly specific contexts, we deal with nuanced concepts like the difference between a parameter and an argument. So we use jargon to distinguish between them. That's not as much of problem in a programming language. The constructs in Python have to have an exact meaning by default. Clearly defining and separating name-spaces is an inescapable fact of life in programming. There's no chance of Python accidentally misinterpreting which "log" you're talking about. There's no potential for a "who's on first" gag. 

2) Cars tend to actually use pretty sensible naming schemes.

A windshield shields you from the wind. A windshield wiper wipes the windshield. Windshield wiper fluid is fluid that helps the windshield wiper wipe the windshield, etc.
If they called windshield wiper solution "epsilon", it wouldn't cause more crashes or anything, it would just be more confusing than it needs to be.

3) It's not like calling 'brakes' 'stoppers'. It's more like calling an expression that makes a function by some random greek letter. I don't see much need for a metaphor.

[Steven Barnes]

* postprandial = after Lunch (not after eating any meal or after a snack).

Not according to Google, Merriam-Webster, Oxford, or Wikipedia.

[Steven Barnes]

In all of these cases there is a specificity to the word used that is 
missing from the alternative offered that will, hopefully, be raised by 
the use of that word. Unfortunately many people, when trying to explain 
what the word means fail to highlight where it is different (the number 
of times that I have heard people "explain" port and starboard as left 
and right without mentioning the word bow or forward is countless).

I understand the potential benefit of jargon as stated above, but even this isn't always true. Sometimes jargon is created that is counterintuitive and then it just sticks because changing it would be a huge hassle. In electrical engineering, current is supposed to be the "flow of positive charge", but charge conventions were established before we knew how atoms work and learned that positively charged particles don't often move in circuits. Dinosaurs are another good example. Sometimes jargon is a mistake.

[Steven Barnes]

Using a slightly unfamiliar word can cause people to ask, or think 
about, why this is different & what the difference is while also drawing 
a parallel that can help the user/student to understand & remember the 
concept.

It depends on if it's easy to tie said word into a broader understanding. It's easy for me to remember that "agua" means "water" in Spanish because it's very similar to a words that relate to water in english like "aquifer". I have trouble remembering that "izquierda" means "left" because I don't know any word like it. I have to pause and think about it every time without fail! Similarly, I can guess that "anonymous function" means a function without a name, but it took me a while to get used to "lambda" because it was just dangling there with no other connection to its context. Even when I learned about lambda calculus it didn't help much because the "lambda" was an arbitrary choice. There wasn't any way for me to tie it into a richer context.

[Steven Barnes]

Also, picking a label for something, and using it consistently, can 
vastly simplify things like manual searches (or on-line searches).

Yes, Steven D'Aprano mentioned this and it's a fair point. I think it'd have to be pretty horrendous jargon to justify "create [an] association from scratch" as Steven put it. I've since gone back on my original push for "partial" over "given" because I don't think it meets that criteria. I think that "lambda" is a different case because there already existed several better alternatives in other languages and, in the case of "def", in Python itself.

[Chris Angelico]

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

Naming and semantics are essentially orthogonal. Sure callbacks and the like can require some painful mental gymnastics, but that's independent of choosing "function" or "lambda". When I talk about students having more trouble learning lambdas than I expect, I'm specifically talking about lambdas, as in:

>>> func = lambda x: x*x

Even students that seemed to quickly grasp functions as first-class objects would stumble on basic lambda expressions. Not as much trouble as callbacks and other, more complex concepts, but more trouble than regular function definition.

Anyway, the question should be "Is it always best to use jargon in the implementation of Python features? If so, how do you figure? If not, when and why should it be avoided?"

[Jonathan Fine]

Summary: Discussion of the words 'jargon' and 'chatter'. Recommend that we

> learn better how to find a compromise (strike a balance) between precision and simplicity.

This thread is, in part, about the meaning, use and usefulness of words. And 'jargon' is what we are talking about. What is the meaning and use of 'jargon'?

According to https://www.etymonline.com/word/jargon (discovered https://en.wikipedia.org/wiki/Jargon)

===

jargon (n.)

mid-14c., "unintelligible talk, gibberish; chattering, jabbering," from Old French jargon "a chattering" (of birds), also "language, speech," especially "idle talk; thieves' Latin" (12c.). Ultimately of echoic origin (compare Latin garrire "to chatter").

From 1640s as "mixed speech, pigin;" 1650s as "phraseology peculiar to a sect or profession," hence "mode of speech full of unfamiliar terms." Middle English also had it as a verb, jargounen "to chatter" (late 14c.), from French.

===

And according to https://www.etymonline.com/word/chatter

===

chatter (v.)

early 13c., chateren "to twitter, make quick, shrill sounds" (of birds), "to gossip, talk idly or thoughtlessly" (of persons), earlier cheateren, chiteren, of echoic origin. Compare Dutch koeteren "jabber," Danish kvidre "twitter, chirp." Of teeth, "make a rattling noise from cold or fright," mid-15c. 

===

Ordinary words can acquire a specialised technical meaning. For example

===

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

Machining vibrations, also called chatter, correspond to the relative movement between the workpiece and the cutting tool. The vibrations result in waves on the machined surface. This affects typical machining processes, such as turning, milling and drilling, and atypical machining processes, such as grinding.

===

Sometimes, machining vibrations make a ch-ch-ch-ch chattering sound. My opinions are that the correct technical phrase is 'machining vibrations', which is good for learned articles. But 'chatter' is better in the workshop. As in 'lubricate the drill bit to reduce chatter'.

And here's another example

===

https://en.wikipedia.org/wiki/Chatter_(signals_intelligence)

Chatter is a signals intelligence term, referring to the volume (quantity) of intercepted communications. Intelligence officials, not having better metrics, monitor the volume of communication, to or from suspected parties such as terrorists or spies, to determine whether there is cause for alarm.

===

Back to 'jargon'.

===

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

Accessibility issues

With the rise of the self-advocacy movement within the disability movement, jargonised language has been much objected to by advocates and self-advocates.

Jargon is largely present in every day language, in newspapers, government documents, and official forms. Several advocacy organisations work on influencing public agents to offer accessible information in different formats.

[...]

There is a balance to be struck, as excessive removal of technical terminology from a document leads to an equally undesirable outcome—dumbing down.

===

I think this last quote gets to the heart of the matter we're discussing. I suggest we learn better how to find a compromise (strike a balance) between precision and simplicity.

-- 

Jonathan

[Stephen J. Turnbull]

tl;dr I don't think so, not very much. There are bigger fish to fry.

I would appreciate comments on the last paragraph (before the
footnotes), which can be read standalone. If opinion is at all
favorable, I'll raise it with the PSF.

Jonathan Fine writes:

> Summary: Discussion of the words 'jargon' and 'chatter'. Recommend
> that we learn better how to find a compromise (strike a balance)
> between precision and simplicity.

I'm not a big fan of asking that everybody put such effort into
documentation for code they're developing. IMHO, where available users
should just buy books by professional writers written to their level,
rather than imposing this burden on the software development project.

Developers themselves should be asked to write concise, precise
documentation. I don't think it's at all a good idea to burden them
with "accessibility" issues. It's hard enough to write good notes for
yourself a year hence! Tutorial writers, OK, they should be cautioned
to avoid jargon, but if they aren't already judicious about using
jargon, maybe they shouldn't be writing tutorials at all?

What about documentation patches from users (including developers who
didn't write the docs being edited)? In general, I favor restricting
these to correcting bugs, missing information, and extremely
convoluted syntax. If the docs use jargon (by which I mean "informal
technical terms, often local to the project") which is intelligible to
long-time users but may be off-putting to newcomers and infrequent
users (of the documentation, not the software!), I think it is better
to provide a glossary.[1] The problem with editing inline is that
there are direct costs and a missed opportunity. The direct costs
include the potential for introducing imprecision and outright
documentation bugs, and code churn (increasing the cost of reading
diffs).

The missed opportunity is that a good glossary will also serve users
who graduate to "informal write-only documentation" including archives
of mailing lists and group chats, and the issue tracker.

I'm not sure about the "conventional" accessibility issues (ie,
excluding newcomers, non-native speakers, and translators). As a
developer/maintainer I have had a small amount of contact with users
with perceptual and motor disabilities, but have never heard them
complain[2] about jargon. (Small sample, but before we presume they
would benefit from simplified docs, we should consult experts.)

Serving non-native-speakers is a tough call. On the one hand, they
would be best served by good translations and glossaries of English
jargon in their native language. You don't need to speak English at
all to write good programs in programming languages based on English
keywords, and the concepts are easier to understand, and precision
easier to obtain, if you're not fighting with a second language.

For many of my students, the first language is Chinese, the second
Japanese, and the third English. English keywords and the occasional
concept denoted by jargon don't faze them. The problem is more
following simple directions about inserting punctuation, misspelled
words, and so on -- the closest literal translations often are poor
semantic matches, and so all English is awkward for them. But I can
understand half (well, 10% ;-) of what their sempai are saying in
Chinese, because of the keywords and borrowed jargon -- and so can the
kohai. Jargon isn't a problem; it's just another symbol for an
unfamiliar concept that they need to learn.

On the other, we're not doing a good job of encouraging translators.
There are a lot of volunteers in the translation community, and (like
programmers) an important reward is getting their product into the
distribution. (This is *not* a complaint about the Python
maintainers. The costs of infrastructure and maintaining
synchronization of translations with the original documentation are
still quite high.) I suppose there must be corporations who are doing
translations for their Python-based products, and we can do a better
job of getting them to contribute them upstream (although we currently
have the problem of "where is upstream?" since we don't distribute
translations ourselves).

Finally, before getting the project into the hairy maintenance issues
that go with distributing translations, I suggest the PSF could buy
the high-quality tutorial books and textbooks (and maybe dictionaries
as well) for translators. Very cheap, but the symbolism that
"somebody noticed, and they care!" is a big reward for many
contributors. Another possibility would be complimentary tickets
(and/or travel grants) to PyCon. From past experience I gather that
many translators are more focused on their natural language than on
the projects whose documentation they translate, so it's probably not
worth sending them to big international PyCons to be lionized by the
core developers and PSF board members. On the other hand going to
a local PyCon might be attractive, especially if they got
complimentary tickets to some of the parties, where they would be
introduced to keynote speakers and the like, and would be lionized by
the people they're writing for. Not to mention getting feedback.

Steve


Footnotes:
[1] The convention in academic and textbook writing of providing
definitions (and expansions of abbreviations and acronyms) at first
use is a good one, but the glossary is essential in technical
documentation because users frequently dip into the middle of a
document for a specific entry rather than reading linearly.

[2] In fact, users with disabilities rarely complain in my
experience. They just point out their issues without attitude.

[Jonathan Fine]

Hi Stephen

Thank you for your message. I'll respond just to a few of your comments.


HOW MUCH EFFORT ON DOCS
==========================

Myself and you wrote:

>> Summary: Discussion of the words 'jargon' and 'chatter'. Recommend
>> that we learn better how to find a compromise (strike a balance)
>> between precision and simplicity.

> I'm not a big fan of asking that everybody put such effort into
> documentation for code they're developing. IMHO, where available users
> should just buy books by professional writers written to their level,
> rather than imposing this burden on the software development project.

Sections 6 and 7 (out of 31) in devguide for the Python project are on this.
===
https://devguide.python.org/docquality/
https://devguide.python.org/documenting/
===
This is about 6.5%, of the devguide, by section count. There are at
present 108 open documentation issues (out of about 6,000). This is
about 2%.

I'm proposing for example that we review, and if possible improve,
these two sections in the devguide. This review would be evidence
based. Not everyone need be involved in this. I suggest that doing
this now would, over 3 years, significantly improve our Python
documentation.


AN EXAMPLE - super()
==================

By chance, I wanted today to read about and then use super(). I found
===
https://docs.python.org/3/library/functions.html#super

For practical suggestions on how to design cooperative classes using
super(), see guide to using super().
===

To my surprise, I found that this links, not to another part of the docs, but to
===
https://rhettinger.wordpress.com/2011/05/26/super-considered-super/
===
This excellent blog post is not, of course, indexed for the docs search.


THE GLOSSARY
=============

You wrote:

> The missed opportunity is that a good glossary will also serve users
> who graduate to "informal write-only documentation" including archives
> of mailing lists and group chats, and the issue tracker.

Five days ago, I raised an issue (one of the 108 open issues), to
improve search in the glossary. And thanks to Ammar Askar, there's
already a patch and pull request. This delights me.

https://bugs.python.org/issue34398
https://github.com/python/cpython/pull/8773


TRANSLATION
============

You wrote:

> Serving non-native-speakers is a tough call. On the one hand, they
> would be best served by good translations and glossaries of English
> jargon in their native language.

There's already prior art on this. See:

PEP 545 -- Python Documentation Translations
https://www.python.org/dev/peps/pep-0545/

One of the alternatives in PEP 545 is
===
Simplified English
It would be possible to introduce a "simplified English" version like
wikipedia did, as discussed on python-dev, targeting English learners
and children.
===

I think this would be a good idea, particularly for the tutorial (and
other beginner materials, such as the glossary).

--
with best regards

Jonathan

[Jonathan Fine]

Hi Stephen

I've just been reading the (excellent) discussion, started by Victor Stinner

[Python-Dev] Translated Python documentation
https://mail.python.org/pipermail/python-dev/2017-February/147416.html
# Start of thread.

You wrote, and asked for comments on:

> Finally, before getting the project into the hairy maintenance issues
> that go with distributing translations, I suggest the PSF could buy
> the high-quality tutorial books and textbooks (and maybe dictionaries
> as well) for translators. Very cheap, but the symbolism that
> "somebody noticed, and they care!" is a big reward for many
> contributors.

I very much more prefer Victor's suggestion (I give the whole message):
===
https://mail.python.org/pipermail/python-dev/2017-February/147485.html

IHMO translating the *whole* Python documentation at once by a
professional translator can be very expensive, no somthing that the
PSF would affort. Which language would you pick? Depending on what?

We already have motivated translators for free who only ask us for the
permission to make tiny changes to make their life simpler and make
the doc more visible. I'm in favor of allowing them to translate and
make the translated doc official ;-)

IMHO a better usage of the PSF funding would be to organize some local
sprints to translate the Python documentation. Such sprints are fun,
cheap, and can be a nice opportunity to recruit free and motivated
translators. We are looking for people involved to translate the doc
the doc is updated, not only translate the doc once and go away.
Right?
===

--
Jonathan

[Stephen J. Turnbull]

Jonathan Fine writes:

> One of the alternatives in PEP 545 is
> ===
> Simplified English
> It would be possible to introduce a "simplified English" version like
> wikipedia did, as discussed on python-dev, targeting English learners
> and children.
> ===

As a *translation*, it's a very worthwhile experiment, if someone
wants to do it.

[Stephen J. Turnbull]

Jonathan Fine writes:

> I very much more prefer Victor's suggestion [of providing
> translations in the distribution and giving translators commit
> bits, AIUI].

I think we can do both. My suggestion is very cheap, and requires no
change to release management, or even action by release managers and
committers: the PSF board could announce the policy tomorrow and start
cutting checks next Monday, and python-dev wouldn't notice. (I'm not
suggesting overnight rollout is a good idea, and practically speaking
the board can't act that fast, of course. The point is that there's
potential encouragement for translators, improved documentation for
users, at zero cost to the code developers and release managers.)

The suggestion of providing official translations in the distribution
has been made before, and resisted by the maintainers and committers.
I don't oppose the idea myself, I simply observe that resistance and
the explanations offered, and assume there is good reason for it.

Steve

[Rhodri James]

On 18/08/18 01:59, Abe Dillon wrote:
> The argument I tried to make is, "yes I believe there are cases where a
> less jargon identifier is preferable and that I believe 'lambda' is an
> example of a missed opportunity to use a less jargon (maybe 'esoteric' is a
> better word here?), more descriptive name."

While I don't entirely disagree with you, if I had been responsible for
inventing that bit of Python I would probably have gone with "lambda"
too. It had been part of my vocabulary as a computer scientist long
before I met it in a programming language. Whether it's a *good* choice
or not... possibly reusing "def" would fit people's expectations better,
or perhaps it would have caused more confusion. Who can tell?

Jargon becomes jargon because it's useful to enough people, for
occasionally rather odd definitions of "useful". In the case of lambda,
it's shorter than "inline function definition" and lambda calculus at
least shows up on most CompSci courses. Once it settles into a group,
you use it because other members of the group will understand what you
mean and might not understand if you rephrase it.

> For instance: when the iPhone was introduced, a lot of people praised
> it's subjectively "slick" user interface. I believe that perception of
> slickness is partly because the iPhone emulated physical interfaces
> very well so it leveraged people's intuition about the physical world.
> It was delightfully intuitive.

One of the things Apple have always been very good at is thinking hard
about user interfaces. What made the iPhone so good was that they
emulated the right physical interfaces, so flipping a page when you're
reading rather than pressing a button.

--
Rhodri James *-* Kynesim Ltd

[Abe Dillon]

Responding out of order.

[Rhodri James] 

> For instance: when the iPhone was introduced, a lot of people praised
> it's subjectively "slick" user interface. I believe that perception of
> slickness is partly because the iPhone emulated physical interfaces
> very well so it leveraged people's intuition about the physical world.
> It was delightfully intuitive.
One of the things Apple have always been very good at is thinking hard about user interfaces.  What made the iPhone so good was that they emulated the right physical interfaces, so flipping a page when you're reading rather than pressing a button.

Yes, that's exactly what I was trying to say. An important point that I think keeps getting lost in this conversation is that Python's grammar, syntax, and standard lib are it's user interface. There are very different constraints on Python's UI than there are when humans have to communicate directly with other humans. I have no problem using words like "closure" or "lambda expression" or "ternary expression" when communicating with other humans about programming language features, but jargon doesn't often make sense as part of Python's UI itself. Again, we don't use the word "ternary" in Python's ternary expressions.

[Rhodri James] 

Jargon becomes jargon because it's useful to enough people, for occasionally rather odd definitions of "useful".  In the case of lambda, it's shorter than "inline function definition"

Yes, again: I understand the utility of jargon. I don't think "anonymous function" would be an improvement over "lambda" because, while it is fairly descriptive, it sacrifices too much brevity. However; the word "anonymous" is redundant. You can tell the function is anonymous by virtue of the fact that it doesn't have a name. "function" is only two characters longer than "lambda" and is actually descriptive, but it probably would have caused backwards compatibility issues (same with "func" or "fun"). "def" would have been even shorter than "lambda".

[Rhodri James]

and lambda calculus at least shows up on most CompSci courses.

 

I suppose if by "courses" you mean "course plans", I highly doubt that the majority of CS classes cover lambda calc, though; I couldn't say for sure because I, like many programmers, didn't take CS in college. There are many disciplines that get by on basic algorithms, data-structures, and a pinch of theory.

[Rhodri James]

Once it settles into a group, you use it because other members of the group will understand what you mean and might not understand if you rephrase it.

If the group you're referring to are Computer Scientists, then I don't see why they would be confused by a syntax that omits the word "lambda" since very few languages use the word "lambda" to denote a lambda expression.

[Rhodri James] 

While I don't entirely disagree with you, if I had been responsible for inventing that bit of Python I would probably have gone with "lambda" too.  It had been part of my vocabulary as a computer scientist long before I met it in a programming language.  Whether it's a *good* choice or not... possibly reusing "def" would fit people's expectations better, or perhaps it would have caused more confusion.  Who can tell?

I don't see how "def" could cause more confusion than "lambda". Those who don't know what "lambda" refers to would at least have some notion of what "def" means, and those who have studied and know what lambda calculus is should also have very little trouble. I don't expect it would confuse someone well versed in computer science any more than a check-engine light would throw off an expert mechanic. They can at least google "python anonymous function" or "python lambda expression" and get results that tell you how to write a lambda expression in Python.

[Stephen J. Turnbull]

Rhodri James writes:
> On 18/08/18 01:59, Abe Dillon wrote:
> > The argument I tried to make is, "yes I believe there are cases where a
> > less jargon identifier is preferable and that I believe 'lambda' is an
> > example of a missed opportunity to use a less jargon (maybe 'esoteric' is a
> > better word here?), more descriptive name."
>
> While I don't entirely disagree with you, if I had been responsible for
> inventing that bit of Python I would probably have gone with "lambda"
> too. It had been part of my vocabulary as a computer scientist long
> before I met it in a programming language.

I was an economist then, and I'm an economist still, but I met lambda
in 1977. Surely lambda has had that role in computer languages since
shortly before I was born. I would guess anybody above a certain age
would reach for "lambda" first for a keyword to denote or define an
anonymous function. Not because of the lambda calculus, but because
of Lisp. (OK, that's indirectly because of the lambda calculus.)

Had Guido decided to change it to "def", I suspect he'd be regretting
it slightly today, for reasons similar to the regrets about "range":
we normally only allow omitting positional arguments at the end of the
list. Maybe there's a better word than "regret". After all, It's
hard to see how you could prototype range better than "range([START,]
END, [STRIDE])", and the same might be true for "def [NAME] ([ARG0,]
...):".

[Steven D'Aprano]

On Tue, Aug 21, 2018 at 02:07:33PM +0900, Stephen J. Turnbull wrote:

> I was an economist then, and I'm an economist still, but I met lambda
> in 1977. Surely lambda has had that role in computer languages since
> shortly before I was born. I would guess anybody above a certain age
> would reach for "lambda" first for a keyword to denote or define an
> anonymous function. Not because of the lambda calculus, but because
> of Lisp. (OK, that's indirectly because of the lambda calculus.)

Its pretty much a term of art.

(Aside: "term of art" is itself a term of art:
https://legal-dictionary.thefreedictionary.com/Term+of+Art )


I think that complaining about lambda is like complaining about "3-sigma
versus 6-sigma processes" in process management. (Not computer
processes, manufacturing processes and quality control.) Or for that
matter, "mean" and "standard deviation" in statistics.

The main difference is that most people are introduced to mean and stdev
in secondary school, while functional programming idioms and lambda are
generally stumbled across in the field. (I know that's how I learned of
the term: through Python.)

> Had Guido decided to change it to "def", I suspect he'd be regretting
> it slightly today, for reasons similar to the regrets about "range":
> we normally only allow omitting positional arguments at the end of the
> list. Maybe there's a better word than "regret". After all, It's
> hard to see how you could prototype range better than "range([START,]
> END, [STRIDE])", and the same might be true for "def [NAME] ([ARG0,]
> ...):".

Secure in the knowledge that Guido probably isn't reading this and won't
contradict me *wink* I'm going to try channelling him. I think he would
regret "def expressions", but not because of the range reason. I think
its because he likes the relatively strict demarcation between
statements and expressions.

We have 4 statements that have a expression form:

if...else versus ternary if expressions;

for loops versus comprehensions;

(soon) = assignment versus := assignment expressions; and

def versus lambda.

(Did I miss any? I don't include technicalities like dot attribute
access versus getattr and similar.) It's notable that in none of those
cases the syntax is quite the same in the two forms. There's always
enough differentiation between the statement and expression that there's
never any ambiguity which is intended. We don't have:

result = if condition expression else expression

where it is the lack of colons which hints that it is an expression, we
have a completely different syntax. So I think Guido probably wouldn't
like the idea of using def in expressions:

def function(arg, callback=def: None):
pass


That's my guess, for what it's worth.



--
Steve

[Abe Dillon]

[Stephen Turnbull]

I was an economist then, and I'm an economist still, but I met lambda
in 1977.  Surely lambda has had that role in computer languages since
shortly before I was born.

 

According to Wikipedia Lisp was the first language to use anonymous functions (introduced in 1958).

[Stephen Turnbull]

I would guess anybody above a certain age
would reach for "lambda" first for a keyword to denote or define an
anonymous function.  Not because of the lambda calculus, but because
of Lisp.

Wikipedia lists the anonymous function syntax of 40+ languages and only 5 (Lisp, Scheme, Python, Ruby, and Maxima) use the "lambda" keyword.
Haskel uses a "\" which I'm pretty sure is supposed to look like the lambda symbol, but even that syntax seems unpopular too.

[Stephen Turnbull]

Maybe there's a better word than "regret".  After all, It's
hard to see how you could prototype range better than "range([START,]
END, [STRIDE])", and the same might be true for "def [NAME] ([ARG0,]
...):".

I wasn't aware that Guido considered "range" to be warty. I like the way it mimics slicing syntax. It makes it easy for me to remember. It seems like a very pragmatic design.

[Steven D'Aprano]

Secure in the knowledge that Guido probably isn't reading this and won't 
contradict me *wink* I'm going to try channelling him.

SUMMON THE GREAT CREATOR!

I wonder if I say his name three times...
Guido Van Rossum! Guido Van Rossum! Guido Van Rossum!

[Steven D'Aprano]

I think he would regret "def expressions", but not because of the range reason. 

I think its because he likes the relatively strict demarcation between statements and expressions.
We have 4 statements that have a expression form:
if...else versus ternary if expressions;
for loops versus comprehensions;
(soon) = assignment versus := assignment expressions; and
def versus lambda.

(I don't know why Gmail's quotes screw up formatting...)

I don't think that's the reason those expressions have different formats than their statement counterparts.
Expressions allow for more flexible arrangement than expressions because the order of execution of an expression doesn't have to follow the order of declaration.
While it's more natural to say "do something to each item in this collection that meets some condition" you can't access variables before they're declared in statements
so you have to tell the computer explicitly that you're looping over some iterable first. Expressions allow you to be more expressive.

You don't have to put your edge-case checking up-front and in the way. When 99.9% of the time you just want:

x = y

you can shove the edge-case checking to the side and let the core logic shine:

x = y   if not edge_case else special_value

# extra spaces added for emphasis

besides:

result = if condition expression else expression

is super awkward to read out loud. That's not how I think at least.
I've never hears someone say, "My child's name will be if it's a girl Sally otherwise Billy."

All of the expressions use either the same or similar keywords or symbols *except* def and lambda.

func = def <args>: <expression> 

Is about as different from the statement form as "x := y" is from "x = y". No name, no parentheses for the arguments.
Finally, I know you've heard the other half of my anti-lambda manifest, but I don't know if Stephen Turnbull has, so I'll briefly present it again.

It's not just the name "lambda" that bothers me, it's the arrangement of the logic and signature. I believe that the expressiveness that allows comprehensions to put the core logic in front of the less important (for readability) loop and filtering constructs, anonymous functions could have been arranged to put the logic in front of the (almost always) less important signature. The reason I say the signature is almost always less important is because one almost always uses an anonymous functions as an argument (key-function, callback, map, reduce, filter, etc.) to something that already defines the call signature it expects.

Consider the alternate form: <expression> with <args>  (thought there are many alternative possibilities)

hand = sorted(cards, key=lambda card: value[card.suit] if card is not wild else max_value)

hand = sorted(cards, by=value[card.suit]     if card is not wild else max_value with card)

 

# notice how unsurprising it is that the signature is "card"

Oh wait... Did I accidentally replace "key" with "by"? Huh... It seems to make more sense even though the jargon is a "key function"... Oops! ;)

Note: if this were a full proposal, lambdas with complex arguments or in certain situations would require parens: (<expression> with <args>)

[Chris Angelico]

On Wed, Aug 22, 2018 at 3:56 AM, Abe Dillon <abed...@gmail.com> wrote:
> I've never hears someone say, "My child's name will be if it's a girl Sally
> otherwise Billy."

"My child's name depends on gender - if it's a girl, Sally, otherwise
Billy." Seems fine to me. You can always come up with something
awkward in a particular order, but it's not the order that made it
awkward.

> Consider the alternate form: <expression> with <args> (thought there are
> many alternative possibilities)
>
> hand = sorted(cards, key=lambda card: value[card.suit] if card is not wild
> else max_value)
>
> hand = sorted(cards, by=value[card.suit] if card is not wild else
> max_value with card)
>
> # notice how unsurprising it is that the signature is "card"

Okay, let's read that.

hand = # we're assigning this to the name 'hand'
sorted( # calling the function named 'sorted'
cards, # positional argument, whatever's in the 'cards' variable
by= # keyword argument, what comes next is the 'by' argument
value[card.suit] # subscript 'value' with 'card.suit'
if card is not wild # yep
else max_value # so we have an alternative
with card # WAIT WAIT WAIT

Once you get to 'with card', you have to go back and completely
reinterpret everything prior to that as a function. You have to scan
back and go "hang on, so exactly how much of this is getting wrapped
up into a function here?". Contrast the Python version:

hand = sorted(cards, key=lambda card: value[card.suit] if card is not
wild else max_value)

hand = # we're assigning this to the name 'hand'
sorted( # calling the function named 'sorted'
cards, # positional argument, whatever's in the 'cards' variable
key= # keyword argument, what comes next is the 'key' argument
lambda card: # a function taking one argument
value[card.suit] # subscript 'value' with 'card.suit'
if card is not wild # yep
else max_value # so we have an alternative
) # and we're done

The only part where you have to back up and change your interpretation
is when you hit "if card is not wild", which reads well enough to
justify the odd ordering. (JFTR, I wouldn't implement a deck of cards
this way. It implies that there is exactly one wild card, where many
decks of cards have at least two. In English, "card is not wild" can
be interpreted as a membership check, but in Python, it is only an
identity check; you're capitalizing on false readability by using this
notation.)

> Oh wait... Did I accidentally replace "key" with "by"? Huh... It seems to
> make more sense even though the jargon is a "key function"... Oops! ;)

I'm sure it would make even more sense if you wrote it this way:

hand = sorted(cards, by="suit")

That's how SQL works - you just name the column that you want to order
the results by. But if you think "by" is a better keyword here, start
explaining why your ordering is done with an anonymous function, not
with an attribute name.

ChrisA

[Abe Dillon]

[Chris Angelico]

Okay, let's read that.
hand = # we're assigning this to the name 'hand'
sorted( # calling the function named 'sorted'
cards, # positional argument, whatever's in the 'cards' variable
by= # keyword argument, what comes next is the 'by' argument
value[card.suit] # subscript 'value' with 'card.suit'
if card is not wild # yep
else max_value # so we have an alternative
with card # WAIT WAIT WAIT
Once you get to 'with card', you have to go back and completely
reinterpret everything prior to that as a function.

The revelation that it's a function should come when you read the "by" or "key". If you don't know what that parameter is, then that's where the "wait wait wiat!" should happen. Then type "help(sorted)" in a console or something. Another hint can come from the appearance of an undeclared variable: card. (I know, I know: I didn't declare several variables, just imagine that 'card' is the only variable not previously declared).

It's no more surprising than reading a comprehension:

initials = {person.name[0] for person in people if person.name}

initials = # we're assigning this to the name "initials"
initials = { # it's a dictionary or set of something
initials = { person.name[0]  # I'v never seen "person" before, this must be a comprehension or something
                             # anyway, no ":" means it's a set of the first letter of each person's name
intiials = { person.name[0] for person # WAIT WAIT WIAT WHAT?!? Just kidding, I saw this coming...

[Chris Angelico]

> Oh wait... Did I accidentally replace "key" with "by"? Huh... It seems to
> make more sense even though the jargon is a "key function"... Oops! ;)
I'm sure it would make even more sense if you wrote it this way:
hand = sorted(cards, by="suit")
That's how SQL works - you just name the column that you want to order
the results by. But if you think "by" is a better keyword here, start
explaining why your ordering is done with an anonymous function, not
with an attribute name.

If the logic is simple enough, you can just use a reference to the method from the class:

hand = sorted(cards, by=Card.suit)  # where Card is the class

That's why I tend to use a more complex example. Otherwise the lambda isn't really justified.

[Chris Angelico]

JFTR, I wouldn't implement a deck of cards this way. 

I don't implement decks of cards often, but in toy problems; I find just using 2-character strings works fine:

Ace_of_spades = "As"
Ten_of_hearts = "Th"
etc...

That can easily be extended by a named tuple initialized with unpacking:

Card = namedtuple("Card", "rank suit")
Ace_of_spades = Card(*"As")

[Chris Angelico]

It implies that there is exactly one wild card, where many
decks of cards have at least two.

I don't know of many games that have wild cards, but that's a simple remedy:

hand = sorted(cards, by=value[card.suit] if card not in wilds else max_value with card)

[Chris Angelico]

In English, "card is not wild" can
be interpreted as a membership check, but in Python, it is only an
identity check; you're capitalizing on false readability by using this
notation.

I promise that wasn't my intent. Since both my proposed form and the lambda form use the same expression,
it doesn't really tip the balance in favor of my argument. Also, most toy card problems I work with use a finite,

immutable set of cards, so identity checking isn't *that* weird.

[Chris Angelico]

On Wed, Aug 22, 2018 at 4:56 AM, Abe Dillon <abed...@gmail.com> wrote:
> [Chris Angelico]
>>
>> Okay, let's read that.
>> hand = # we're assigning this to the name 'hand'
>> sorted( # calling the function named 'sorted'
>> cards, # positional argument, whatever's in the 'cards' variable
>> by= # keyword argument, what comes next is the 'by' argument
>> value[card.suit] # subscript 'value' with 'card.suit'
>> if card is not wild # yep
>> else max_value # so we have an alternative
>> with card # WAIT WAIT WAIT
>> Once you get to 'with card', you have to go back and completely
>> reinterpret everything prior to that as a function.
>
>
> The revelation that it's a function should come when you read the "by" or
> "key". If you don't know what that parameter is, then that's where the "wait
> wait wiat!" should happen.

That right there is unacceptable. You should not have to know the
destination to understand what something fundamentally is. You can't
redefine language syntax based on the function being called.

[Chris Angelico]

On Wed, Aug 22, 2018 at 4:56 AM, Abe Dillon <abed...@gmail.com> wrote:
> [Chris Angelico]
>>
>> In English, "card is not wild" can
>> be interpreted as a membership check, but in Python, it is only an
>> identity check; you're capitalizing on false readability by using this
>> notation.
>
>
> I promise that wasn't my intent. Since both my proposed form and the lambda
> form use the same expression,
> it doesn't really tip the balance in favor of my argument. Also, most toy
> card problems I work with use a finite,
> immutable set of cards, so identity checking isn't *that* weird.

Fair enough. To be fair, I use decks of cards primarily for non-game
usage (for instance, teaching data structures and algorithms - cards
laid out on a table can represent a tree, heap, array, etc), and my
decks of cards are artistic. A deck containing four suits of thirteen
cards plus one joker would have 53 cards, which is a prime number;
printing 54 cards lets you lay them out as 9 by 6 on a sheet, so it's
easy to add a second joker. Some decks (I have an Alice in Wonderland
themed deck) have *four* jokers.

As such, the most logical way to do this would be as an attribute of
the card. Its jokerness is as much a feature as the clubness of
another card. You can pick up a physical card, look at it, and say
"This is a joker"; you don't have to see if it's in a list of specific
known jokers.

hand = sorted(cards, by=value[card.suit] if not card.wild else
max_value with card)

Honestly, though, it'd usually be more interesting to sort by rank
within suit. What you're doing here would group the cards by suit,
ignoring their ranks; more useful would be:

hand = sorted(cards, key=lambda card: (card.is_wild, card.suit, card.rank))

Much cleaner. No conditionals needed.

[Abe Dillon]

[Chris Angelico]

That right there is unacceptable. You should not have to know the
destination to understand what something fundamentally is.

You don't *have* to know what the parameter "key" is to know that (value[card.suit] ... with card) is a function. You can identify that it's a function just by reading the full expression. However, if you don't know what "key" is, then it'll cause far more confusion than the late declaration of the function's parameters.

[Chris Angelico]

You can't redefine language syntax based on the function being called.

That's not at all what I suggested. You were walking through my example from the reader's perspective. I was explaining how the reader will often have plenty of context about what they're reading before they get to the signature declaration. Whether it be because they know what the "key" parameter means or because they know "card" is undeclared or both. I never claimed the language syntax should be based on the function being called.

func = value[card.suit] if card not in wilds else wild_value with card

Works independent of the function being called. It's just not a common use case because it obviates the expressiveness of anonymous functions. You might as well use a "def" statement.

The thing that makes callbacks difficult is not knowing how they're called. I tried to throw a little JavaScript into my curriculum once thinking "how bad can it be?" and suggested my students work on a project using the Force Directed Graph from D3.js. That was a HUGE mistake not because anonymous functions are confusing but because the example (at the time) had no documentation at all (like this one) and used mysterious callbacks everywhere. The main documentation for D3.js is super difficult to navigate, when all you want to do is slightly modify one of the examples (use svg images for the nodes and have stats display "on mouse over").

If you don't know what "".join() does, then you're going to have trouble making sense of:

def initials(person):
     return "".join(name[0] + "." for name in person.names if name)

The late assignment of the name variable will NOT be your main source of confusion. If you do know what "".join() does, then it should take you much less context to realize you're reading a generator expression. By the time you read the yet-to-be-assigned "name" variable you should be tipped off.

[Chris Angelico]

On Wed, Aug 22, 2018 at 6:24 AM, Abe Dillon <abed...@gmail.com> wrote:
> [Chris Angelico]
>>

>> That right there is unacceptable. You should not have to know the
>> destination to understand what something fundamentally is.
>
>
> You don't *have* to know what the parameter "key" is to know that
> (value[card.suit] ... with card) is a function. You can identify that it's a
> function just by reading the full expression. However, if you don't know
> what "key" is, then it'll cause far more confusion than the late declaration
> of the function's parameters.
>
> [Chris Angelico]
>>
>> You can't redefine language syntax based on the function being called.
>
>
> That's not at all what I suggested. You were walking through my example from
> the reader's perspective. I was explaining how the reader will often have
> plenty of context about what they're reading before they get to the
> signature declaration. Whether it be because they know what the "key"
> parameter means or because they know "card" is undeclared or both. I never
> claimed the language syntax should be based on the function being called.
>
> func = value[card.suit] if card not in wilds else wild_value with card
>
> Works independent of the function being called. It's just not a common use
> case because it obviates the expressiveness of anonymous functions. You
> might as well use a "def" statement.

Python's parser is *deliberately* incapable of backtracking this far
in its definition of syntax. So if you want to have something where
the first long slab of it is entirely acceptable as an expression,
right up until you get to the "with" at the end, it's not going to
work. You then said that it was the parameter "key" that told you that
this would be a function, which is also unacceptable in Python syntax.
So how do you intend to do this?

And you still haven't done anything to show that this is actually
better than "lambda card:" at the beginning. I'm done.

[Abe Dillon]

[Chris Angelico]

I use decks of cards primarily for non-game
usage (for instance, teaching data structures and algorithms - cards
laid out on a table can represent a tree, heap, array, etc)

I do too. They're a great tool for visualizing and physically trying out different techniques.

[Chris Angelico]

A deck containing four suits of thirteen
cards plus one joker would have 53 cards, which is a prime number;
printing 54 cards lets you lay them out as 9 by 6 on a sheet, so it's
easy to add a second joker. Some decks (I have an Alice in Wonderland
themed deck) have *four* jokers.
As such, the most logical way to do this would be as an attribute of
the card.

In most cases I've seen wild cards used, it's a declaration about a certain card (e.g. "Eights are wild."
or "The 2 of clubs is wild."). I've found that if you're trying to model a game like poker or Monopoly, it's tempting to add complexity to simple objects, but it can lead to problems later on. A card doesn't know if it's wild. That's a function of the game being played. An ace may be high or low.

[Chris Angelico]

On Wed, Aug 22, 2018 at 6:33 AM, Abe Dillon <abed...@gmail.com> wrote:
> [Chris Angelico]
>>

>> I use decks of cards primarily for non-game
>> usage (for instance, teaching data structures and algorithms - cards
>> laid out on a table can represent a tree, heap, array, etc)
>
>
> I do too. They're a great tool for visualizing and physically trying out
> different techniques.
>
> [Chris Angelico]
>>
>> A deck containing four suits of thirteen
>> cards plus one joker would have 53 cards, which is a prime number;
>> printing 54 cards lets you lay them out as 9 by 6 on a sheet, so it's
>> easy to add a second joker. Some decks (I have an Alice in Wonderland
>> themed deck) have *four* jokers.
>> As such, the most logical way to do this would be as an attribute of
>> the card.
>
>
> In most cases I've seen wild cards used, it's a declaration about a certain
> card (e.g. "Eights are wild."
> or "The 2 of clubs is wild."). I've found that if you're trying to model a
> game like poker or Monopoly, it's tempting to add complexity to simple
> objects, but it can lead to problems later on. A card doesn't know if it's
> wild. That's a function of the game being played. An ace may be high or low.

Well, okay. Then you should check if the card is a joker, rather than
checking if it's wild. That means your sort function is "by suit, and
within that by rank, but jokers are at the end" (ignoring wildness).

That said, though... I've seen and used a Canasta deck of cards, which
have game-specific information printed on them. Physical cards. So
there's precedent for that!

[Jonathan Fine]

Hi Abe

First, I have reservations about the name lambda. But there's a lot of
code out there that uses lambda, and I'd like that code to continue to
run.

You wrote:
> func = value[card.suit] if card not in wilds else wild_value with card

I thought I'd try this, and variants, in the Python interpreter. I got

# An expression. It's valid syntax, get run-time error.

>>> value[card.suit] if card not in wilds else wild_value

NameError: name 'card' is not defined

# An expression. It's valid syntax. Its value is a function. No run-time error.
>>> lambda card: value[card.suit] if card not in wilds else wild_value
<function <lambda> at 0x7ff815e2bbf8>

# If Python were enhanced, an valid expression whose value is a function.

>>> value[card.suit] if card not in wilds else wild_value with card

SyntaxError: invalid syntax

My understanding is that you prefer
>>> EXPRESSION with IDEN
to
>>> lambda IDEN: EXPRESSION

How do you feel about this, as a means of defining an anonymous function?
>>> with IDEN: EXPRESSION

We can't adopt it, of course, because it's already valid syntax, but
with semantics.

>>> with wibble:
... wobble
NameError: name 'wibble' is not defined

Now for a trick question. Consider
>>> fn = (lambda : EXPRESSION)
This produces a function that has zero parameters.

How would you write this, using 'with'. Would it be:
>>> fn = (EXPRESSION with)
I think this looks rather odd.

--
Jonathan

[Abe Dillon]

[Jonathan Fine]

I have reservations about the name lambda. But there's a lot of
code out there that uses lambda, and I'd like that code to continue to
run.

Yes. I'm under no delusion that lambda will be replaced any time soon. Nor do I believe any alternative I suggest will be enough of an improvement to warrant breaking the "there should be one and only one obvious way to do something rule". So I don't expect this conversation to lead to any change to the language, I just think my case that it's sub-optimal might inform future design decisions. Though it doesn't look like anyone finds it especially convincing.

[Jonathan Fine]

My understanding is that you prefer
>>> EXPRESSION with IDEN
to
>>> lambda IDEN: EXPRESSION

Correct. My argument is two fold:

1) the name "lambda" is needlessly esoteric.
2) the format of lambdas is "backwards"

I tried to focus on the name gripe in this thread because trying to explain both at the same time caused confusion. However, Stephen Turnbull's and (more so) Steven D'Aprano's comments made the format argument semi-relevant and I can't help getting on that soap-box...

[Jonathan Fine]

How do you feel about this, as a means of defining an anonymous function?
>>> with IDEN: EXPRESSION

I think it's better than lambda. I can't decide if I like it more than:

>>> def IDEN: EXPRESSION

Because def is more clearly connected to function declaration and i'm somewhat sympathetic to the idea of expressionizing "with"-statements.
The only reason I don't prefer:

>>> EXPRESSION def IDEN

to 

>>> EXPRESSION with IDEN

Is that it looks weird to me. It just doesn't seem right.

[Jonathan Fine]

Now for a trick question. Consider
>>> fn =  (lambda : EXPRESSION)
This produces a function that has zero parameters.
How would you write this, using 'with'. Would it be:
>>> fn = (EXPRESSION with)
I think this looks rather odd.

That's a good point. I hadn't considered that. There are several possible formats that put the expression before the signature definition. The specific form isn't quite as interesting to me. I would even prefer something like:

>>> def (EXPRESSION [<seperator> SIG])

Mostly because "def" could then have a double meaning: "define" and "deferred expression". I think that's kinda neat. My problem with putting the signature first is that it usually amounts to noisy preamble that gets in the way of the important code. In pseudo code you'd often write:

>>> hand = sorted(cards, by=card.suit)

But obviously the compiler doesn't know what "card" is since it's never declared, so we write:

>>> hand = sorted(cards, by=lambda card: card.suit)

Notice that the information that's important to the reader: the expression, is pushed behind information the computer needs but the reader probably doesn't care about.
My claim is that in most cases, the signature is more noise than signal, so it should come after the expression.

A function passed as a callback, key-function, mapper, reducer, filter, event handler, etc. has a mostly pre-defined call signature. In most other cases, you're better off using a named function.

Thanks for your input!

[Abe Dillon]

[Chris Angelico]

Python's parser is *deliberately* incapable of backtracking this far
in its definition of syntax.

Can you explain how far the parser is capable of backtracking?
It seems like <expression> with <signature> would require a similar amount of backtracking to ternary expressions:

<expression> if <condition> else <expression>

If the preceding expression is the same in both cases, then the parser needs to backtrack just as far when it finds an "if" as when it finds a "with".

[Chris Angelico]

You then said that it was the parameter "key" that told you that
this would be a function, which is also unacceptable in Python syntax.

That was *never* a statement about syntax. It was about the context clues a reader has, not the parser. The proposed syntax: <expression> with <signature> is an expression that evaluates to a function object regardless of any parameter or any function it might or might not be passed to.

My argument is simply: Most cases where an anonymous function is more expressive than a named function are also cases where, *from the perspective of a human reading the code*, the signature is noisy preamble that gets in the way of the expression.

In psuedo code, people tend to write things like:

>>> hand = sorted(cards, by=card.suit)

Obviously that wouldn't compile because the computer doesn't know what "card" is. However;

>>> hand = sorted(cards, by=lambda card: card.suit)

puts a bunch of noise that's mostly of interest to the computer in front of the expression that's of interest to the reader. There is precedent for late-variable-binding in Python expressions already (e.g. comprehensions), so it makes sense to me that the expression version of function declaration could also bind the signature after the main expression.

The same logic follows for mappers, reducers, filters, callbacks, event-handlers, etc.

[Chris Angelico]

So how do you intend to do this?

I don't intend any of this to make its way into Python. It's a case study of expression design. It's interesting to me to explore such alternatives. It's fine to prod it and examine its flaws as Jonathan Fine has.

[Chris Angelico]

And you still haven't done anything to show that this is actually
better than "lambda card:"

I'm trying to, but I also have to answer all your misconceptions about the idea (like that the syntax is function or parameter-dependent).

[Chris Angelico]

I'm done.

OK. I'm sorry if I upset you.

[Chris Angelico]

On Wed, Aug 22, 2018 at 8:45 AM, Abe Dillon <abed...@gmail.com> wrote:
> [Chris Angelico]
>>
>> Python's parser is *deliberately* incapable of backtracking this far
>> in its definition of syntax.
>
>
> Can you explain how far the parser is capable of backtracking?
> It seems like <expression> with <signature> would require a similar amount
> of backtracking to ternary expressions:
>
> <expression> if <condition> else <expression>
>
> If the preceding expression is the same in both cases, then the parser needs
> to backtrack just as far when it finds an "if" as when it finds a "with".

I have to defer to someone who knows in more detail here, but the
parser will look ahead one "token", whatever a token is. (Technically
it doesn't backtrack, it looks ahead - same difference.) In order for
the ternary-if to work, the expression before the if has to be of a
more restricted type than just "any expression" (for instance, you
can't put a lambda function there, unless you parenthesize it). But
I'm not fluent in all the details, and I definitely am not comfortable
citing exactly what the limits are. The last time I tried editing the
grammar, weird things happened.