I'm missing something here...

[Skip Montanaro]

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
​