On 3/28/2019 12:29 PM, Alexey Muranov wrote:
On jeu., Mar 28, 2019 at 5:00 PM, python-list-requ...@python.org wrote:
So my opinion is that lambda expressions should only be used within
larger expressions and never directly bound.
It would be however more convenient to be able to write instead just
f(x) = x*x
Given my view above, this is, standing alone, strictly an abbreviation
of the equivalent def statement. I am presuming that a proper
implementation would result in f.__name__ == 'f'.
No, after some thought, i think it should be an abbreviation of "f =
lambda x: x*x", f.__name__ would still be '<lambda>'.
Throwing the name away is foolish. Testing functions is another
situation in which function names are needed for proper report. I wrote
and use a test function something like the following, simplified and
adapted for use with unittest:
def ftest(func, io_pairs):
errors = []
for input, expected in io_pairs:
actual = func(input)
if actual != expected:
errors.append(
f"Func: {func.__name__}, input: {input}, "
f"expected: {expected}, actual: {actual}.")
return errors if errors else None
(Then "self.assertNone(ftest(func, io_pairs))" will test all pairs and
list at least part of the error list.)
If all the names were '<lambda>', not very useful. (The workaround
would be to require the caller to know a name and pass it separately,
without mis-typing.)
for unittest, a
But i see your point about never assigning lambdas directly, it makes
sense. But sometimes i do assign short lambdas directly to variable.
Is the convenience and (very low) frequency of applicability worth the
inconvenience of confusing the meaning of '=' and complicating the
implementation?
I do not see any conflicts with the existing syntax.
It heavily conflicts with existing syntax. The current meaning of
target_expression = object_expression
is
1. Evaluate object_expression in the existing namespace to an object,
prior to any new bindings and independent of the target_expression.
2. Evaluate target_expression in the existing namespace to one or more
targets.
3. Bind object to target or iterate target to bind to multiple targets.
I do not thick so. In "x = 42" the variable x is not evaluated.
All examples of the proposed syntax i can think of are currently
illegal, so i suppose there is no conflicts. (I would appreciate a
counterexample, if any.)
You are talking about syntax conflicts, I am talking about semantic
conflict, which is important for human understanding.
Thanks for the reference to PEP 8, this is indeed an argument against.
The situation in which assigning lambda expressions is more tempting is
when assigning to attributes or dicts.
def double(x): return x*x
C.double = double
d['double'] = double
versus
C.double = lambda x: x*x
d['double'] = lambda x: x*x
For attributes, "def C.double(x): return x*x" has been proposed but not
accepted.
--
https://mail.python.org/mailman/listinfo/python-list
