Support free-threaded Python 3.13 #925
Conversation
ngoldbaum
force-pushed
the
support-free-threading
branch
from
dcb6071 to
1d8f655
Compare
|
It looks like the lack of Python3.7 support in pytest-run-parallel is a little annoying to deal with in tox (or at least I don't see how to deal with it straightforwardly given that we need to make a code modification to the tests). Let me see how hard it is to support Python 3.7 in pytest-run-parallel. |
|
We also may be able to drop 3.7. we'd need to start by looking at the usage
data
…On Mon, Nov 25, 2024, 3:02 PM Nathan Goldbaum ***@***.***> wrote:
It looks like the lack of Python3.7 support in pytest-run-parallel is a
little annoying to deal with in tox (or at least I don't see how to deal
with it straightforwardly given that we need to make a code modification).
Let me see how hard it is to support Python 3.7 in pytest-run-parallel.
—
Reply to this email directly, view it on GitHub
<#925 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAGBGQGDZM5ZSHZF6OTHD2CN65BAVCNFSM6AAAAABSOYEP32VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJYHEZDCNBVGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
I think we probably do want some explicit threading testing separate from the use of threading in the test harness itself. A quick lazy glance at the stats suggests we're ~5-7% Python 3.7 downloads per day. On pyca/cryptography that'd be too high, but this project sees less change so I think I'd be okay with dropping it. |
Can you share a little more what you had in mind here? Maybe several threads hashing and checking passwords based on shared bytes or hashes? Is there any state stored anywhere? It looks like everything is a pure function. |
Great, I'll look at dropping Python 3.7 in a separate PR. |
Yeah there's no state, but your proposed idea is what I'd do. Just mimicking what a multi-threaded workload would look like with hash gen, verification, and kdf operations. |
ngoldbaum
force-pushed
the
support-free-threading
branch
from
fed9d38 to
ba2bcd4
Compare
| @@ -219,7 +224,7 @@ def test_gensalt_bad_prefix(): | |||
| bcrypt.gensalt(prefix=b"bad") | |||
|
|
|||
|
|
|||
| def test_gensalt_2a_prefix(monkeypatch): | |||
There was a problem hiding this comment.
unrelated to this PR, but I noticed these fixtures weren't being used anymore
|
I added a test that uses threading, let me know if you have any suggestions. It also looks like PyO3 0.23.2 might have broken setuptools-rust on Windows? |
|
I think PyO3/pyo3#4733 might fix it, want to try setting that git branch here and see if resolves? |
ngoldbaum
force-pushed
the
support-free-threading
branch
from
994a54e to
9187561
Compare
|
@reaperhulk it looks like all the upstream issues have been sorted out and this is ready now. |
| self.id_ = id_ | ||
| self.salt = bcrypt.gensalt(4) | ||
| self.hash_ = bcrypt.hashpw(pw, self.salt) | ||
| self.key = bcrypt.kdf(pw, self.salt, 32, 50) |
There was a problem hiding this comment.
I chose these parameters to make this run in a reasonable time. Still, it's a very slow test compared with the rest of the test suite.
Towards fixing #913.
Adds pytest-run-parallel as a test dependency. This does a good job of detecting thread-unsafe use of global state but doesn't catch thread safety issues due to sharing mutable state stored in objects. I marked one test as thread-unsafe because it uses the
warningsmodule, which isn't thread-safe.Declares that the rust PyO3 module exprted in
_bcryptdoesn't use the GIL. It looks like the rust code exports python functions and doesn't define any objects with state. Am I missing something?Sets up free-threaded CI using quansight-labs/setup-python.
It looks like the existing tests don't use
threadingat all. Should I add some multithreaded tests? Or ispytest-run-parallelexecuting the existing tests in parallel sufficient?After this I'll look at updating the wheel-building and uploading 313t wheels.