Bug: Reentrant behavior does not work with distinct lock objects on the same thread

[nefrob]

Setup

• Python 3.11.3
• filelock 3.12.4
• MacOS

Actual:

➜ python
>>> from filelock import FileLock
>>> lock_1 = FileLock("test.lock")
>>> lock_2 = FileLock("test.lock")
>>> lock_1.acquire()
<filelock._api.AcquireReturnProxy object at 0x100baa550>
>>> lock_1._context
ThreadLocalFileContext(lock_file='test.lock', timeout=-1, mode=420, lock_file_fd=3, lock_counter=1)
>>> lock_2._context
ThreadLocalFileContext(lock_file='test.lock', timeout=-1, mode=420, lock_file_fd=None, lock_counter=0)
>>> lock_2.acquire()
... hangs

Also it does not appear that releasing the lock removes the lock file (not sure if this is expected):

>>> from filelock import FileLock
>>> lock = FileLock("test.lock")
>>> lock.acquire()
<filelock._api.AcquireReturnProxy object at 0x102ad80d0>
>>> lock.release()

➜ ls
test.lock

Expectation:

• lock_2 can be acquired since it is locking the same file on the same thread per reentrancy definition in docs:

The lock objects are recursive locks, which means that once acquired, they will not block on successive lock requests

(https://py-filelock.readthedocs.io/en/latest/#tutorial)

[gaborbernat]

PR welcome 👍

[nefrob]

Closing this re #283 being merged/released.

[hmaarrfk]

I'm not sure why this is the expected behavior.

The lock objects lock_1 and lock_2 are just two different objects.

I personally feel like #283 is a step backward.

[gaborbernat]

It's optional opt in behavior so shouldn't cause you issues 🤔