On Mon, Jan 11, 2016 at 6:04 PM, Skip Montanaro
<skip.montan...@gmail.com> wrote:
> 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 may be wrong, but I believe pylint just looks at the AST, not the opcodes.
--
https://mail.python.org/mailman/listinfo/python-list
