On Thu, 18 Jan 2018 16:37:18 -0500, Jason Swails wrote:
> The root cause of the issue comes down to the following check returning
> true:
>
> isinstance([], collections.Mapping)
I re-iterate Chris' suggestion that you check that the instance is an
actual list, not a subclass.
Can you grep the offending files for something like
class .*\(.*list.*\):
to see if anything subclasses list? If so, does it look like the subclass
is intended to offer a mapping interface?
> Obviously you can get this behavior if you register `list` as a subclass
> of the Mapping ABC, but I'm not doing that. Because the issue is so
> rare (but still common enough that I need to address it), it's hard to
> reproduce in a bench test.
Ah lovely, a heisenbug.
> What I am going to try is to essentially monkey-patch
> collections.Mapping.register with a method that dumps a stack trace
> whenever it's called at the time of initial import so I can get an idea
> of where this method could *possibly* be getting called with a list as
> its argument.
Seems like a reasonable step to me.
Also you could try identifying the offending library by interleaving
assertions between the imports:
import collections
assert not isinstance([], collections.Mapping)
import amqp
assert not isinstance([], collections.Mapping)
import billiard
assert not isinstance([], collections.Mapping)
import celery
etc. When (if) the assertion fails, you know which library is to blame.
Not exactly the nicest code, but it is only there until you locate (and
fix) the problem.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
