They certainly should _not_ be swapped, as explained clearly in the message following the one you referenced.  For the first half:

        if self._lock.acquire(0):

succeeds if and only if the lock is not held by _any_ thread at the time.  In that case, the lock is _acquired_ as a side-effect of performing the test, and the code goes on to restore the lock again to its initially unacquired state, and (correctly) return False:

            self._lock.release()
            return False

The second half of the code is certainly wrong:

        else:
            return True

The docs state:

        # Return True if lock is owned by current_thread.

but the code actually returns True if the lock is currently owned by _any_ thread.  All that is also explained in the thread you pointed at.

However, I don't see any possibility of fixing that.  There is simply no way to know, for an arbitrary "lock-like" object, which thread owns it.

Indeed, on Windows it's not even possible for a threading.Lock.  For example (here under Python3, but I'm sure it's the same under Python2):

>>> import threading as th
>>> lock = th.Lock()
>>> c = th.Condition(lock)
>>> def hmm():
...   print("is_owned:", c._is_owned())
...
>>> t = th.Thread(target=hmm)
>>> t.start()
is_owned: False
>>> lock.acquire()
True
>>> t = th.Thread(target=hmm)
>>> t.start()
is_owned: True

Note that the last line showed True despite that the lock is _not_ owned by the thread doing the print - it's owned by the main program thread.  That's because threading.Lock._is_owned doesn't exist under Windows, so it's falling into the second case of the Condition._is_owned() implementation at issue here.

Also note that if the True and False cases were swapped, _none_ of the output would make any sense at all ;-)