On 2/23/21 10:07 AM, Paul Sokolovsky wrote:
> Hello,
>
> On Tue, 23 Feb 2021 09:35:58 -0500
> Richard Damon <rich...@damon-family.org> wrote:
>
> []
>
>> My first thought to the idea of making an alternate syntax is the line
>> from the Zen:
>>
>> There should be one-- and preferably only one --obvious way to do it.
>> Although that way may not be obvious at first unless you're Dutch.
>>
>> This says that if the 'arrow' is a new alternate way of writing
>> lambda, then lambda needs to be, at least informally, deprecated and
>> declared not to be that obvious way to do it (but it can't be
>> actually removed for a long time for backwards compatibility reasons).
> No more than "+" deprecates __add__, or vice-versa. And no more than
> various pop-up novelties (we now have more than one) deprecate sacred
> '"%s" % var' syntax.
The difference with + is that it NEVER was the case that the 'preferred'
way to add two values was with a direct call to __add__ (it was just an
internal implmentation detail for the operator).
As far as formatting strings, yes, there are multiple ways to do similar
things, but there are also significant differences between them. If we
look at 'f-strings' as the example, I beleive f-strings are now
considered the 'preferred obvious' way to do it, when it is applicable,
but that there are still significant cases where you can't use the
f-string, because it is a 'compile' time construct. For things like
translation strings, where the string comes from some string store, and
at run time combined with the variable, you still need do this with the
older % or .format() method.
As far as between % or .format(), I think the documentation is fairly
clear that the % method is 'old' and if not 'formally' deprecated, is no
longer considered the 'obvious' way to do it (even if some people will
still do it that way for the simplest cases).
>> Note, I thought that lambda was currently 'multi-line', it just isn't
>> multi-statement, just a single expression, that could flow to
>> following lines (and since often used inside a function call, being
>> inside the '(' makes the continuation to the next line automatic)
> Yes, people who colloquially say "multi-line", formally mean
> multi-statement. (Alternatively, they mean "multi-line without tricks".)
People colloquially using the wrong words shouldn't get surprised when
they get corrected. It isn't a 'trick' to make a Python expression
'multi-line', it is just standard Python formatting.
Now, if lambda can 'grow up' to be a 'multi-statement expression' (whch
I think is part of the issue) then perhaps there is room for both lambda
and 'arrow functions', just like string formatting has both f-strings
and .format().
That is a big 'IF', as putting statement-blocks into code as pieces of
an expression, is a cognitive barrier, and may well require a syntax
change (perhaps using an anonymous def inside the expression), and I am
not sure how common it can be found (I know in C, it is only available
as a semi-common extension in some compilers).
Also note, that I am not saying that 'arrow-functions' can't happen,
just that if they are created, a natural consequence is that, like with
.format(), the 'old' (lambda) way will need to be marked as 'old', and
not the current obvious way.
--
Richard Damon
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/IQOPRB4NQBLXNGGHGOETIKYPAWQAMPUE/
Code of Conduct: http://python.org/psf/codeofconduct/
