>>> import threading
    >>> l = threading.Lock()
    >>> l.__reduce_ex__(3)
    (<function __newobj__ at 0x00000000026CD8C8>,
     (<class '_thread.lock'>,),
     None,
     None,
     None)

Isn't it a bug that `__reduce_ex__` works on the non-pickleable lock object?

I don't really know. It simply looks like the default implementation of __reduce_ex__. Is it important?

I use that to test whether an object is pickleable or not. It used to work in Python 2.

> I use that to test whether an object is pickleable or not. It used to
> work in Python 2.

Well, the obvious way to do it would be to call pickle.dumps() on
the object, IMO :-)

Wrong, because the object itself could be pickleable but refer to a different object which is non-pickleable. I want to know whether the object itself, without any object it refers to, is pickleable.

Also, pickling an object could be very resource-intensive, depending on its size.

> Wrong, because the object itself could be pickleable but refer to a
> different object which is non-pickleable. I want to know whether the
> object itself, without any object it refers to, is pickleable.

I think you're being too picky. Unless you're manually added stuff
to your Lock's attributes, there isn't a practical difference between
the two situations.

> Also, pickling an object could be very resource-intensive, depending
> on its size.

Well, this is a Lock here, not an ISO file.

This does not look like a bug to me.
I think this should be closed.