Sorry, I should have been explicit. prob_dates (the actual argument of the
call) is a set. As far as I know pylint does no type inference, so pylint
can't tell if the LHS and RHS of the |= operator are appropriate, nor can
it tell if it has an update() method.
Before writing, I had more-or-less concluded I had hit a bug, but in my
experience when I hit something I think is a bug, it's not. It's me.
Terry's reply convinced me that I had hit something.
Something else just occurred to me. I should have tried disassembling the
two versions of the function. Here's the output near prob_dates.update()
call:
14
62 LOAD_FAST 3 (prob_dates)
65 LOAD_ATTR 6 (update)
68 LOAD_GLOBAL 7 (compare_prices)
71 LOAD_CONST 3 ('E:%s')
74 LOAD_FAST 5 (sym)
77 BINARY_MODULO
78 LOAD_FAST 0 (cx1)
81 LOAD_FAST 1 (cx2)
84 LOAD_FAST 2 (cx3)
87 CALL_FUNCTION 4
90 CALL_FUNCTION 1
Here's how the |= version disassembles in that region:
20
62 LOAD_FAST 3 (prob_dates)
65 LOAD_GLOBAL 6 (compare_prices)
68 LOAD_CONST 3 ('E:%s')
71 LOAD_FAST 5 (sym)
74 BINARY_MODULO
75 LOAD_FAST 0 (cx1)
78 LOAD_FAST 1 (cx2)
81 LOAD_FAST 2 (cx3)
84 CALL_FUNCTION 4
87 INPLACE_OR
88 STORE_FAST 3 (prob_dates)
I think what's throwing pylint is that last
STORE_FAST. That tells pylint the argument is ignored.
I'll at least bring up the issue on the code-quality list.
Thanks,
Skip
--
https://mail.python.org/mailman/listinfo/python-list
