[
{
"path": ".claude/CLAUDE.md",
"content": "# Hypothesis Development Guide\n\n## Essential Reading\n\n**Always read `CONTRIBUTING.rst` before starting work**, especially before writing tests or creating a PR.\n\n## Testing\n\n### Running Tests\n\nRun tests using the build system:\n- **Quick test run**: `./build.sh check-coverage` (curated subset with coverage verification)\n- **Python version-specific**: `./build.sh check-py311` (replace with target version)\n- **Fine-grained control**: `./build.sh tox py311-custom 3.11.3 -- [pytest args]`\n- **Direct pytest** (after setup): `pytest hypothesis-python/tests/cover/`\n\n### Writing Tests\n\n**Never use `.example()` method in tests.** Instead:\n- Use `@given` decorator directly for property-based tests\n- Use helper functions from `tests.common.debug`:\n - `minimal()` - find minimal failing example\n - `find_any()` - find any example matching condition\n - `assert_all_examples()` - verify all examples match predicate\n - `assert_simple_property()` - verify simple properties with few examples\n - `check_can_generate_examples()` - verify strategy can generate without error\n\n## Changelog & Pull Requests\n\nWhen creating a PR that changes `hypothesis-python/src/`:\n1. Create `hypothesis-python/RELEASE.rst` with `RELEASE_TYPE: patch` (bugfixes) or `minor` (features)\n2. See `RELEASE-sample.rst` for examples\n3. **Imitate the style in `changelog.rst`** for consistency\n4. Follow all changelog instructions in `CONTRIBUTING.rst`\n\n**Note:** Test-only changes (no modifications to `src/`) do not require a RELEASE.rst file.\n\n## Before Committing\n\n1. Do a final edit pass on all code to ensure it is:\n - **Concise** - remove unnecessary verbosity\n - **Idiomatic** - follows Python and Hypothesis conventions\n - **Minimally commented** - code should be self-documenting; only add comments where truly needed\n2. **Run `./build.sh format; ./build.sh lint`** immediately before committing to auto-format and lint code\n3. **Do not reference issues or PRs in commit messages** (e.g., avoid `Fixes #1234` or `See #5678`) - this clutters the issue timeline with unnecessary links\n"
},
{
"path": ".claude/commands/hypothesis.md",
"content": "---\ndescription: Write property-based tests with Hypothesis\n---\n\nYou are an expert developer of property-based tests, specifically using Hypothesis. Your goal is to identify and implement a small number of the most valuable Hypothesis tests that would benefit an existing codebase right now. You focus on clarity and maintainability, as your code will be reviewed by a developer. Your goal is to write precise tests, not comprehensive test suites.\n\nCreate and follow this todo list using the `Todo` tool:\n\n1. [ ] Explore the provided code and identify valuable properties.\n2. [ ] For each property, explore how its related code is used.\n3. [ ] Write Hypothesis tests based on those properties.\n4. [ ] Run the new Hypothesis tests, and reflect on the result.\n\n## 1. Explore the code provided and identify valuable properties\n\nFirst, explore the provided code, and identify valuable properties to test. A \"valuable property\" is an invariant or property about the code that is valuable to the codebase right now and that a knowledgeable developer for this codebase would have written a Hypothesis test for. The following are indicative of a valuable property:\n\n- Would catch important bugs: Testing this property would reveal bugs that could cause serious issues.\n- Documents important behavior: The property captures essential assumptions or guarantees that are important to future or current developers.\n- Benefits significantly from Hypothesis: The property is concisely and powerfully expressed as a Hypothesis test, rather than a series of unit tests.\n\nKeep the following in mind:\n\n- Only identify properties that you strongly believe to be true and that are supported by evidence in the codebase, for example in docstrings, comments, code use patterns, type hints, etc. Do not include properties you are at all unsure about.\n- Each property should provide a substantial improvement in testing power or clarity when expressed as a Hypothesis test, rather than a unit test. Properties which could have been equally well tested with a unit test are not particularly valuable.\n- You may come across many possible properties. Your goal is to identify only a small number of the most valuable of those properties that would benefit the codebase right now.\n\nIf the provided code is large, focus on exploring in this order:\n\n1. Public API functions/classes\n2. Well-documented implementations of core functionality\n3. Other implementations of core functionality\n4. Internal/private helpers or utilities\n\nHere are some examples of typical properties:\n\n- Round-trip property: `decode(encode(x)) = x`, `parse(format(x)) = x`.\n- Inverse relationship: `add/remove`, `push/pop`, `create/destroy`.\n- Multiple equivalent implementations: Optimized vs reference implementation, complicated vs simple implementation.\n- Mathematical property: Idempotence `f(f(x)) = f(x)`, commutativity `f(x, y) = f(y, x)`.\n- Invariants: `len(filter(x)) <= len(x)`, `set(sort(x)) == set(x)`.\n- Confluence: the order of function application doesn't matter (for example, in compiler optimization passes).\n- Metamorphic property: some relationship between `f(x)` and `g(x)` holds for all x. For example, `sin(π − x) = sin(x)`.\n- Single entry point. If a library has a narrow public API, a nice property-based test simply calls the library with valid inputs. Common in parsers.\n\nWhile the following should generally not be tested:\n\n- Obvious code wrappers\n- Implementation details\n\nThe user has provided the following guidance for where and how to add Hypothesis tests: $ARGUMENTS.\n\n- If the user has provided no direction, explore the entire codebase.\n- If the user has provided a specific module, explore that module.\n- If the user has provided a specific file, explore that file.\n- If the user has provided a specific function, explore that function.\n- If the user has given more complex guidance, follow that instead.\n\nIf you don't identify any valuable properties during exploration, that's fine; just tell the user as much, and then stop.\n\nAt the end of this step, you should tell the user the small list of the most valuable properties that you intend to test.\n\n## 2. For each valuable property, explore how its related code is used\n\nBefore writing Hypothesis tests, explore how the codebase uses the related code of each valuable property. For example, if a property involves a function `some_function`, explore how the codebase calls `some_function`: what kinds of inputs are passed to it? in what context? etc. This helps correct any misunderstanding about the property before writing a test for it.\n\n## 3. Write Hypothesis tests based on those properties.\n\nFor each property, write a new Hypothesis test for it, and add it to the codebase's test suite, following its existing testing conventions.\n\nWhen writing Hypothesis tests, follow these guidelines:\n\n- Each Hypothesis test should be both sound (tests only inputs the code can actually be called with) and complete (tests all inputs the code can actually be called with). Sometimes this is difficult. In those cases, prefer sound and mostly-complete tests; stopping at 90% completeness is better than over-complicating a test.\n- Only place constraints on Hypothesis strategies if required by the code. For example, prefer `st.lists(...)` (with no size bound) to `st.lists(..., max_size=100)`, unless the property explicitly happens to only be valid for lists with no more than 100 elements.\n\n## 4. Run the new Hypothesis tests, and reflect on the result.\n\nRun the new Hypothesis tests that you just added. If any fail, reflect on why. Is the test failing because of a genuine bug, or because it's not testing the right thing? Often, when a new Hypothesis test fails, it's because the test generates inputs that the codebase assumes will never occur. If necessary, re-explore related parts of the codebase to check your understanding. You should only report that the codebase has a bug to the user if you are truly confident, and can justify why.\n\n# Hypothesis Reference\n\nDocumentation reference (fetch with the `WebFetch` tool if required):\n\n- **Strategies API reference**: https://hypothesis.readthedocs.io/en/latest/reference/strategies.html\n- **Other API reference**: https://hypothesis.readthedocs.io/en/latest/reference/api.html\n - Documents `@settings`, `@given`, etc.\n\nThese Hypothesis strategies are under-appreciated for how effective they are. Use them if they are a perfect or near-perfect fit for a property:\n\n- `st.from_regex`\n- `st.from_lark` - for context-free grammars\n- `st.functions` - generates arbitrary callable functions\n"
},
{
"path": ".gitattributes",
"content": "* text eol=lf\n\n# Denote all files that are truly binary and should not be modified.\n*.png binary\n*.jpg binary\n*.gif binary\n"
},
{
"path": ".github/CODEOWNERS",
"content": "# Engine changes need to be approved by Zac-HD, as per\n# https://github.com/HypothesisWorks/hypothesis/blob/master/guides/review.rst#engine-changes\n/hypothesis-python/src/hypothesis/internal/conjecture/ @Zac-HD @Liam-DeVoe\n\n# Changes to the paper also need to be approved by DRMacIver or Zac, as authors\n/paper.md @DRMacIver @Zac-HD\n/paper.bib @DRMacIver @Zac-HD\n"
},
{
"path": ".github/CODE_OF_CONDUCT.rst",
"content": "---------------\nCode of conduct\n---------------\n\nHypothesis's community is an inclusive space, and everyone in it is expected to abide by a code of conduct.\nThis applies in issues, pull requests, etc. as well as in the various Hypothesis community spaces.\n\nAt the high level the code of conduct goes like this:\n\n1. Be kind\n2. Be respectful\n3. Be helpful\n\nWhile it is impossible to enumerate everything that is unkind, disrespectful or unhelpful, here are some specific things that are definitely against the code of conduct:\n\n1. -isms and -phobias (e.g. racism, sexism, transphobia and homophobia) are unkind, disrespectful *and* unhelpful. Just don't.\n2. All software is broken. This is not a moral failing on the part of the authors. Don't give people a hard time for bad code.\n3. It's OK not to know things. Everybody was a beginner once, nobody should be made to feel bad for it.\n4. It's OK not to *want* to know something. If you think someone's question is fundamentally flawed, you should still ask permission before explaining what they should actually be asking.\n5. Note that \"I was just joking\" is not a valid defence.\n6. Don't suggest violence as a response to things, e.g. \"People who do/think X should be Y-ed\".\n Even if you think it is obvious hyperbole and that it's very clear that no actual threat is meant,\n it still contributes to a culture that makes people feel unsafe.\n\n\n~~~~~~~~~~~~~~~~~~~~~~~~\nResolution of Violations\n~~~~~~~~~~~~~~~~~~~~~~~~\n\nDavid R. MacIver (the project lead) acts as the main point of contact and enforcer for code of conduct violations.\nYou can email him at david@drmaciver.com, or for violations on GitHub that you want to draw his attention to you can also mention him as @DRMacIver.\n\nOther people (especially Hypothesis team members) should feel free to call people on code of conduct violations when they see them,\nand it is appreciated but not required (especially if doing so would make you feel uncomfortable or unsafe).\n\nWe don't currently have a formal policy for resolutions and it's mostly based on subjective judgement calls,\nbut the high level intent is as follows:\n\n* minor one-off infractions will just be met with a request not to repeat the behaviour and, where it would be useful,\n for an apology.\n* Major infractions and repeat offenders will be banned from the community.\n\nIf you disagree with David's judgement on any particular event, please feel free to tell him so.\n\nAlso, people who have a track record of bad behaviour outside of the Hypothesis community may be banned even\nif they obey all these rules if their presence is making people uncomfortable.\n"
},
{
"path": ".github/actions/install-base/action.yml",
"content": "name: \"Install\"\ndescription: \"Install python, then cache\"\ninputs:\n python-version:\n description: \"Python version\"\n required: true\n python-architecture:\n description: \"Python architecture, if not default for platform\"\n task:\n description: \"Task name\"\n required: true\nruns:\n using: \"composite\"\n steps:\n - name: Set up Python ${{ inputs.python-version }} ${{ inputs.python-architecture }}\n uses: actions/setup-python@v4\n with:\n python-version: ${{ inputs.python-version }}\n architecture: ${{ inputs.python-architecture }}\n - name: Install dotnet6 for Pyjion\n if: ${{ endsWith(inputs.task, '-pyjion') }}\n shell: bash\n run: |\n wget https://packages.microsoft.com/config/ubuntu/21.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb\n sudo dpkg -i packages-microsoft-prod.deb\n rm packages-microsoft-prod.deb\n sudo apt-get update\n sudo apt-get install -y apt-transport-https && \\\n sudo apt-get update && \\\n sudo apt-get install -y dotnet-sdk-6.0\n - name: Restore cache\n uses: actions/cache@v3\n with:\n path: |\n .tox/\n vendor/bundle\n ~/.cache\n ~/.local\n ~/appdata/local/pip/cache\n ~/Library/Caches/pip\n ~/wheelhouse\n key: deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}-${{ inputs.python-version }}-${{ inputs.python-architecture }}-${{ inputs.task }}\n restore-keys: |\n deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}-${{ inputs.python-version }}-${{ inputs.python-architecture }}\n deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}\n deps-${{ runner.os }}\n"
},
{
"path": ".github/workflows/fuzz.yml",
"content": "name: Fuzzing\n\nenv:\n # Tell pytest and other tools to produce coloured terminal output.\n # Make sure this is also in the \"passenv\" section of the tox config.\n PY_COLORS: 1\n\non:\n # Run every six hours, for six hours each time\n schedule:\n - cron: '0 */6 * * *'\n # Allow manual launching too so we can test any branch we like\n workflow_dispatch:\n # # Enable this and reduce the timeout below to check a PR is working\n # pull_request:\n # branches: [ master ]\n\njobs:\n fuzz:\n if: github.repository == 'HypothesisWorks/hypothesis' || github.event_name == 'workflow_dispatch'\n # Keep all of this stuff synced with the setup in main.yml for CI\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0\n - name: Set up Python 3.14\n uses: actions/setup-python@v4\n with:\n python-version: \"3.14.2\"\n - name: Restore cache\n uses: actions/cache@v3\n with:\n path: |\n ~/.cache\n ~/wheelhouse\n ~/.local\n vendor/bundle\n .tox/\n key: deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}-${{ matrix.task }}\n restore-keys: |\n deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}\n deps-${{ runner.os }}\n\n # OK, on to the fuzzing-specific part.\n # We're going to stick everything into a single run for now instead of\n # sharding it, because we'd have to manually specify all the databases\n # we want to multiplex across and that would be annoying to manage.\n # TODO: revisit this later; a redis-like service would be so much nicer.\n - name: Download example database\n uses: dawidd6/action-download-artifact@v9\n with:\n name: hypothesis-example-db\n path: .hypothesis/examples\n if_no_artifact_found: warn\n workflow_conclusion: completed\n\n - name: Install dependencies\n run: |\n pip install --upgrade setuptools pip wheel\n pip install -r requirements/fuzzing.txt\n pip install hypothesis-python/[all]\n\n - name: Run hypofuzz session\n continue-on-error: true\n # The timeout ensures that we finish all steps within the six-hour\n # maximum runtime for Github Actions.\n # Then run the fuzzer on everything, as for our Windows CI; avoiding\n # the --no-dashboard option because that also disables .patch writing.\n run: |\n timeout --preserve-status 5.5h \\\n hypothesis fuzz -- hypothesis-python/tests/ \\\n --ignore=hypothesis-python/tests/quality/ \\\n --ignore=hypothesis-python/tests/ghostwriter/\n\n - name: Upload patch files with covering and failing `@example()`s\n uses: actions/upload-artifact@v4\n if: always()\n with:\n name: explicit-example-patches\n path: .hypothesis/patches/latest_hypofuzz_*.patch\n\n # Upload the database so it'll be persisted between runs.\n # Note that we can also pull it down to use locally via\n # https://hypothesis.readthedocs.io/en/latest/database.html#hypothesis.database.GitHubArtifactDatabase\n - name: Upload example database\n uses: actions/upload-artifact@v4\n if: always()\n with:\n name: hypothesis-example-db\n path: .hypothesis/examples\n"
},
{
"path": ".github/workflows/main.yml",
"content": "name: Hypothesis CI\n\nenv:\n # Tell pytest and other tools to produce coloured terminal output.\n # Make sure this is also in the \"passenv\" section of the tox config.\n PY_COLORS: 1\n\non:\n push:\n branches: [ master ]\n pull_request:\n branches: [ master ]\n workflow_dispatch:\n\n# Cancel in-progress PR builds if another commit is pushed.\n# On non-PR builds, fall back to the globally-unique run_id and don't cancel.\nconcurrency:\n group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}\n cancel-in-progress: true\n\njobs:\n basic:\n runs-on: ubuntu-latest\n strategy:\n matrix:\n task:\n - tox-cover\n - tox-nocover\n - tox-rest\n - check-whole-repo-tests\n - check-types-hypothesis\n - lint\n - check-format\n fail-fast: false\n env:\n PYTHON_VERSION: \"3.14\"\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0\n - name: \"Install base for Python ${{ env.PYTHON_VERSION }}\"\n uses: ./.github/actions/install-base\n with:\n python-version: ${{ env.PYTHON_VERSION }}\n task: ${{ matrix.task }}\n - name: Install tox\n if: ${{ startsWith(matrix.task, 'tox-') }}\n run: |\n pip install --upgrade setuptools pip wheel\n pip install tox\n - name: Run tests\n run: |\n export TASK=${{ matrix.task }}\n if [[ $TASK == tox-* ]]; then\n TOX_TASK=\"${TASK#tox-}\"\n cd hypothesis-python\n tox -e $TOX_TASK\n else\n ./build.sh\n fi\n\n req:\n needs: [basic]\n runs-on: ubuntu-latest\n strategy:\n matrix:\n task:\n - check-documentation\n - check-types-api\n - check-coverage\n - check-conjecture-coverage\n - check-py310-cover\n - check-py310-nocover\n - check-py310-niche\n - check-pypy310-cover\n # - check-py310-pyjion # see notes in tox.ini\n - check-py311-cover\n - check-py311-nocover\n - check-py311-niche\n - check-pypy311-cover\n - check-py312-cover\n - check-py312-nocover\n - check-py312-niche\n - check-py313-cover\n - check-py313-nocover\n - check-py313-niche\n - check-py313t-cover\n - check-py313t-nocover\n - check-py313t-niche\n - check-quality\n - check-pytest9\n - check-pytest84\n - check-pytest74\n - check-py311-pytest62\n - check-django60\n - check-django42\n - check-py313-pandas22\n - check-py312-pandas21\n - check-py311-pandas20\n - check-py311-pandas15\n - check-py310-pandas14\n - check-py310-pandas13\n ## FIXME: actions update means Python builds without eg _bz2, which was required\n # - check-py310-pandas12\n # - check-py310-pandas11\n fail-fast: false\n env:\n PYTHON_VERSION: \"3.14\"\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0\n - name: \"Install base for Python ${{ env.PYTHON_VERSION }}\"\n uses: ./.github/actions/install-base\n with:\n python-version: ${{ env.PYTHON_VERSION }}\n task: ${{ matrix.task }}\n - name: Run tests\n run: |\n export TASK=${{ matrix.task }}\n if [[ $TASK == check-crosshair-custom-* ]]; then\n GROUP=\"${TASK#check-crosshair-custom-}\"\n ./build.sh check-crosshair-custom -- -n auto $(cd hypothesis-python && echo tests/$GROUP | xargs -n1 echo | grep -Ev \"_py312|_py314\" | xargs)\n else\n ./build.sh\n fi\n - name: Upload coverage data\n uses: actions/upload-artifact@v4\n # Invoke the magic `always` function to run on both success and failure.\n if: ${{ always() && endsWith(matrix.task, '-coverage') }}\n with:\n name: ${{ matrix.task }}-data\n include-hidden-files: true\n path: |\n hypothesis-python/.coverage*\n !hypothesis-python/.coveragerc\n hypothesis-python/branch-check*\n\n nonreq:\n needs: [basic]\n runs-on: ubuntu-latest\n strategy:\n matrix:\n task:\n - check-py314-cover\n - check-py314-nocover\n # Blocked by a 3.14rc1 bug. see\n # https://github.com/HypothesisWorks/hypothesis/pull/4490#issuecomment-3144989862.\n # Can revisit in 3.14rc2.\n # - check-py314-niche\n - check-py314t-cover\n - check-py314t-nocover\n - check-py314t-niche\n # - check-py315-cover\n # - check-py315-nocover\n # - check-py315-niche\n # - check-py315t-cover\n # - check-py315t-nocover\n # - check-py315t-niche\n - check-django52\n ## `-cover` is too slow under crosshair; use a custom split\n - check-crosshair-custom-cover/test_[a-d]*\n - check-crosshair-custom-cover/test_[e-i]*\n - check-crosshair-custom-cover/test_[j-r]*\n - check-crosshair-custom-cover/test_[s-z]*\n - check-crosshair-custom-pytest/test_*\n - check-crosshair-custom-nocover/test_[a-d]*\n - check-crosshair-custom-nocover/test_[e-i]*\n - check-crosshair-custom-nocover/test_[j-r]*\n - check-crosshair-custom-nocover/test_[s-z]*\n # - check-crosshair-niche\n - check-threading\n - check-py310-oldestnumpy\n - check-numpy-nightly\n fail-fast: false\n env:\n PYTHON_VERSION: \"3.14\"\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0\n - name: \"Install base for Python ${{ env.PYTHON_VERSION }}\"\n uses: ./.github/actions/install-base\n with:\n python-version: ${{ env.PYTHON_VERSION }}\n task: ${{ matrix.task }}\n - name: Run tests\n run: |\n export TASK=${{ matrix.task }}\n if [[ $TASK == check-crosshair-custom-* ]]; then\n GROUP=\"${TASK#check-crosshair-custom-}\"\n ./build.sh check-crosshair-custom -- -n auto $(cd hypothesis-python && echo tests/$GROUP | xargs -n1 echo | grep -Ev \"_py312|_py314\" | xargs)\n else\n ./build.sh\n fi\n\n cross:\n needs: [basic]\n strategy:\n matrix:\n os:\n - windows-latest\n - macos-latest\n python-version:\n - \"3.11\"\n - \"3.14\"\n python-architecture:\n - null\n - \"x86\"\n task:\n - cover\n - nocover\n - rest\n - alt-nocover\n - alt-rest\n exclude:\n - { os: macos-latest, python-architecture: \"x86\" }\n - { python-version: \"3.14\", python-architecture: \"x86\" }\n - { python-version: \"3.11\", task: nocover }\n - { python-version: \"3.11\", task: rest }\n - { python-version: \"3.14\", task: alt-nocover }\n - { python-version: \"3.14\", task: alt-rest }\n fail-fast: false\n runs-on: ${{ matrix.os }}\n env:\n # Override default from tox.ini\n PYTHONWARNDEFAULTENCODING: \"\"\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0\n - name: \"Install base for Python ${{ matrix.python-version }} ${{ matrix.python-architecture }}\"\n uses: ./.github/actions/install-base\n with:\n python-version: ${{ matrix.python-version }}\n python-architecture: ${{ matrix.python-architecture }}\n task: ${{ matrix.task }}\n - name: Install tox\n run: |\n pip install --upgrade setuptools pip wheel\n pip install tox\n - name: Run tests\n working-directory: ./hypothesis-python\n run: |\n tox -e ${{ matrix.task }}\n\n # See https://pyodide.org/en/stable/usage/building-and-testing-packages.html\n # and https://github.com/numpy/numpy/blob/9a650391651c8486d8cb8b27b0e75aed5d36033e/.github/workflows/emscripten.yml\n test-pyodide:\n needs: [basic]\n runs-on: ubuntu-latest\n env:\n NODE_VERSION: 22\n # Note that the versions below are updated by `update_pyodide_versions()` in our weekly cronjob.\n # The versions of pyodide-build and the Pyodide runtime may differ.\n PYODIDE_VERSION: 0.29.3\n PYODIDE_BUILD_VERSION: 0.33.0\n # pyodide 0.29.0 (latest at time of writing) doesn't yet support 3.14\n PYTHON_VERSION: 3.13.2\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0\n - name: \"Install base for Python ${{ env.PYTHON_VERSION }}\"\n uses: ./.github/actions/install-base\n with:\n python-version: ${{ env.PYTHON_VERSION }}\n task: pyodide\n - name: Set up Node\n uses: actions/setup-node@b39b52d1213e96004bfcb1c61a8a6fa8ab84f3e8 # v4.0.1\n with:\n node-version: ${{ env.NODE_VERSION }}\n - name: Install pyodide-build and Pyodide cross-build environment\n run: |\n pip install pyodide-build==${{ env.PYODIDE_BUILD_VERSION }}\n pyodide xbuildenv install ${{ env.PYODIDE_VERSION }}\n - name: Set up Pyodide venv and install dependencies\n run: |\n pip install --upgrade setuptools pip wheel build\n python -m build --wheel hypothesis-python --outdir dist/\n pip download --dest=dist/ hypothesis-python/ pytest tzdata # fetch all the wheels\n rm dist/packaging-*.whl # fails with `invalid metadata entry 'name'`\n pyodide venv .venv-pyodide\n source .venv-pyodide/bin/activate\n pip install dist/*.whl\n - name: Run tests\n run: |\n source .venv-pyodide/bin/activate\n # pyodide can't run multiple processes internally, so parallelize explicitly over\n # discovered test files instead (20 at a time)\n TEST_FILES=$(ls hypothesis-python/tests/cover/test*.py | grep -v \"_py314\")\n echo \"test files: $TEST_FILES\"\n parallel --max-procs 100% --max-args 20 --keep-order --line-buffer \\\n python -m pytest -p no:cacheprovider <<< $TEST_FILES\n\n check-required:\n if: always()\n needs: [basic, req, cross]\n runs-on: ubuntu-latest\n steps:\n - name: Check required jobs\n uses: re-actors/alls-green@release/v1\n with:\n jobs: ${{ toJSON(needs) }}\n\n deploy:\n if: \"github.event_name == 'push' && github.repository == 'HypothesisWorks/hypothesis'\"\n runs-on: ubuntu-latest\n needs: [check-required]\n strategy:\n matrix:\n task:\n - deploy\n fail-fast: false\n steps:\n - uses: actions/checkout@v3\n with:\n fetch-depth: 0\n token: ${{ secrets.GH_TOKEN }}\n - uses: ./.github/actions/install-base\n with:\n python-version: \"3.14\"\n - name: Deploy package\n env:\n GH_TOKEN: ${{ secrets.GH_TOKEN }}\n TWINE_PASSWORD: ${{ secrets.PYPI_TOKEN }}\n run: |\n TASK=${{ matrix.task }} ./build.sh\n"
},
{
"path": ".github/workflows/update-deps.yml",
"content": "name: Update pinned dependencies\n\non:\n schedule:\n - cron: 0 0 * * 0\n workflow_dispatch:\n\njobs:\n release:\n name: Update pinned dependencies\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v3\n - name: Set up Python 3.14\n uses: actions/setup-python@v4\n with:\n python-version: '3.14'\n - name: Update pinned dependencies\n run: ./build.sh upgrade-requirements\n - name: Open pull request\n uses: peter-evans/create-pull-request@v7\n with:\n token: ${{secrets.GH_TOKEN}}\n delete-branch: true\n title: Update pinned dependencies\n body: |\n Automatically update pinned dependencies\n commit-message: 'Update pinned dependencies'\n committer: 'CI on behalf of the Hypothesis team '\n author: 'CI on behalf of the Hypothesis team '\n"
},
{
"path": ".github/workflows/website.yml",
"content": "name: Build website & deploy to GitHub Pages\n\non:\n # Runs on pushes targeting the default branch\n push:\n branches: [\"master\"]\n\n # Allows you to run this workflow manually from the Actions tab\n workflow_dispatch:\n\n# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages\npermissions:\n contents: read\n pages: write\n id-token: write\n\n# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.\n# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.\nconcurrency:\n group: \"pages\"\n cancel-in-progress: false\n\njobs:\n # Single deploy job since we're just deploying\n deploy:\n environment:\n name: github-pages\n url: ${{ steps.deployment.outputs.page_url }}\n runs-on: ubuntu-latest\n steps:\n - name: Checkout\n uses: actions/checkout@v4\n - name: Build website\n run: ./build.sh website\n - name: Upload artifact\n uses: actions/upload-pages-artifact@v3\n with:\n path: 'website/output/'\n - name: Deploy to GitHub Pages\n id: deployment\n uses: actions/deploy-pages@v4\n"
},
{
"path": ".gitignore",
"content": "# mypyc\n\n*.so\n\n# misc (editors, file systems, etc)\n\n*.swo\n*.swp\n.idea\n.vagrant\n.DS_Store\n.hypothesis\n.vscode/\n.claude/settings.local.json\n\n# generic build components\n\n.runtimes\n/hypothesis-python/branch-check*\n/pythonpython3.*\n/pythonpypy3.*\n.pyodide-xbuildenv\n\n# python\n\n*.pyc\n*.pyo\nvenv*\n.cache\n.pytest_cache\n.mypy_cache\ndocs/_build\n*.egg-info\n_build\n.tox\n.coverage\n.coverage.*\n.pypirc\nhtmlcov\nbuild\ndist\n.doctrees/\n.v*/\n\n# encrypted files\nsecrets.tar\nsecrets\n\n\n_site/\n.sass-cache/\n.docker\n\n# =========================\n# Operating System Files\n# =========================\n\n# OSX\n# =========================\n\n.AppleDouble\n.LSOverride\n\n# Thumbnails\n._*\n\n# Files that might appear on external disk\n.Spotlight-V100\n.Trashes\n\n# Directories potentially created on remote AFP share\n.AppleDB\n.AppleDesktop\nNetwork Trash Folder\nTemporary Items\n.apdisk\n\n# Windows\n# =========================\n\n# Windows image file caches\nThumbs.db\nehthumbs.db\n\n# Folder config file\nDesktop.ini\n\n# Recycle Bin used on file shares\n$RECYCLE.BIN/\n\n# Windows Installer files\n*.cab\n*.msi\n*.msm\n*.msp\n\n# Windows shortcuts\n*.lnk\nsftp-config.json\n\n# Vim files\n\n*.sw*\n\n__pycache__\n\n.jekyll-metadata\n\nHypothesisWorks.github.io.iml\njekyll.log\n/website/output/\n/t.py\n"
},
{
"path": ".readthedocs.yml",
"content": "# Read the Docs configuration file\n# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details\n\n# Required\nversion: 2\n\n# Optionally build your docs in additional formats such as PDF and ePub\nformats:\n - htmlzip\n - epub\n # - pdf # busted by latex crash on unicode U+030A combining ring above, in text() docs\n\n# Optionally set the version of Python and requirements required to build your docs\nbuild:\n os: ubuntu-22.04\n tools:\n python: \"3.14\"\npython:\n install:\n - requirements: requirements/tools.txt\n - path: hypothesis-python/\n extra_requirements:\n - all\nsphinx:\n configuration: hypothesis-python/docs/conf.py\n"
},
{
"path": "AUTHORS.rst",
"content": "--------------------\nList of Contributors\n--------------------\n\nThe primary author for most of Hypothesis is David R. MacIver (me). However the following\npeople have also contributed work. As well as my thanks, they also have copyright over\ntheir individual contributions.\n\n.. NOTE - this list is in alphabetical order by first name (or handle).\n\n* `A. Jesse Jiryu Davis `_\n* `Aaron Meurer `_\n* `Adam Johnson `_\n* `Adam Matan _`\n* `Adam Sven Johnson `_\n* `Afrida Tabassum `_ (afrida@gmail.com)\n* `Afonso Silva `_ (ajcerejeira@gmail.com)\n* `Agriya Khetarpal `_\n* `Agustín Covarrubias `_ (gh@agucova.dev)\n* `Akash Suresh `_ (akashsuresh36@gmail.com)\n* `Alex Gaynor `_\n* `Alex Stapleton `_\n* `Alex Willmer `_ (alex@moreati.org.uk)\n* `Andrea Pierré `_\n* `Andrea Reina `_\n* `Andrew Sansom `_\n* `Anne Archibald `_\n* `Arjoonn Sharma `_\n* `Ben Anhalt `_\n* `Ben Peterson `_ (killthrush@hotmail.com)\n* `Benjamin Lee `_ (benjamindlee@me.com)\n* `Benjamin Palmer `_\n* `Bex Dunn `_ (bex.dunn@gmail.com)\n* `Bill Tucker `_ (imbilltucker@gmail.com)\n* `Brandon Chinn `_\n* `Bryant Eisenbach `_\n* `Buck Evan, copyright Google LLC `_\n* `Cameron McGill `_\n* `Carl Meyer `_\n* `Charles O'Farrell `_\n* `Charlie Tanksley `_\n* `Chase Garner `_ (chase@garner.red)\n* `Cheuk Ting Ho `_\n* `Chris Down `_\n* `Chris van Dronkelaar `_\n* `Chris Wesseling `_\n* `Christopher Martin `_ (ch.martin@gmail.com)\n* `Claudio Jolowicz `_\n* `Conrad Ho `_ (conrad.alwin.ho@gmail.com)\n* `Cory Benfield `_\n* `Cristi Cobzarenco `_ (cristi@reinfer.io)\n* `Damon Francisco `_ (damontfrancisco@yahoo.com)\n* `Daniel J. West `_\n* `Daniel Knell `_ (contact@danielknell.co.uk)\n* `David Bonner `_ (dbonner@gmail.com)\n* `David Chudzicki `_ (dchudz@gmail.com)\n* `David Mascharka `_\n* `Dawn E. Collett `_\n* `Derek Gustafson `_\n* `Dion Misic `_ (dion.misic@gmail.com)\n* `Dmitry Dygalo `_\n* `Ed Rogers `-\n* `Eduardo Enriquez `_ (eduardo.a.enriquez@gmail.com)\n* `El Awbery `_\n* `Emmanuel Leblond `_\n* `Evan Tey `_\n* `Felix Divo `_\n* `Felix Grünewald `_\n* `Felix Sheldon `_\n* `Florian Bruhin `_\n* `follower `_\n* `Francesc Elies `_\n* `Gabe Joseph `_\n* `Gary Donovan `_\n* `Genevieve Mendoza `_\n* `George Macon `_\n* `Glenn Lehman `_\n* `Graham Williamson `_\n* `Grant David Bachman `_ (grantbachman@gmail.com)\n* `Gregory Petrosyan `_\n* `Grzegorz Zieba `_ (g.zieba@erax.pl)\n* `Grigorios Giannakopoulos `_\n* `Hal Blackburn `_\n* `Hugo van Kemenade `_\n* `Humberto Rocha `_\n* `Ilya Lebedev `_ (melevir@gmail.com)\n* `Israel Fruchter `_\n* `Ivan Tham `_\n* `Iyassou Shimels `_\n* `Jack Massey `_\n* `Jakub Nabaglo `_ (j@nab.gl)\n* `James Lamb `_\n* `Jenny Rouleau `_\n* `Jens Heinrich `_\n* `Jens Tröger `_\n* `Jeremy Thurgood `_\n* `J.J. Green `_\n* `JP Viljoen `_ (froztbyte@froztbyte.net)\n* `Jochen Müller `_\n* `Joseph Weston `_\n* `Joey Tuong `_\n* `Jonathan Gayvallet `_ (jonathan.gayvallet@orange.com)\n* `Jonty Wareing `_ (jonty@jonty.co.uk)\n* `Joshua Boone `_ (joshuaboone4190@gmail.com)\n* `Joshua Munn `_ (public@elysee-munn.family)\n* `jmhsi `_\n* `Justus Magin `_\n* `jwg4 `_\n* `Kai Chen `_ (kaichen120@gmail.com)\n* `Karthikeyan Singaravelan `_ (tir.karthi@gmail.com)\n* `Katelyn Gigante `_\n* `Katrina Durance `_\n* `kbara `_\n* `Keeri Tramm `_\n* `Kristian Glass `_\n* `Krzysztof Przybyła `_\n* `Kyle Reeve `_ (krzw92@gmail.com)\n* `Lampros Mountrakis `_\n* `Lea Provenzano `_\n* `Lee Begg `_\n* `Liam DeVoe `_\n* `Libor Martínek `_\n* `Lisa Goeller `_\n* `Louis Taylor `_\n* `Luke Barone-Adesi `_\n* `Lundy Bernard `_\n* `Marco Ricci `_\n* `Marco Sirabella `_\n* `marekventur `_\n* `Marius Gedminas `_ (marius@gedmin.as)\n* `Markus Unterwaditzer `_ (markus@unterwaditzer.net)\n* `Mateusz Sokół `_\n* `Mathieu Paturel `_ (mathieu.paturel@gmail.com)\n* `Matt Bachmann `_ (bachmann.matt@gmail.com)\n* `Matthew Barber `_ (quitesimplymatt@gmail.com)\n* `Max Nordlund `_ (max.nordlund@gmail.com)\n* `Maxim Kulkin `_ (maxim.kulkin@gmail.com)\n* `Mel Seto `_\n* `Michel Alexandre Salim `_ (michel@michel-slm.name)\n* `mulkieran `_\n* `Munir Abdinur `_\n* `Nathan Goldbaum `_\n* `Nicholas Chammas `_\n* `Nick Anyos `_\n* `Nick Collins ` _\n* `Nick Muoh `_ (nickspirit3@gmail.com)\n* `Nicolas Erni `_\n* `Nikita Sobolev `_ (mail@sobolevn.me)\n* `Oleg Höfling `_ (oleg.hoefling@gmail.com)\n* `Paul Ganssle `_ (paul@ganssle.io)\n* `Paul Kehrer `_\n* `Paul Lorett Amazona `_\n* `Paul Stiverson `_\n* `Pax (R. Margret) W. `_\n* `Peadar Coyle `_ (peadarcoyle@gmail.com)\n* `Petr Viktorin `_\n* `Phillip Schanely `_ (pschanely@gmail.com)\n* `Pierre-Jean Campigotto `_\n* `Przemek Konopko `_\n* `Reagan Lee `_\n* `Richard Boulton `_ (richard@tartarus.org)\n* `Richard Scholtens `_ (richardscholtens2@gmail.com)\n* `Robert Howlett `_\n* `Robert Knight `_ (robertknight@gmail.com)\n* `Rodrigo Girão Serrão `_ (rodrigo@mathspp.com)\n* `Rónán Carrigan `_ (rcarriga@tcd.ie)\n* `Ruben Opdebeeck `_\n* `Ryan Soklaski `_ (rsoklaski@gmail.com)\n* `Ryan Turner `_ (ryan.turner@uber.com)\n* `Sam Bishop (TechDragon) `_ (sam@techdragon.io)\n* `Sam Clamons `_ (sclamons@gmail.com)\n* `Sam Hames `_\n* `Sam Watts `_\n* `Sangarshanan `_ (sangarshanan1998@gmail.com)\n* `Sanyam Khurana `_\n* `Saul Shanabrook `_ (s.shanabrook@gmail.com)\n* `Sebastiaan Zeeff `_ (sebastiaan.zeeff@ordina.nl)\n* `Sharyar Memon `_ (smemon.cal@gmail.com)\n* `Shaun Read `_\n* `Shlok Gandhi `_ (shlok.gandhi@gmail.com)\n* `Sogata Ray `_ (rayardinanda@gmail.com)\n* `Stuart Cook `_\n* `SuperStormer `_\n* `Sushobhit `_ (sushobhitsolanki@gmail.com)\n* `Tariq Khokhar `_ (tariq@khokhar.net)\n* `Tessa Bradbury `_\n* `Thea Koutsoukis `_\n* `Thomas Ball `_ (bomtall1@hotmail.com)\n* `Thomas Grainge `_\n* `Thomas Kluyver `_ (thomas@kluyver.me.uk)\n* `Tim Martin `_ (tim@asymptotic.co.uk)\n* `Tom McDermott `_ (sponster@gmail.com)\n* `Tom Milligan `_ (code@tommilligan.net)\n* `Tyler Gibbons `_ (tyler.gibbons@flexport.com)\n* `Tyler Nickerson `_\n* `Vidya Rani `_ (vidyarani.d.g@gmail.com)\n* `Vince Reuter `_ (vince.reuter@gmail.com)\n* `Vincent Michel `_ (vxgmichel@gmail.com)\n* `Viorel Pluta `_ (viopluta@gmail.com)\n* `Vytautas Strimaitis `_\n* `Will Hall `_ (wrsh07@gmail.com)\n* `Will Thompson `_ (will@willthompson.co.uk)\n* `Wilfred Hughes `_\n* `Yiyang Zhan `_\n* `Zac Hatfield-Dodds `_ (zac.hatfield.dodds@gmail.com)\n* `Zebulun Arendsee `_ (zbwrnz@gmail.com)\n"
},
{
"path": "CITATION.cff",
"content": "cff-version: 1.2.0\nmessage: |\n If you use Hypothesis as part of a published research project,\n please cite our paper in the Journal of Open Source Software:\n\n Text:\n\n MacIver et al., (2019). Hypothesis: A new approach to property-based testing.\n Journal of Open Source Software, 4(43), 1891, https://doi.org/10.21105/joss.01891\n\n BibTeX:\n\n @article{MacIver2019Hypothesis,\n journal = {Journal of Open Source Software},\n doi = {10.21105/joss.01891},\n issn = {2475-9066},\n number = {43},\n publisher = {The Open Journal},\n title = {Hypothesis: A new approach to property-based testing},\n url = {http://dx.doi.org/10.21105/joss.01891},\n volume = {4},\n author = {MacIver, David and Hatfield-Dodds, Zac and Contributors, Many},\n pages = {1891},\n date = {2019-11-21},\n year = {2019},\n month = {11},\n day = {21},\n }\n\n To reference a particular version of Hypothesis as a software artifact,\n you can use the version-specific DOIs we create for each release under\n https://doi.org/10.5281/zenodo.1412597\n\n\npreferred-citation:\n title: 'Hypothesis: A new approach to property-based testing'\n date-released: 2019-11-21\n type: article\n doi: 10.21105/joss.01891\n authors:\n - family-names: MacIver\n given-names: David R.\n orcid: https://orcid.org/0000-0002-8635-3223\n affiliation: Imperial College London\n - family-names: Hatfield-Dodds\n given-names: Zac\n orcid: https://orcid.org/0000-0002-8646-8362\n affiliation: Australian National University\n - name: \"many other contributors\"\n\n# Citation metadata for the software itself, as required by the CFF spec\ndoi: 10.5281/zenodo.1412597 # Version-independent DOI for the software archive\ntitle: 'Hypothesis: Property-Based Testing for Python'\nrepository-code: https://github.com/HypothesisWorks/hypothesis\nlicense: MPL-2.0\nauthors:\n - family-names: MacIver\n given-names: David R.\n orcid: https://orcid.org/0000-0002-8635-3223\n affiliation: Imperial College London\n - family-names: Hatfield-Dodds\n given-names: Zac\n orcid: https://orcid.org/0000-0002-8646-8362\n affiliation: Australian National University\n - name: \"many other contributors\"\n"
},
{
"path": "CONTRIBUTING.rst",
"content": "=============\nContributing\n=============\n\nFirst off: It's great that you want to contribute to Hypothesis! Thanks!\n\n---------------------------------------\nJust tell me how to make a pull request\n---------------------------------------\n\n1. Make your change and ensure it has adequate tests\n2. Create ``hypothesis-python/RELEASE.rst`` with ``RELEASE_TYPE: patch``\n for small bugfixes, or ``minor`` for new features. See ``RELEASE-sample.rst``\n as an example.\n3. Add yourself to the list in ``AUTHORS.rst`` and open a PR!\n\nFor more detail, read on; for even more, continue to the ``guides/`` directory!\n\n------------------\nWays to Contribute\n------------------\n\nHypothesis is a mature yet active project. This means that there are many\nways in which you can contribute.\n\nFor example, it's super useful and highly appreciated if you do any of:\n\n* Submit bug reports\n* Submit feature requests\n* Write about Hypothesis\n* Give a talk about Hypothesis\n* Build libraries and tools on top of Hypothesis outside the main repo\n* Submit PRs\n\nIf you build a Hypothesis strategy that you would like to be more widely known\nplease add it to the list of external strategies by preparing a PR against\nthe docs/strategies.rst file.\n\nIf you find an error in the documentation, please feel free to submit a PR that\nfixes the error. Spot a tyop? Fix it up and send us a PR!\nYou can read more about how we document Hypothesis in ``guides/documentation.rst``\n\nThe process for submitting source code PRs is generally more involved\n(don't worry, we'll help you through it), so do read the rest of this document.\nIf you're planning a larger change, the contributor guides (in the ``guides/``\ndirectory) will make sure you're on the right track.\n\n----------------------------------\nInstalling from source and testing\n----------------------------------\n\nIf you want to install directly from the source code (e.g. because you want to\nmake changes and install the changed version) you can do this with:\n\n.. code:: bash\n\n pip install -r requirements/test.in\n pip install -r requirements/tools.in\n pip install -e hypothesis-python/\n\n # You don't need to run the tests, but here's the command:\n pytest hypothesis-python/tests/cover/\n\nYou may wish to do all of this in a\n`virtualenv `_. For example:\n\n.. code:: bash\n\n python3 -m venv .venv\n source .venv/bin/activate\n pip install hypothesis\n\nWill create an isolated environment where you can install and try out\nHypothesis without affecting your system packages.\n\n-----------------------\nCopyright and Licensing\n-----------------------\n\nIt's important to make sure that you own the rights to the work you are submitting.\nIf it is done on work time, or you have a particularly onerous contract, make sure\nyou've checked with your employer.\n\nAll work in Hypothesis is licensed under the terms of the\n`Mozilla Public License, version 2.0 `_. By\nsubmitting a contribution you are agreeing to licence your work under those\nterms.\n\nFinally, if it is not there already, add your name (and a link to your GitHub\nand email address if you want) to the list of contributors found in\nAUTHORS.rst, in alphabetical order. It doesn't have to be your\n\"real\" name (whatever that means), any sort of public identifier\nis fine. In particular a GitHub account is sufficient.\n\n-----------------------\nThe actual contribution\n-----------------------\n\nOK, so you want to make a contribution and have sorted out the legalese. What now?\n\nFirst off: If you're planning on implementing a new feature, talk to us\nfirst! Come `join us on the mailing list `_,\nor open an issue. If it's really small feel free to open a work in progress pull request sketching\nout the idea, but it's best to get feedback from the Hypothesis maintainers\nbefore sinking a bunch of work into it.\nIf you're working on an existing issue, leave a comment so we can try to avoid\nduplicating your work before you open a pull request.\n\nIn general work-in-progress pull requests are totally welcome if you want early feedback\nor help with some of the tricky details. Don't be afraid to ask for help.\n\nIn order to get merged, a pull request will have to have a green build (naturally) and\nto be approved by a Hypothesis maintainer (and, depending on what it is, possibly specifically\nby DRMacIver). Most pull requests will also need to `write a changelog entry in\nhypothesis-python/RELEASE.rst `_.\n\nThe review process is the same one that all changes to Hypothesis go through, regardless of\nwhether you're an established maintainer or entirely new to the project. It's very much\nintended to be a collaborative one: It's not us telling you what we think is wrong with\nyour code, it's us working with you to produce something better together.\n\nWe have `a lengthy check list `_ of things we look for in a review. Feel\nfree to have a read of it in advance and go through it yourself if you'd like to. It's not\nrequired, but it might speed up the process.\n\nOnce your pull request has a green build and has passed review, it will be merged to\nmaster fairly promptly. This will immediately trigger a release! Don't be scared. If that\nbreaks things, that's our fault not yours - the whole point of this process is to ensure\nthat problems get caught before we merge rather than after.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nPull request or external package?\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nNew strategies can be added to Hypothesis, or published as an external package\non PyPI - either is fine for most strategies. If in doubt, ask!\n\nIt's generally much easier to get things working outside, because there's\nmore freedom to experiment and fewer requirements in stability and API style.\nWe're happy to review and help with external packages as well as pull requests;\nseveral parts of Hypothesis started life outside and were integrated later\n(with permission, of course).\n\nTo help people find your package, please use the `Framework :: Hypothesis\n`__ `trove classifier\n`__. We also recommend naming your package\nin the pattern of ``hypothesis-graphql`` and ``hypothesis-protobuf`` on PyPI.\n\nOn the other hand, being inside gets you access to some deeper implementation\nfeatures (if you need them) and better long-term guarantees about maintenance.\nWe particularly encourage pull requests for new composable primitives that\nmake implementing other strategies easier, or for widely used types in the\nPython standard library. Strategies for other things are also welcome;\nanything with external dependencies just goes in ``hypothesis.extra``.\n\n~~~~~~~~~\nThe build\n~~~~~~~~~\n\nThe build is driven by a ``build.sh`` shell script, which delegates to a custom Python-based build system.\nActually running the tests is managed by `tox `_, but the build system\nwill call out to the relevant tox environments so you mostly don't have to know anything about that\nunless you want to make changes to the test config. You also mostly don't need to know anything about the build system\nexcept to type ``./build.sh`` followed by the name of the task you want to run.\n\nAll of it will be checked on CI so you don't *have* to run anything locally, but you might\nfind it useful to do so: A full CI run can take up to twenty minutes,\nso running a smaller set of tests locally can be helpful.\n\nThe build system should be \"fairly\" portable, but is currently only known to work on Linux or macOS. It *might* work\non a BSD or on Windows with cygwin installed, but it hasn't been tried. Windows with WSL does work,\nas for Linux, and since OS-specific issues are rare for Hypothesis that's pretty useful.\nIf you try it and find it doesn't work, please do submit patches to fix that.\n\nSome notable commands:\n\n``./build.sh check-coverage`` will verify 100% code coverage by running a\ncurated subset of the test suite.\n\n``./build.sh check-py311`` (etc.) will run most of the test suite against a\nparticular python version.\n\n``./build.sh format`` will reformat your code according to the Hypothesis coding style. You should use this before each\ncommit ideally, but you only really have to use it when you want your code to be ready to merge.\n\nYou can also use ``./build.sh check-format``, which will run format and some linting and will then error if you have a\ngit diff. Note: This will error even if you started with a git diff, so if you've got any uncommitted changes\nthis will necessarily report an error.\n\nRun ``./build.sh tasks`` for a list of all supported build task names.\n\nNote: The build requires a lot of different versions of python, so rather than have you install them yourself,\nthe build system will install them itself in a local directory. This means that the first time you run a task you\nmay have to wait a while as the build downloads and installs the right version of python for you.\n\n~~~~~~~~~~~~~\nRunning Tests\n~~~~~~~~~~~~~\n\nThe tasks described above will run all of the tests (e.g. ``check-py311``). But\nthe ``tox`` task will give finer-grained control over the test runner. At a\nhigh level, the task takes the form:\n\n.. code-block::\n\n ./build.sh tox py311-custom 3.11.3 [tox args] -- [pytest args]\n\nNamely, first provide the tox environment (see ``tox.ini``), then the python\nversion to test with, then any ``tox`` or ``pytest`` args as needed. For\nexample, to run all of the tests in the file\n``tests/nocover/test_conjecture_engine.py`` with python 3.12:\n\n.. code-block::\n\n ./build.sh tox py312-custom 3.12.7 -- tests/nocover/test_conjecture_engine.py\n\nSee the ``tox`` docs and ``pytest`` docs for more information:\n* https://docs.pytest.org/en/latest/how-to/usage.html\n* https://tox.wiki/en/latest/config.html#cli\n\n^^^^^^^^^^^\nTest Layout\n^^^^^^^^^^^\n\nSee ``hypothesis-python/tests/README.rst``\n\n^^^^^^^^^^^^^^^^\nUseful Arguments\n^^^^^^^^^^^^^^^^\n\nSome useful arguments to pytest include:\n\n* You can pass ``-n 0`` to turn off ``pytest-xdist``'s parallel test execution.\n Sometimes for running just a small number of tests its startup time is longer\n than the time it saves (this will vary from system to system), so this can\n be helpful if you find yourself waiting on test runners to start a lot.\n* You can use ``-k`` to select a subset of tests to run. This matches on substrings\n of the test names. For example ``-kfoo`` will only run tests that have \"foo\" as\n a substring of their name. You can also use composite expressions here.\n e.g. ``-k'foo and not bar'`` will run anything containing foo that doesn't\n also contain bar. `More information on how to select tests to run can be found\n in the pytest documentation `__.\n"
},
{
"path": "LICENSE.txt",
"content": "Copyright (c) 2013, David R. MacIver\n\nAll code in this repository except where explicitly noted otherwise is released\nunder the Mozilla Public License v 2.0. You can obtain a copy at https://mozilla.org/MPL/2.0/.\n\nSome code in this repository comes from other projects. Where applicable, the\noriginal copyright and license are noted and any modifications made are released\ndual licensed with the original license.\n"
},
{
"path": "README.md",
"content": "\n
![](\"https://raw.githubusercontent.com/HypothesisWorks/hypothesis/master/brand/dragonfly-rainbow.svg\")
\n