Sign Up
Log In
Log In
or
Sign Up
Places
All Projects
Status Monitor
Collapse sidebar
home:wicked:qubes-build
python-beartype
python-beartype.changes
Overview
Repositories
Revisions
Requests
Users
Attributes
Meta
File python-beartype.changes of Package python-beartype
------------------------------------------------------------------- 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.
Locations
Projects
Search
Status Monitor
Help
OpenBuildService.org
Documentation
API Documentation
Code of Conduct
Contact
Support
@OBShq
Terms
openSUSE Build Service is sponsored by
The Open Build Service is an
openSUSE project
.
Sign Up
Log In
Places
Places
All Projects
Status Monitor
