[Steven D'Aprano]
> most importantly, "def" with "fun", which will have the
> advantage of making Python programming more fun!
I'm sold. Make the change and SHIP IT!
No need for committee approval.
[Steven D'Aprano]
> If we're going to break people's code by
> changing keywords, let's do it properly! *wink*
I'm not backing this proposal, but I am curious what the proposal could
break.
[Steven D'Aprano]
> - Two fewer keystrokes.
THREE!!!
[Steven D'Aprano]
> - but "def" is still jargon that needs to be learned.
It already has to be learned and it's already associated with function
declaration.
[Steven D'Aprano]
> I don't think this cosmetic change comes even close to the break-even
> point of costs versus benefits. Maybe if we were designing Python from
> scratch today, there would be a good argument to be made for using def
> in both the statement and expression form, but even that's not a sure
> thing. Changing it *now* is more costly with less benefit.
Yeah, that's pretty much my take on the matter.
That ship sailed way back when Py3k was finalized.
[Steven D'Aprano]
> To give an example of a problematic keyword where changing it is not
> just cosmetic, for many years, consider the "for...else" statement. It
> seems to be saying:
> run the for loop
> *or else* run this block
> but that's not what it actually means. But even if we had consensus that
> the "else" keyword should be changed (to what? "then" is my suggestion),
> the benefit is probably too small to disrupt the Python ecosystem by
> actually making that change.
for-finished?
for-done?
for-stopped? # referencing StopIteration
for-anything_but_else?
[Steven D'Aprano]
>
> By the way, I'll also point out that the way you have demonstrated the
> use of anonymous functions is considered a (mild) abuse of syntax. Your
> example:
> # reverting back to lambda for the moment
> hn = lambda a, b=2, c=3: a ** b / c
> ought to be written as:
> def hn(a, b=2, c=3): return a ** b / c
Oh, come-on; D'Aprano! That was just to demonstrate properties of the
resulting object.
It's not meant to be production code.
[Steven D'Aprano]
> Replacing the keyword:
> results = map(def a, b=2, c=3: a ** b / c, sequence)
> widget.register(callback=def: spam.eggs())
> Doesn't look so attractive now, I wager. Using "def" inside an
> expression looks strange. And this looks outright disturbing:
> def method(self, arg, callback=def arg: arg+1):
> pass
Eh... I think they look fine. Which is worse:
def method(self, arg, callback=def arg: arg+1):
pass
or
lambda arg, callback=lambda arg: arg+1: None
because the second one makes me go cross-eyed...
On Tue, Aug 21, 2018 at 8:55 PM, Steven D'Aprano <st...@pearwood.info>
wrote:
> On Tue, Aug 21, 2018 at 10:27:20PM +0100, Jonathan Fine wrote:
>
> > Here is my simple proposal. Enhance Python to allow
> >
> > >>> hn = def a, b=2, c=3: a ** b / c
>
> Enhancements ought to allow us to write new code that we couldn't do
> before, or open up new kinds of algorithms that weren't easy or possible
> before.
>
> This is a mere cosmetic change, replacing a perfectly valid keyword with
> one which clashes with an existing keyword in what I consider to be an
> ugly way.
>
> While we're at it, perhaps we ought to replace:
>
> - "else" with "otherwise"
> ("else" is a weird word, outside of programming we hardly ever use it
> without a leading "or")
>
> - "import" with "load" (shorter)
>
> - "for" with "repeat with"
> (I've always found it awkward that the word "for" sounds like an number)
>
> - "raise" with "throw"
>
> - and most importantly, "def" with "fun", which will have the
> advantage of making Python programming more fun!
>
> Admittedly these run into backwards-compatibility issues, which your
> suggestion does not. But if we're going to break people's code by
> changing keywords, let's do it properly! *wink*
>
> Changing the public API of a language, its keywords, is not something to
> be done lightly. The consequences of such a change can include:
>
> - breaking backwards compatibility;
>
> - code churn (people have to "fix their code" even if it wasn't broken);
>
> - confusion ("what's the difference between def anonymous functions
> and lambda anonymous functions?");
>
> - more to learn during the transition (sometimes code uses lambda,
> sometimes def, so you need to know both)
>
> - more documentation explaining why the name is only sometimes needed;
>
> - more unit tests etc to ensure the feature works correctly, e.g. to
> test for the syntax error when people use def unanonymously when
> they should use it anonymously:
>
> map(def func(a, b, c): a+b-c, zip(seq1, seq2, seq3))
>
>
> Those costs are real and should only be paid when the benefits outweigh
> the costs. In this specific case, there's also a very real cost:
>
> - you will *seriously annoy and frustrate* those of us who like lambda
> and dislike the look of "def" inside expressions;
>
> - while only *slightly pleasing* those who have already learned lambda
> but don't like it. They've already learned the existing word, now they
> have to unlearn it.
>
> And the corresponding benefit is tiny:
>
> - The conceptual difficulties with lambda is not the word but the
> concept of anonymous functions as first class values; that doesn't
> change, so no benefit there.
>
> - One less keyword in the language (after the transition period).
>
> - Two fewer keystrokes.
>
> - but "def" is still jargon that needs to be learned.
>
> (Does it mean defeat, defame, defer, defend, or that thing bears do in
> the woods? To a non-English speaker, memorising "def" = "define" is no
> less obscure than memorising "lam" = "lambda" would be for English
> speakers.)
>
> I don't think this cosmetic change comes even close to the break-even
> point of costs versus benefits. Maybe if we were designing Python from
> scratch today, there would be a good argument to be made for using def
> in both the statement and expression form, but even that's not a sure
> thing. Changing it *now* is more costly with less benefit.
>
> To give an example of a problematic keyword where changing it is not
> just cosmetic, for many years, consider the "for...else" statement. It
> seems to be saying:
>
> run the for loop
>
> *or else* run this block
>
> but that's not what it actually means. But even if we had consensus that
> the "else" keyword should be changed (to what? "then" is my suggestion),
> the benefit is probably too small to disrupt the Python ecosystem by
> actually making that change.
>
> By the way, I'll also point out that the way you have demonstrated the
> use of anonymous functions is considered a (mild) abuse of syntax. Your
> example:
>
> # reverting back to lambda for the moment
> hn = lambda a, b=2, c=3: a ** b / c
>
> ought to be written as:
>
> def hn(a, b=2, c=3): return a ** b / c
>
> which ensures that hn has a nice name for debugging. Lambdas ought to be
> limited to in-place uses, as part of a larger expression and not just an
> assignment, probably 99% of the time. Hence:
>
> results = map(lambda a, b=2, c=3: a ** b / c, sequence)
>
> widget.register(callback=lambda: spam.eggs())
>
> are reasonable examples of how one might find lambdas in the wild.
> Replacing the keyword:
>
> results = map(def a, b=2, c=3: a ** b / c, sequence)
>
> widget.register(callback=def: spam.eggs())
>
> Doesn't look so attractive now, I wager. Using "def" inside an
> expression looks strange. And this looks outright disturbing:
>
> def method(self, arg, callback=def arg: arg+1):
> pass
>
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
