3 ms·

It's faster (better performance). It could also be preferred just as a coding style.

kzrdude 4y ago
This makes me wonder, couldn't python have a peephole optimization that replaces certain easy labmdas like this with operator functions? Maybe it's too noticeable to work as a transparent optimization (function kind and name etc changes).
- winstonewert 4y ago
  Such optimizations can't be transparent in python (at least not easily) because you could very well reassigned everything in `operator` to do whatever you want. PyPy can do it with its jit because it supports invalidating compiled code when such changes are made.
  - eesmith 4y ago
    Assuming the implementation has access to the "real" operator.itemgetter, I can't think of a case where lambda x: x['name'] cannot be replaced by a operator.itemgetter("name") and get a different result. ... except for the stack trace: >>> f = lambda x: x["A"] >>> f({"A": 3}) 3 >>> f({"B": 3}) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 1, in <lambda> KeyError: 'A' >>> import operator >>> f = operator.itemgetter("A") >>> f({"A": 3}) 3 >>> f({"B": 3}) Traceback (most recent call last): File "<stdin>", line 1, in <module> KeyError: 'A' So if 'x' implemented its own getitem and it inspected the stack (eg, how Pandas uses the 'level' parameter in 'eval' and 'query' methods to get locals() and globals()), then this change would cause different results.
    - winstonewert 4y ago
      Oh, I see. I think you are right.
deleted 4y ago
[deleted]
tonyg 4y ago
Holy shit, you're right. It's about 33% faster on Python 3.10 on my machine: import operator n1 = operator.itemgetter('name') n2 = lambda x: x['name'] x = {'name': 'abcdef'} import timeit print(timeit.timeit('n1(x)', globals=globals())) print(timeit.timeit('n2(x)', globals=globals())) I'm so surprised because I went and read (what I thought was) the source for operator.itemgetter, which boils down to a wrapper object around the plain version. It turns out that this is not the source code. As with so many other things in Python, there's a special case you have to know about: there's a separate C implementation of the operator module. :-/
- ssl232 4y ago
  > It turns out that this is not the source code. As with so many other things in Python, there's a special case you have to know about: there's a separate C implementation of the operator module. :-/ I actually kinda like that Python often maintains 100% compatible pure-Python implementations of various C modules. It's definitely niche, but I have sometimes found myself trying to work out what a module is doing (e.g. with the fancy new PEG parser) and I find it far easier to read Python than C.
- kzrdude 4y ago
  I'd expect it to be even better improvement inside sort, but maybe my hunch is wrong. The significance is greater there, at least.

This makes me wonder, couldn't python have a peephole optimization that replaces certain easy labmdas like this with operator functions? Maybe it's too noticeable to work as a transparent optimization (function kind and name etc changes).

winstonewert 4y ago
Such optimizations can't be transparent in python (at least not easily) because you could very well reassigned everything in `operator` to do whatever you want. PyPy can do it with its jit because it supports invalidating compiled code when such changes are made.
- eesmith 4y ago
  Assuming the implementation has access to the "real" operator.itemgetter, I can't think of a case where lambda x: x['name'] cannot be replaced by a operator.itemgetter("name") and get a different result. ... except for the stack trace: >>> f = lambda x: x["A"] >>> f({"A": 3}) 3 >>> f({"B": 3}) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 1, in <lambda> KeyError: 'A' >>> import operator >>> f = operator.itemgetter("A") >>> f({"A": 3}) 3 >>> f({"B": 3}) Traceback (most recent call last): File "<stdin>", line 1, in <module> KeyError: 'A' So if 'x' implemented its own getitem and it inspected the stack (eg, how Pandas uses the 'level' parameter in 'eval' and 'query' methods to get locals() and globals()), then this change would cause different results.
  - winstonewert 4y ago
    Oh, I see. I think you are right.

deleted 4y ago

[deleted]

tonyg 4y ago

Holy shit, you're right. It's about 33% faster on Python 3.10 on my machine: import operator n1 = operator.itemgetter('name') n2 = lambda x: x['name'] x = {'name': 'abcdef'} import timeit print(timeit.timeit('n1(x)', globals=globals())) print(timeit.timeit('n2(x)', globals=globals())) I'm so surprised because I went and read (what I thought was) the source for operator.itemgetter, which boils down to a wrapper object around the plain version. It turns out that this is not the source code. As with so many other things in Python, there's a special case you have to know about: there's a separate C implementation of the operator module. :-/

ssl232 4y ago
> It turns out that this is not the source code. As with so many other things in Python, there's a special case you have to know about: there's a separate C implementation of the operator module. :-/ I actually kinda like that Python often maintains 100% compatible pure-Python implementations of various C modules. It's definitely niche, but I have sometimes found myself trying to work out what a module is doing (e.g. with the fancy new PEG parser) and I find it far easier to read Python than C.
kzrdude 4y ago
I'd expect it to be even better improvement inside sort, but maybe my hunch is wrong. The significance is greater there, at least.