>>> 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.