def test(self, func: t.Callable[..., bool], *args, **kwargs) -> Predicate:
"""
Run a user-defined test function against the value.
>>> def test_func(val):
... return val == 42
...
>>> var('f1').test(test_func)
:param func: The function to call, passing the dict as the first
argument
:param args:
:param kwargs:
Additional arguments to pass to the test function
"""
return self._build_predicate(
lambda lhs, value: func(lhs, *args, **kwargs),
Operation.TEST,
(self._path, func, args, freeze(kwargs))
)
Becomes ....
def test(self, func: (...) -> bool, *args, **kwargs) -> Predicate:
"""
Run a user-defined test function against the value.
>>> def test_func(val):
... return val == 42
...
>>> var('f1').test(test_func)
:param func: The function to call, passing the dict as the first
argument
:param args:
:param kwargs:
Additional arguments to pass to the test function
"""
return self._build_predicate(
(lhs, value) => func(lhs, *args, **kwargs),
Operation.TEST,
(self._path, func, args, freeze(kwargs))
)
Sent from my iPhone
> On 19 Feb 2021, at 9:03 AM, Stephen J. Turnbull
> <turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
> 2qdxy4rzwzuui...@potatochowder.com writes:
>>> On 2021-02-18 at 18:10:16 +0400,
>>> Abdulla Al Kathiri <alkathiri.abdu...@gmail.com> wrote:
>>>
>>> I will be very happy if those versions of Callable and anonymous
>>> functions exist in Python right now. See how elegant that would look
>>> like..
>>>
>>> def func(x: int, y: int, f: (int, int) -> int) -> int:
>>> return f(x, y)
>>
>> Elegant? I realize that this is a contrived scenario, but even if the
>> identifiers x, y, and f were meaningful (e.g., account_balance,
>> socket_descriptor), the signal to noise ratio in that definition makes
>> me cringe. And it only gets worse once I'm not dealing with ints.
>
> I'm -1 on the Arrow proposal, but old Lisper that I am I do define
> functions like that. I would write it:
>
> def post_to_auditor(
> account_balance: PosIntPennies,
> socket_descriptor: Socket,
> validator: (PosIntPennies, Socket) -> Bool
> ) -> Bool:
>
> which I don't think is bad at all.[1] Is the S/N really so bad?
> (Aside from the fact that try as I could I couldn't think of even one
> reason for passing both account_balance and socket_descriptor to the
> same user-supplied function, an idea that made my ears ring).
>
> I think it's important in these things that we avoid taking toy
> examples and criticizing them for points that they weren't intended to
> make. It's also useful to use real code to avoid this kind of
> criticism. Most of the really strong arguments for syntax changes
> that I've seen take the stdlib, or some other large body of code (in
> this case I would bet Sympy would be a candidate) and show how the
> change improves its expressiveness.
>
>
> Footnotes:
> [1] Don't ask me about the docstring, I am a game theorist, not an
> accountant nor a network engineer.
> _______________________________________________
> 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/IHS7H5JDTROSUYEEPDYPXW7XHY45GSVO/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/6D4DRQSBRYIELHY6ATIM2FJAKTQYJCUM/
Code of Conduct: http://python.org/psf/codeofconduct/
