- update to 0.18.5:
  * Beartype 0.18.5 resolves a critical low-level
    issue in @beartype's dynamic type-checking code generator for
    **nested beartype validator-in-container type hints** (e.g.,
    type hints of the form `list[typing.Annotated[{type},
    Is[{validator}]]]`). Someone, somewhere cares deeply about
    this. You might even be that someone.

• Files Changed
• Browse Source

- update to 0.18.4:
  * resolves a critical low-level issue in dynamic type-checking
    code generator for **nested tuple-in-dictionary type hints**
- update to 0.18.3:
  * Beartype 0.18.3 is for @iamrecursion and @sylvorg. May their
    usernames live forever in `git log` infamy. In this release,
    a few more bugs die.
- update to 0.18.2:
  * This patch release temporarily squelches (i.e., silences)
    a low-level `assert`
    statement erroneously performed during @beartype's dynamic
    code generation loop.
- update to 0.18.0:
  * We're *finally* type-checking general-purpose Python containers.

• Files Changed
• Browse Source

• Files Changed
• Browse Source

- update to 0.17.0:
  * Emit non-fatal warnings on type-checking violations? Yup. We got
    that. Grep violation_*type, then win.
  * Raise custom exception types on type-checking violations? We got
    that, too. violation_*type grepping intensifies.
  * Raise custom exception messages on type-checking violations? Got
    that. __instancecheck_str() enters the chat emboldened and
    swaggering.
  * Modify the verbosity of type-checking violation messages? Got
    that. violation_verbosity + BeartypeVerbosity is snickering in the
    back.
  * Reduce complex type hints to simple type aliases in type-checking
    violations? That is a thing now. type {name} = {hard_stuff} |
    {moar_stuff}.
  * Blatantly lie about the types your API expects by instructing
    @beartype to internally transform source to target type hints
    matching various patterns with type hint overrides? You know we
    even got that. hint_overrides + BeartypeHintOverrides. It's best
    not to question this stuff.

• Files Changed
• Browse Source

- update to 0.16.4:
  * **`beartype.claw` + methods + PEP 526.** Previously,
    `beartype.claw` silently failed to type-check PEP
    526-compliant annotated variable assignments in methods. Now,
    `beartype.claw` does so: e.g.,
- update to 0.16.3:
  * This bug-defying patch release adds official support for
    **hot module reloading,** **root superclass validators,**
    **forward reference `issubclass()` proxying,** **readable
    forward reference exceptions,** and **class redecoration
    eliding** as well as documenting a medley of topics and APIs
    first introduced with the `beartype.claw` subpackage under
- update to 0.16.2:
  * **Plum** + **class methods** (i.e., `@classmethod`-decorated
    methods) + **PEP 563** (i.e., `from __future__ import
    annotations`). If you use Plum – which you surely do, of
    course – you want this.
- update to 0.16.0:
  * @beartype 0.16.0 **[**codename: _Super Unsexy Stabilization
    Asinine Force (SUSAF)_**]** boringly stabilizes everything
    unstable about @beartype that made your coworker who only
    wears skinny jeans while squinting whenever you mention

- Update to version 0.11.0

• Files Changed
• Browse Source

- update to 0.15.0:
  * Like a cyberpunk phoenix whose intertube veins are made of
    pure honey and blueberry juic, 0.15.0 introduces
    the new `beartype.claw` API.
  * When you call import hooks published by the `beartype.claw`
    API, you enable **hybrid runtime-static type-checking.**
  * For many of you: "Yes. That is what this means." Pure-static
    type-checkers lie to you about everything, require
    maintaining fragile and unreadable `type: ignore[...]` and
    `pyright: ignore[...]` comment chatter throughout your once-
    pristine codebase, and fail to enforce anything at test- or
    runtime. In other words, they (mostly) suck; we should all
    stop using them, because they (mostly) fail at their core
    mandate.

• Files Changed
• Browse Source

- update to 0.14.1:
  * **[PEP 517][PEP 517].** This release restores our [PEP
    517][PEP 517]-compliant top-level `pyproject.toml` file in a
    vain and probably misguided attempt to restore the
    buildability of our documentation on the third-party
    ReadTheDocs (RTD) documentation host. Doing so nudges
    @beartype mildly closer towards abandoning the antiquated
    (and frankly objectionable) `setuptools` build system to
    Hatch, officially endorsed by the Python Packaging Authority
    (PyPA) as sane and *not* `setuptools`, which are the only
    criteria @leycec is looking for in a Python build system. The
    bar could *not* be lower.
  * **[PEP 544][PEP 544].** @beartype now officially supports
    *all* third-party `typing_extensions.Protocol` backports,
    resolving issue #241 kindly submitted by MIT machine learning
    guru @rsokl (Ryan Soklaski). This release also restores
    testing of the `typing_extensions.Protocol` superclass, which
    now passes under *all* `typing_extensions` versions. Let's
    not ask prying and uncomfortable questions about what exactly
    was resolved here, because then @leycec might break down and
    openly weep emoji tears live on GitHub.
  * **[PEP 585][PEP 585].** This release "undeprecates" the
    `beartype.typing.{Match,Pattern}` type hints deprecated by
    [PEP 585][PEP 585], resolving issue #240 kindly submitted by
    AI King @KyleKing (Kyle King). Specifically, the
    `beartype.typing` subpackage now imports those type hints
    from the standard `re` rather than `typing` module under
    Python >= 3.9. This is why @leycec sighs in his sleep while
    clutching a Bengal plushy.

• Files Changed
• Browse Source

- update to 0.14.0:
  * This minor release brings exhilarating support for PEP
    673 (i.e., `typing.Self`) and PEP 675 (i.e.,
    `typing.LiteralString`) as well as
    substantially improved compatibility with PyPy.
  * This release resolves a significant incompatibility
    with PyPy, whose implementation of the `id()` builtin appears
    to occasionally [read: non-deterministically] return object
    identifiers that are negative integers. Specifically,
    @beartype now guaranteeably generates valid parameter names
    passed to type-checking wrapper functions regardless of the
    sign of the `id()` of the values of those parameters. Doing
    so resolves issue #232 kindly submitted by @jvesely (Jan
    Vesely) who purportedly lives in or around an ancient pork
    by-product that has calcified into stone -- which is quite
    impressive, really. Stoneham: it's like Stonehenge, only
    American and yummy in your tummy. Thanks so much for the
    heads up, @jvesely.

• Files Changed
• Browse Source

- update to 0.13.1:
  * The `test_pep561_mypy()` integration test validating that
    @beartype passes all mypy-specific static runtime type-
    checks
  * **Pandera (pandas) type hints** (i.e., ad-hoc PEP-
    noncompliant type hints validating pandas `DataFrame`
    objects, produced by subscripting factories published by the
    `pandera.typing` subpackage and validated *only* by user-
    defined callables decorated by the ad-hoc PEP-noncompliant
    `@pandera.check_types` runtime type-checking decorator),
    resolving feature request #227 kindly submitted by
    @ulfaslakprecis (Ulf Aslak) the Big Boss Typer. @beartype
    now:
  * Transparently supports pandera's PEP-noncompliant
    `@pandera.check_types` decorator for deeply runtime type-
    checking arbitrary pandas objects.
  * *Always* performs a rudimentary `O(1)` `isinstance()`-based
    type-check for each pandera type hint. Doing so substantially
    improves usability in common use cases, including:
  * Callables annotated by one or more pandera type hints that
    are correctly decorated by @beartype but incorrectly *not*
    decorated by the pandera-specific `@pandera.check_types`
    decorator.
  * (Data)classes annotated by one or more pandera type hints.
  * Pandera type hints passed as the second argument to
    statement-level @beartype type-checkers – including:
  * **Pseudo-callable monkey-patching support.** `@beartype` now
    supports **pseudo-callables** (i.e., otherwise uncallable
    objects masquerading as callable by defining the `__call__()`
    dunder method), resolving feature request #211 kindly

• Files Changed
• Browse Source

- Disable test_beartype_in_sphinx, broken with sphinx 6.1.3
  gh#beartype/beartype#209
- Update to version 0.12.0
  Change log - https://github.com/beartype/beartype/releases

• Files Changed
• Browse Source

• Files Changed
• Browse Source

Required by python-sphinx-autodoc-typehints 

• Browse Source