__call__ on lists, dicts etc.
Hi all, I've been working in q and k, which is where this idea comes from. My idea is to make lists and dicts callable, with __call__ = __getitem__. So that: [3,4,5](1) gives 4 {'a':1, 'b': 2}('b') gives 2 Arguably a list is a function which maps from range(len(list)) to the list entries, and a dictionary is a function that maps from keys to values. This would mean that functions designed to take functions, can be repurposed to take data, for example: map(lst, idxs) instead of (lst[i] for i in idxs) or map(lambda x: lst[x], idxs) map(dct, lst) instead of (dct[l] for l in lst) sorted(range(len(lst)), key=lst) to calculate the equivalent of np.argsort max(range(len(lst)), key=lst) to calculate the equivalent of np.argmax I couldn't find this being discussed before. Does anyone like it? There is room for confusion as it would mean that e.g. filter([1,2], [0,1]) would give [0,1] whilst [1] might be expected. Best, George Harding p.s. Thank you to everyone for their work on such a wonderful language.
Well there is already a function you can call for these, __getitem__: lst_getter = lst.__getitem__ map( lst_getter, idxs) sorted(range(len(lst)), key=lst_getter) max(range(len(lst)), key=lst_getter) dct_getter = dct.__getitem__ map(dct, lst) instead of (dct[l] for l in lst) If you find yourself preferring this map() style of code a lot (rather than using generator expressions), you can make a utility function: def getter(obj): return obj.__getitem__ If anything is going to be proposed, I'd suggest rather than making these callable directly, add a utility function that calls the dunder method. So: len() is to __len__ as: getter() is to __getitem__ But I'm not proposing this, I'm just suggesting it as a bit better alternative to the initial idea. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler On Mon, Oct 5, 2020 at 8:42 AM <george.winton.harding@gmail.com> wrote:
Hi all,
I've been working in q and k, which is where this idea comes from.
My idea is to make lists and dicts callable, with __call__ = __getitem__.
So that:
[3,4,5](1) gives 4 {'a':1, 'b': 2}('b') gives 2
Arguably a list is a function which maps from range(len(list)) to the list entries, and a dictionary is a function that maps from keys to values.
This would mean that functions designed to take functions, can be repurposed to take data, for example:
map(lst, idxs) instead of (lst[i] for i in idxs) or map(lambda x: lst[x], idxs) map(dct, lst) instead of (dct[l] for l in lst)
sorted(range(len(lst)), key=lst) to calculate the equivalent of np.argsort max(range(len(lst)), key=lst) to calculate the equivalent of np.argmax
I couldn't find this being discussed before. Does anyone like it? There is room for confusion as it would mean that e.g. filter([1,2], [0,1]) would give [0,1] whilst [1] might be expected.
Best,
George Harding
p.s. Thank you to everyone for their work on such a wonderful language. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/MZCYYF... Code of Conduct: http://python.org/psf/codeofconduct/
If you find yourself preferring this map() style of code a lot (rather
Please no. If you want lisp, use lisp (or something in the lisp family) On Mon, Oct 5, 2020 at 5:53 AM Ricky Teachey <ricky@teachey.org> wrote: than using generator expressions), you can make a utility function: def getter(obj): return obj.__getitem__ or use the ones that are already in the stdlib: In [3]: operator.attrgetter? Init signature: operator.attrgetter(self, /, *args, **kwargs) Docstring: attrgetter(attr, ...) --> attrgetter object Return a callable object that fetches the given attribute(s) from its operand. After f = attrgetter('name'), the call f(r) returns r.name. After g = attrgetter('name', 'date'), the call g(r) returns (r.name, r.date). After h = attrgetter('name.first', 'name.last'), the call h(r) returns (r.name.first, r.name.last). -CHB --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler
On Mon, Oct 5, 2020 at 8:42 AM <george.winton.harding@gmail.com> wrote:
Hi all,
I've been working in q and k, which is where this idea comes from.
My idea is to make lists and dicts callable, with __call__ = __getitem__.
So that:
[3,4,5](1) gives 4 {'a':1, 'b': 2}('b') gives 2
Arguably a list is a function which maps from range(len(list)) to the list entries, and a dictionary is a function that maps from keys to values.
This would mean that functions designed to take functions, can be repurposed to take data, for example:
map(lst, idxs) instead of (lst[i] for i in idxs) or map(lambda x: lst[x], idxs) map(dct, lst) instead of (dct[l] for l in lst)
sorted(range(len(lst)), key=lst) to calculate the equivalent of np.argsort max(range(len(lst)), key=lst) to calculate the equivalent of np.argmax
I couldn't find this being discussed before. Does anyone like it? There is room for confusion as it would mean that e.g. filter([1,2], [0,1]) would give [0,1] whilst [1] might be expected.
Best,
George Harding
p.s. Thank you to everyone for their work on such a wonderful language. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/MZCYYF... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/OPXPI5... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
participants (3)
-
Christopher Barker -
george.winton.harding＠gmail.com -
Ricky Teachey