File python-beartype.changes of Package python-beartype

Overview Repositories Revisions Requests Users Attributes Meta

File python-beartype.changes of Package python-beartype (Revision 09b46e026d0dcf15e0b5e3319bc3edb9)

Currently displaying revision 09b46e026d0dcf15e0b5e3319bc3edb9 , Show latest

-------------------------------------------------------------------
Sat Apr 27 08:59:16 UTC 2024 - Dirk Müller <dmueller@suse.com>

- 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.

-------------------------------------------------------------------
Sat Apr 20 13:46:02 UTC 2024 - Dirk Müller <dmueller@suse.com>

- 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.

-------------------------------------------------------------------
Fri Feb 16 12:38:14 UTC 2024 - Ben Greiner <code@bnavigator.de>

- Update to 0.17.2
  * Beartype 0.17.2 nervously skitters about on thin ice. Cracks
    form, yet beartype 0.17.2 fails to return to shore. "What are
    you even doing!?", the crowd exclaims. Verily, it is best not
    to ask questions.
  * This Release Kinda Sucks, Huh?
  * Alright, alright. You found us out already.
  * Beartype 0.17.2 is an extremely minor patch release that exists
    purely to relax the bad assumption that all Python 3.9 releases
    unconditionally define the standard
    typing.ForwardRef.__forward_module__ dunder attribute,
    resolving issue #324 kindly submitted by stone-cold typonista
    @jvesely (Jan Vesely). Although Python ≥ 3.9.18 definitively
    defines this attribute, an unknown range of older Python 3.9
    patch releases fail to do so.
  * Beartype 0.17.2 resolves this by naively pretending that all
    Python 3.9 releases fail to do so. Although kinda non-ideal,
    it's unclear whether this attribute is even used (i.e., set to
    a string) under Python 3.9. In fact, it's unclear whether this
    attribute is even used anywhere, ever. It probably will be
    under Python ≥ 3.13, but that's putting the proverbial cart
    before the horse. Anyyyyyyway.
  * We now return to your regularly scheduled Python hackathon.
- Release 0.17.1
  * Beartype 0.17.1 gently descends from the heavens on a golden
    dragon made of rainbows. "How can this be!?", the crowd
    exclaims. Verily, it is best not to ask questions.
  * This patch release adds explicit support for typing.NamedTuple
    subclasses under PEP 56

-------------------------------------------------------------------
Tue Feb  6 18:46:35 UTC 2024 - Daniel Garcia <daniel.garcia@suse.com>

- 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.

-------------------------------------------------------------------
Fri Nov 10 12:43:41 UTC 2023 - Dirk Müller <dmueller@suse.com>

- 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

-------------------------------------------------------------------
Wed Jul 26 12:56:23 UTC 2023 - Dirk Müller <dmueller@suse.com>

- 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.

-------------------------------------------------------------------
Sun Jun 11 09:26:13 UTC 2023 - Dirk Müller <dmueller@suse.com>

- 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.

-------------------------------------------------------------------
Wed May  3 15:40:20 UTC 2023 - Dirk Müller <dmueller@suse.com>

- 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.

-------------------------------------------------------------------
Sun Apr 16 09:16:52 UTC 2023 - Dirk Müller <dmueller@suse.com>

- 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
    submitted by Google X typing guru @patrick-kidger (Patrick
    Kidger). When passed a pseudo-callable whose `__call__()`
    method is annotated by one or more type hints, `@beartype`
    runtime type-checks that method in the standard way.

-------------------------------------------------------------------
Wed Jan 25 13:18:26 UTC 2023 - Daniel Garcia <daniel.garcia@suse.com>

- 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

-------------------------------------------------------------------
Wed Oct 12 02:44:23 UTC 2022 - Yogalakshmi Arunachalam <yarunachalam@suse.com>

- Update to version 0.11.0
  Change log - https://github.com/beartype/beartype/releases

-------------------------------------------------------------------
Thu May  5 06:14:45 UTC 2022 - Matej Cepl <mcepl@suse.com>

- Initial packaging effort for beartype 0.10.4.

Places

File python-beartype.changes of Package python-beartype (Revision 09b46e026d0dcf15e0b5e3319bc3edb9)

Places