__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/

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:
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__
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/
participants (3)
-
Christopher Barker
-
george.winton.harding@gmail.com
-
Ricky Teachey