[Python-ideas] Re: Alternate lambda syntax
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
> wrote:
>
> 2qdxy4rzwzuui...@potatochowder.com writes:
>>> On 2021-02-18 at 18:10:16 +0400,
>>> Abdulla Al Kathiri 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/
[Python-ideas] Re: Alternate lambda syntax
2qdxy4rzwzuui...@potatochowder.com writes: > On 2021-02-18 at 18:10:16 +0400, > Abdulla Al Kathiri 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] Re: Alternate lambda syntax
On 19/02/21 9:43 am, Steven D'Aprano wrote: Although I have heard from Ruby enthusiasts that the ability to write large, complex, multi-statement anonymous block functions is really useful, its not something I can personally say I have missed. Ruby may be somewhat different here, because Ruby's equivalent of things like the iterator protocol work by passing in a block of code representing the loop body, so having an easy way to write that is important. -- Greg ___ 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/OWJSH7YOKDASTILTGNMPW4YTBGV3SZPU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Thu, Feb 18, 2021 at 8:46 PM Steven D'Aprano wrote: > Although I have heard from Ruby enthusiasts that the ability to write > large, complex, multi-statement anonymous block functions is really > useful, its not something I can personally say I have missed. > I think that once you get past a fairly simple one-line expression, > anything else ought to be tested; and that requires making it a named > function at the top level so that doctest or unittest can see it. > I think I can kinda sympathize with that perspective. Just like you sometimes have an elif block where "a bunch of stuff happens", sometimes you have a callback function that is only used by one other function. It cannot be a block in current Python because it's a callback, but it doesn't *really* have a meaningful name outside that of the enclosing function. On other hand, writing an inner function and using the throwaway name `fn` for it requires two extra characters. OK, maybe 4 characters since it is both defined and then used. Of course, exact character count depends on the hypothetical syntax of a "multi-statement lambda" ... but it amounts to "no big deal" in existing Python, in any case. ___ 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/I6DZPPDI6KPAOS573VWNLUZE6TP7LUTP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Wed, Feb 17, 2021 at 07:03:55PM +, Gustavo Carneiro wrote: > Just my 2c, I don't find lambda verbose at all, quite like it. > > But I wish Python allowed for multi-line lambda functions... somehow. Python allows for multi-*line* lambda: lambda key, value, condition, sep='', default='': ( compute_prefix(key) + sep.join([str(expression or default) for obj in lookup(key, value) if condition(obj)] ) + compute_suffix(key) ) What it doesn't allow is multi-*statement* lambda; lambda is limited to a single expression. Although I have heard from Ruby enthusiasts that the ability to write large, complex, multi-statement anonymous block functions is really useful, its not something I can personally say I have missed. I think that once you get past a fairly simple one-line expression, anything else ought to be tested; and that requires making it a named function at the top level so that doctest or unittest can see it. -- Steve ___ 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/AWP6IPKTD6WYTBUCHZ4NWD2MJ6OLZLQ3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On 2021-02-18 at 18:10:16 +0400, Abdulla Al Kathiri 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. > print(func(3, 4, (x, y) => x + y)) #Out: 7 > > Imagine your mouse is on :func: ‘func’ in VSC or PyCharm and see that > you need the third parameter to be of type (int, int) -> int, you can > immediately write an anonymous function that mirrors the structure of > the annotation but instead of ->, you have =>. Straight forward. If my IDE is that clever, then it can also type "lambda x, y: " for me in addition to showing me that signature. Aside: And then a thousand developers/engineers/maintainers, auditors, and testers (not to mention future me) have to read that anonymous function. Over and over. And over. Unless it's trivial, or simpler, use a def statement, give it a name and a doc string, test it, and reuse it. And if it's that trivial, then trading "lambda" for "->" (or "=>") doesn't matter. ___ 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/4QNOE7AFAAYWZWQQJ24GCUMFVX2JBI4F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
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) print(func(3, 4, (x, y) => x + y)) #Out: 7 Imagine your mouse is on :func: ‘func’ in VSC or PyCharm and see that you need the third parameter to be of type (int, int) -> int, you can immediately write an anonymous function that mirrors the structure of the annotation but instead of ->, you have =>. Straight forward. > On 18 Feb 2021, at 12:43 PM, Paul Sokolovsky wrote: > > (x, y) -> x + ytranslates to: Callable[[x, y], x + y] > > while > > (x, y) => x + ytranslates to: lambda x, y: x + y > > Huge difference. ___ 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/V7KSM464X2ECGWUQFZ5OH4A74LIHF4HG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Thu, Feb 18, 2021 at 9:57 PM Steven D'Aprano wrote: > > On Thu, Feb 18, 2021 at 06:21:19AM +1100, Chris Angelico wrote: > > > > I would personally love for SimpleNamespace to get a shorter name and > > > become a built-in. > > > > > > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a > > builtin, what should its name be? > > The traditional name is "Bunch". Nineteen years ago, Alex Martelli's > recipe for Bunch was published in the Python Cookbook. You can still > find the recipe here: > > https://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-bunch-of-named/ > > Another common name is "Bag", although I've also seen that used as a > name for a multiset. > Yeah, not a fan of Bag because of that usage, but I'm liking Bunch. ChrisA ___ 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/H5BKHDW5F4H3RCWFWO5EYEENTSEBCGM7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On 18.02.2021 12:00, Steven D'Aprano wrote: > On Wed, Feb 17, 2021 at 11:28:05AM -0800, Brendan Barnwell wrote: > >> When I see people suggest >> SimpleNamespace, it's usually just to use it as a dict which is accessed >> with attribute syntax instead of item syntax. > > If its a dict, it must have dict methods. That leads to conflict: data > fields and methods collide. > > A Bunch (see my previous post) or SimpleNamespace doesn't have that > problem. A Bunch has no methods (apart from dunders) and so there is no > way for them to collide with field names. > > Things like attrdict, and the Javascript "convenience" short-cut that > allows dict key:item pairs to be accessed through attribute syntax, are > an attractive nuisance because of that collision problem. I use a Namespace class for such things, with methods using an underscore as prefix to avoid clashes with attributes. It supports the attribute protocol, the dictionary protocol and also comes with some extras, such as optional defaults for unknown attributes, or formatting support. Oh, and acquisition is also supported, for those who still know how this was used in Zope to do attribute access across hierarchies. You can find this in the egenix-mx-base package under mx.Misc.Namespace. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 18 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ 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/C5HTETSX2OBYBWO4L7O3HB3OJO54DF4L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Wed, Feb 17, 2021 at 11:28:05AM -0800, Brendan Barnwell wrote: > When I see people suggest > SimpleNamespace, it's usually just to use it as a dict which is accessed > with attribute syntax instead of item syntax. If its a dict, it must have dict methods. That leads to conflict: data fields and methods collide. A Bunch (see my previous post) or SimpleNamespace doesn't have that problem. A Bunch has no methods (apart from dunders) and so there is no way for them to collide with field names. Things like attrdict, and the Javascript "convenience" short-cut that allows dict key:item pairs to be accessed through attribute syntax, are an attractive nuisance because of that collision problem. -- Steve ___ 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/5SGLEXYT37JWIB4N4LQGEUVZUQ7JOSPX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Thu, Feb 18, 2021 at 06:21:19AM +1100, Chris Angelico wrote: > > I would personally love for SimpleNamespace to get a shorter name and > > become a built-in. > > > > Okay. Let's start bikeshedding. If SimpleNamespace were to become a > builtin, what should its name be? The traditional name is "Bunch". Nineteen years ago, Alex Martelli's recipe for Bunch was published in the Python Cookbook. You can still find the recipe here: https://code.activestate.com/recipes/52308-the-simple-but-handy-collector-of-a-bunch-of-named/ Another common name is "Bag", although I've also seen that used as a name for a multiset. -- Steve ___ 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/VUKQYOMLQ4MLDOTOCA4DJDHJ4QREPDSL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
Hello, On Thu, 18 Feb 2021 21:27:18 +1100 Steven D'Aprano wrote: [] > Or we could just use a one-liner: > > >>> from types import SimpleNamespace > > and get all of that for free. And if it were a builtin, it would be a > zero-liner. Right. If the whole CPython stdlib were builtin, it all would be zero-liner. But it's not, and won't be. Even such important things as OrderedDict and namedtuple live in a module. So, SimpleNamespace will hopefully remain there too. And good luck with renaming it to something not obscure. My bet is on AttrObject ;-). [] -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/OGFFUF44AS4SHQGSJXFSMZX5RHKDJITM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SimpleNamespace vs object
On Thu, Feb 18, 2021 at 11:50:17AM +1300, Greg Ewing wrote:
> It's dead simple to define
> your own blank-object class, and you get to give it a name that
> reflects what you're really doing with it. I don't understand
> why there's such a fascination with things like SimpleNamespace.
Right, it takes only two lines of code. So let's do it!
>>> class Thing:
... pass
...
>>> obj = Thing(attr='value')
Traceback (most recent call last):
File "", line 1, in
TypeError: Thing() takes no arguments
Hmmm. Okay, *three* lines of code:
>>> class Thing:
... def __init__(self, **kw):
... vars(self).update(kw)
...
>>> obj = Thing(attr='value')
>>> print(obj)
<__main__.Thing object at 0x7f2b07c23b80>
Damn, that's about as useful as a screen door on a submarine. Let's give
it a repr, so when debugging we can see what it actually is.
So *five* lines of code:
>>> class Thing:
... def __init__(self, **kw):
... vars(self).update(kw)
... def __repr__(self):
... return f'Thing({vars(self)})'
...
>>> obj = Thing(attr='value')
>>> print(obj)
Thing({'attr': 'value'})
>>> obj == Thing(attr='value')
False
Bugger. So **ten** lines of code:
>>> class Thing:
... def __init__(self, **kw):
... vars(self).update(kw)
... def __repr__(self):
... return f'Thing({vars(self)})'
... def __eq__(self, other):
... if isinstance(other, Thing):
... return vars(self) == vars(other)
... else:
... return NotImplemented
...
>>> obj = Thing(attr='value')
>>> print(obj)
Thing({'attr': 'value'})
>>> obj == Thing(attr='value')
True
So we've gone from a trivial two-liner that doesn't do what we need, to
ten lines, without docs or tests.
Or we could just use a one-liner:
>>> from types import SimpleNamespace
and get all of that for free. And if it were a builtin, it would be a
zero-liner.
--
Steve
___
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/GW5ZPEET5V26XE3VBSJBOFEU7CAPO6TD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
Hello, On Wed, 17 Feb 2021 18:43:09 -0300 "Joao S. O. Bueno" wrote: > On Wed, 17 Feb 2021 at 18:15, Abdulla Al Kathiri < > alkathiri.abdu...@gmail.com> wrote: > > > How is this not pythonic? > > > > series.apply(x -> x**2) > > Compared to.. > > series.apply(lambda x: x**2) > > > > > > (x, y) -> x+y, () -> 0, (x) -> x**2 (for single parameter, we can > > write it without parenthesis like the example above) are pythonic > > enough to my eyes. As said many times already, that's not Pythonic, because "->" is used in Python for return *type* annotation, and thus cannot be used as lambda synonym (without hampering understandability for machines and humans). To illustrate it, (x, y) -> x + ytranslates to: Callable[[x, y], x + y] while (x, y) => x + ytranslates to: lambda x, y: x + y Huge difference. > Well, for m eyes, the above is definetellly "perlonic" . it could be > "j" before being Pyrhon. That's unlikely, in Perl it would be something like $x+$y $) ql/x y/. As was said from the very beginning, "(x, y) => x + y" is "JavaScriptonic". For reference, JavaScript is the world's leading programming language, and now even turned out that it has some "good parts" (much later than originally supposed). So, people are looking how to "steal" those good parts. (Just the same as previously, JS "stole" generators from Python). -- Best regards, Paul mailto:pmis...@gmail.com ___ 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/MRNRM777SG5L5W6QMVUSKHJDCUYUKNCV/ Code of Conduct: http://python.org/psf/codeofconduct/
