{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":252646465,"defaultBranch":"main","name":"beartype","ownerLogin":"beartype","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2020-04-03T06:06:22.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/63089855?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1717485697.0","currentOid":""},"activityList":{"items":[{"before":"fb3f0499e8ec3989c7f4c700a24648eec68c7ac4","after":"b8fa8e8968f7efe8eedcad82809e0016ed96cc0e","ref":"refs/heads/pyproject","pushedAt":"2024-06-05T07:01:51.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`setup.py` -> Hatch + `pyproject.toml` x 2.\n\nThis commit is the next in a commit chain fundamentally refactoring\n@beartype's build toolchain from the venerable (and frankly awful)\n`setuptools` to a Hatch-based `pyproject.toml` installation workflow,\nen-route to resolving feature request #396 kindly submitted by suave ML\nMilano guru @baggiponte exactly a year ago. *Exactly a year ago!?!?!*\n...how is possible that so much and yet so little has changed? It is\npossible. Please manage our time better or we're never gonna cross that\nfinish line, GitHub. @leycec assumes no responsibility for just playing\nvideo games for a year.\n\nSpecifically, this commit finishes authoring a greatly expanded\ntop-level `pyproject.toml` file from the stinking, retching, wretched,\nfeted guts of a hodge-podge of long-obsolete `setuptools`-specific files\n(e.g., `MANIFEST.in`, `setup.cfg`, `setup.py`, `beartype/meta.py`).\nThe Hatch-specific `hatch project metadata` command now successfully\noutputs a table (dictionary) of all PyPI-friendly @beartype metadata.\n\nUp next: the antiquated `beartype.meta` submodule, which now needs to be\nrefactored to reference `pyproject.toml` keys via the standard\n`importlib.metadata` submodule. It is boring. It is Python. (*Chortling chores!*)","shortMessageHtmlLink":"setup.py -> Hatch + pyproject.toml x 2."}},{"before":null,"after":"fb3f0499e8ec3989c7f4c700a24648eec68c7ac4","ref":"refs/heads/pyproject","pushedAt":"2024-06-04T07:21:37.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`setup.py` -> Hatch + `pyproject.toml` x 1.\n\nThis commit is the first in a commit chain fundamentally refactoring\n@beartype's build toolchain from the venerable (and frankly awful)\n`setuptools` to a Hatch-based `pyproject.toml` installation workflow,\nen-route to resolving discussion #243 kindly submitted by suave ML\nMilano guru @baggiponte exactly a year ago. *Exactly a year ago!?!?!*\n...how is to possible that so much and yet so little has changed?\nPlease manage our time better or we're never gonna cross that finish\nline, GitHub. @leycec assumes no responsibility for just playing video\ngames for a year.\n\nSpecifically, this commit:\n\n* Begins authoring a greatly expanded top-level `pyproject.toml` file\n from the stinking, retching, wretched, feted guts of a hodge-podge of\n long-obsolete `setuptools`-specific files (e.g., `MANIFEST.in`,\n `setup.cfg`, `setup.py`, `beartype/meta.py`).\n* Permanently removes all `setuptools`-specific files -- including:\n * `MANIFEST.in`.\n * `setup.cfg`.\n * `setup.py`.\n\n(*Brood of a hundred blood-red undead!*)","shortMessageHtmlLink":"setup.py -> Hatch + pyproject.toml x 1."}},{"before":"0b4453f83c7ed4be054d8733aab8075e1478e166","after":"c8c4f05d49ac1dd240a7325652404ed995004eb9","ref":"refs/heads/main","pushedAt":"2024-06-01T06:45:54.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Python 3.13 x 3.\n\nThis commit is the next in a commit chain officially supporting the\nupcoming release of Python 3.13, en-route to resolving future issue #387\nkindly submitted by core Python `typing` mega-boss @JelleZijlstra (Jelle\nZijlstra). Specifically, this commit resolves *all* remaining\ncompatibility issues with respect to Python 3.13 – except for static\ntype-checking under `mypy` and `pyright`, which remains an open (but\nlargely boring) question. For all intents and purposes, @beartype now\nofficially supports Python 3.13! *Wohoooo.* (*Fully syntactic synapses snap sinfully!*)","shortMessageHtmlLink":"Python 3.13 x 3."}},{"before":"e07f8ee04819e27e11270c33777649586c6f4d87","after":"0b4453f83c7ed4be054d8733aab8075e1478e166","ref":"refs/heads/main","pushedAt":"2024-05-31T06:35:53.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Python 3.13 x 2.\n\nThis commit is the next in a commit chain officially supporting the\nupcoming release of Python 3.13, en-route to resolving future issue #387\nkindly submitted by core Python `typing` mega-boss @JelleZijlstra (Jelle\nZijlstra). Specifically, this commit generalizes internal introspection\nof standard type hint factories to note that the following factories now\nconditionally accept a second optional child type hint under Python ≥\n3.13, due to PEP 696 (i.e., \"Type Defaults for Type Parameters\"):\n\n* `contextlib.AsyncContextManager[...]`.\n* `contextlib.ContextManager[...]`.\n* `typing.AsyncContextManager[...]`.\n* `typing.ContextManager[...]`.\n\nLet's do this, `typing` bois! (*Final vanquishment of a languishing vanguard!*)","shortMessageHtmlLink":"Python 3.13 x 2."}},{"before":"4b27fbb518cabad406132b0fc321028ddb26d829","after":"e07f8ee04819e27e11270c33777649586c6f4d87","ref":"refs/heads/main","pushedAt":"2024-05-30T07:44:43.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Python 3.13 x 1.\n\nThis commit is the first in a commit chain officially supporting the\nupcoming release of Python 3.13, en-route to resolving future issue #386\nkindly submitted by core Python `typing` mega-boss @JelleZijlstra (Jelle\nZijlstra). Specifically, this commit synchronizes the standard `typing`\nmodule with our non-standard `beartype.typing` subpackage under Python\n3.13. Let's do this, `typing` bois! (*Intrepid trip of an intraprocess PID!*)","shortMessageHtmlLink":"Python 3.13 x 1."}},{"before":"e3f322bb0df192429581e0fd412cbf013e792866","after":"4b27fbb518cabad406132b0fc321028ddb26d829","ref":"refs/heads/main","pushedAt":"2024-05-30T06:34:12.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`beartype.typing` removals scheduled.\n\nThis commit schedules various public `typing` attributes currently\nexported by the `beartype.typing` subpackage for removal under future\nPython releases, resolving future issue #386 kindly submitted by core\nPython `typing` mega-boss @JelleZijlstra (Jelle Zijlstra). Specifically,\nthis commit schedules:\n\n* `beartype.typing.ByteString` for removal under Python ≥ 3.14.\n* `beartype.typing.AnyStr` for removal under Python ≥ 3.16.\n\nThanks a heap overflow for the heads up, mega-boss @JelleZijlstra!\n(*Stationary inundation on undated stats!*)","shortMessageHtmlLink":"beartype.typing removals scheduled."}},{"before":"b7559598366b73c8c0f358aafade48a2a7112bfa","after":"e3f322bb0df192429581e0fd412cbf013e792866","ref":"refs/heads/main","pushedAt":"2024-05-28T07:53:06.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`Type[Self]`.\n\nThis commit resolves a critical issue with respect to deeply\ntype-checking **`Type[Self]` type hints** (i.e., hints validating a\nparameter or return to be a subclass of the currently decorated class,\nintegrating either the PEP 484-compliant `typing.Type[...]` or PEP\n585-compliant `type[...]` type hint factories by the PEP 673-compliant\n`typing.Self` type hint), resolving issue #389 kindly submitted by the\nfearless ML retail guru @msvensson (Marcus Svensson). Specifically, this\ncommit:\n\n* Refactors our logic deeply type-checking `Type[...]` type hints to\n resemble that of other deep type-checking logic, ensuring proper\n sanitization of the child type hints subscripting parent `Type[...]`\n type hints -- which, in this case, then sanitizes the PEP\n 673-compliant `typing.Self` type hint to the class currently being\n decorated by the `@beartype` decorator.\n* Exhaustively unit tests that all of this still makes sense.\n\nThis is why we @beartype: *so that only @leycec is exhausted.*\n(*Humble mumbler is a bumbling bumble-bee!*)","shortMessageHtmlLink":"Type[Self]."}},{"before":"791602d32b08feda65e2778fba7738c83027622a","after":"b7559598366b73c8c0f358aafade48a2a7112bfa","ref":"refs/heads/main","pushedAt":"2024-05-26T07:22:24.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`multiprocessing` compatibility.\n\nThis commit explicitly generalizes the @beartype codebase to support\nPython subprocesses forked by the standard `multiprocessing` package,\nresolving issue #382 kindly submitted by type-checking superstar\n@avolchek (Andrei Volchek). Specifically, this commit:\n\n* Generalizes all **beartype exceptions** (i.e., exception subclasses\n published by the `beartype.roar` subpackage) to support pickling and\n unpickling via the standard `pickle` module, which then suffices to\n support the standard `multiprocessing` package, which shockingly\n leverages `pickle` rather than `dill` in 2024. *Why is `pickle` still\n even a thing!?*\n* Exhaustively exercises this functionality with unit tests.\n\nI am exhausted. Let's *not* do this again, fam. I sigh while futilely\nflinging my hands up to the sky on a murky Saturday evening! (*Bad rad sad Chad!*)","shortMessageHtmlLink":"multiprocessing compatibility."}},{"before":"b5178bc384e789e24048ee75ccd5d051b911d545","after":"791602d32b08feda65e2778fba7738c83027622a","ref":"refs/heads/main","pushedAt":"2024-05-24T07:21:02.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`pyright 1.1.364`.\n\nThis commit generalizes types pertaining to abstract syntax trees (ASTs)\nacross the @beartype codebase to support `pyright 1.1.364`, which\nappears to have gone *really* hard on AST types. In theory, this commit\nrestores our GitHub Actions-based continuous integration (CI) pipeline\nto worky. In theory. In theory, @leycec also has muscles. *In theory.*\n(*Theoretical theorems bring binderless reams of dreams!*)","shortMessageHtmlLink":"pyright 1.1.364."}},{"before":"dccd8df78176fefb41257ff28a50fe41ad0f6aba","after":"b5178bc384e789e24048ee75ccd5d051b911d545","ref":"refs/heads/main","pushedAt":"2024-05-24T06:42:22.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Update install.rst so joke is more scientifically accurate (#384)\n\nReplaced the word venomous with vicious, since anacondas are not venomous :)","shortMessageHtmlLink":"Update install.rst so joke is more scientifically accurate (#384)"}},{"before":"83866f1a3d5fbdf5352414362bf43dc9ea64e7aa","after":"dccd8df78176fefb41257ff28a50fe41ad0f6aba","ref":"refs/heads/main","pushedAt":"2024-05-23T07:08:29.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Reiterables x 3.\n\nThis commit is the next in a commit chain deeply type-checking\n**reiterables** (i.e., collections satisfying the\n`collections.abc.Collection` protocol with guaranteed `O(1)` read-only\naccess to *only* the first collection item), en-route to *finally*\nresolving feature request #167 kindly submitted by the perennial\nbrilliant @langfield (...*how I miss that awesome guy!*) several\nlifetimes ago back when I was probably a wandering vagabond Buddhist\nmonk with a bad attitude, a begging bowl the size of my emaciated torso,\nand an honestly pretty cool straw hat that glinted dangerously in the\nfirelight. Note that reiterables include *all* containers matched by one\nor more of the following PEP 484- or 585-compliant type hints:\n\n* `frozenset[...]`.\n* `set[...]`.\n* `collections.deque[...]`.\n* `collections.abc.Collection[...]`.\n* `collections.abc.KeysView[...]`.\n* `collections.abc.MutableSet[...]`.\n* `collections.abc.Set[...]`.\n* `collections.abc.ValuesView[...]`.\n* `typing.AbstractSet[...]`.\n* `typing.Collection[...]`.\n* `typing.Deque[...]`.\n* `typing.FrozenSet[...]`.\n* `typing.KeysView[...]`.\n* `typing.MutableSet[...]`.\n* `typing.Set[...]`.\n* `typing.ValuesView[...]`.\n\nSpecifically, this commit continues unit testing this implementation.\nSome things are tested, so it's probably *not* totally busted anymore.\nBut... just wow. Should have done this two years ago, huh? This is why\nwe can't have good type-checking: @leycec gets distracted by shiny\nglittery stuff way too easily. (*Electable connectives in an electric delicatessen!*)","shortMessageHtmlLink":"Reiterables x 3."}},{"before":"b215401bc932bf9dc09884bbceb9b7142dc5c9c0","after":"83866f1a3d5fbdf5352414362bf43dc9ea64e7aa","ref":"refs/heads/main","pushedAt":"2024-05-22T06:30:17.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Reiterables x 2.\n\nThis commit is the next in a commit chain deeply type-checking\n**reiterables** (i.e., collections satisfying the\n`collections.abc.Collection` protocol with guaranteed `O(1)` read-only\naccess to *only* the first collection item), en-route to *finally*\nresolving feature request #167 kindly submitted by the perennial\nbrilliant @langfield (...*how I miss that awesome guy!*) several\nlifetimes ago back when I was probably a wandering vagabond Buddhist\nmonk with a bad attitude, a begging bowl the size of my emaciated torso,\nand an honestly pretty cool straw hat that glinted dangerously in the\nfirelight. Note that reiterables include *all* containers matched by one\nor more of the following PEP 484- or 585-compliant type hints:\n\n* `frozenset[...]`.\n* `set[...]`.\n* `collections.deque[...]`.\n* `collections.abc.Collection[...]`.\n* `collections.abc.KeysView[...]`.\n* `collections.abc.MutableSet[...]`.\n* `collections.abc.Set[...]`.\n* `collections.abc.ValuesView[...]`.\n* `typing.AbstractSet[...]`.\n* `typing.Collection[...]`.\n* `typing.Deque[...]`.\n* `typing.FrozenSet[...]`.\n* `typing.KeysView[...]`.\n* `typing.MutableSet[...]`.\n* `typing.Set[...]`.\n* `typing.ValuesView[...]`.\n\nSpecifically, this commit:\n\n* Finalizes a now-working implementation of this deep type-checking.\n* Begins unit testing this implementation. Some things are tested, so\n it's probably *not* totally busted anymore.\n\nBut... just wow. Should have done this two years ago, huh? This is why\nwe can't have good type-checking: @leycec gets distracted by shiny\nglittery stuff way too easily. (*Habitual deviations cohabit unenviable consultations!*)","shortMessageHtmlLink":"Reiterables x 2."}},{"before":"d1d6f55159ac5a5e9f5e33432795103b7913d78a","after":"b215401bc932bf9dc09884bbceb9b7142dc5c9c0","ref":"refs/heads/main","pushedAt":"2024-05-21T06:44:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Throw shade at bad boi callables.\n\nThis commit improves the readability of exceptions raised by edge-case\n`@beartype`-decorated callables annotated by one or more forward\nreferences while also failing to define the `__module__` dunder\nattribute, resolving issue #381 kindly submitted by dynamical Bostonian\nand bonafide real-life main character @femtomc (McCoy R. Becker). For\nunknown (and probably indefensible) reasons, the third-party\n`markdown-exec` package appears to define such horrifying callables.\nWhen confronted with such horrifying callables, the `@beartype`\ndecorator now raises human-readable exceptions resembling:\n\n```python\nbeartype.roar.BeartypeDecorHintForwardRefException: Function muh_func()\nparameter \"muh_arg\" forward reference type hint \"MuhType\" unresolvable,\nas \"muh_func.__module__\" dunder attribute undefined (e.g., due to\n being defined only dynamically\nin-memory). So much bad stuff is happening here all at once that\n@beartype can no longer cope with the explosion in badness.\n```\n\nFlex those burly exception messages, @beartype! Flex 'em! (*A flexible lexicon on iconic nicks!*)","shortMessageHtmlLink":"Throw shade at bad boi callables."}},{"before":"ba3bb42116228019f6dce9b90648a17dea514007","after":"d1d6f55159ac5a5e9f5e33432795103b7913d78a","ref":"refs/heads/main","pushedAt":"2024-05-18T07:12:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Reiterables x 1.\n\nThis commit is the first in a commit chain deeply type-checking\n**reiterables** (i.e., collections satisfying the\n`collections.abc.Collection` protocol with guaranteed `O(1)` read-only\naccess to *only* the first collection item), en-route to *finally*\nresolving feature request #167 kindly submitted by the perennial\nbrilliant @langfield (...*how I miss that awesome guy!*) several\nlifetimes ago back when I was probably a wandering vagabond Buddhist\nmonk with a bad attitude, a begging bowl the size of my emaciated torso,\nand an honestly pretty cool straw hat that glinted dangerously in the\nfirelight. Note that reiterables include *all* containers matched by one\nor more of the following PEP 484- or 585-compliant type hints:\n\n* `frozenset[...]`.\n* `set[...]`.\n* `collections.deque[...]`.\n* `collections.abc.Collection[...]`.\n* `collections.abc.KeysView[...]`.\n* `collections.abc.MutableSet[...]`.\n* `collections.abc.Set[...]`.\n* `collections.abc.ValuesView[...]`.\n* `typing.AbstractSet[...]`.\n* `typing.Collection[...]`.\n* `typing.Deque[...]`.\n* `typing.FrozenSet[...]`.\n* `typing.KeysView[...]`.\n* `typing.MutableSet[...]`.\n* `typing.Set[...]`.\n* `typing.ValuesView[...]`.\n\nSpecifically, this commit almost fully implements this deep\ntype-checking. Nothing's tested, so it's probably totally busted. But...\njust wow. Should have done this two years ago, huh? This is why we can't\nhave good type-checking: @leycec gets distracted by shiny glittery stuff\nway too easily. (*Lackadaisical lacky licking a licorice chalice!*)","shortMessageHtmlLink":"Reiterables x 1."}},{"before":"1d0bd23fac4c340b9c036b55689ec3c880f3fc91","after":"ba3bb42116228019f6dce9b90648a17dea514007","ref":"refs/heads/main","pushedAt":"2024-05-17T07:18:35.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Import hook decoration position x 3.\n\nThis commit is the last in a commit chain enabling end users to\nexplicitly configure **import hook decoration positions** (i.e.,\ncompeting locations to which the `@beartype` decorator will be\nimplicitly injected into existing chains of one or more decorators\ndecorating classes and callables defined by modules imported under\n`beartype.claw` import hooks, each with concomitant tradeoffs with\nrespect to decorator interoperability and quality assurance), resolving\nfeature request #374 kindly indirectly submitted by bestest @beartype\nusers @danielward27 and @patrick-kidger courtesy parent feature request\n#368. Specifically, this commit exhaustively tests this functionality as\nshockingly working. Would @leycec lie!? (*Win some, winsome yards of vineyards!*)","shortMessageHtmlLink":"Import hook decoration position x 3."}},{"before":"72e3eb19a012860536e2255defeb59bd288622a5","after":"1d0bd23fac4c340b9c036b55689ec3c880f3fc91","ref":"refs/heads/main","pushedAt":"2024-05-16T08:05:44.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Import hook decoration position x 2.\n\nThis commit is the next in a commit chain enabling end users to\nexplicitly configure **import hook decoration positions** (i.e.,\ncompeting locations to which the `@beartype` decorator will be\nimplicitly injected into existing chains of one or more decorators\ndecorating classes and callables defined by modules imported under\n`beartype.claw` import hooks, each with concomitant tradeoffs with\nrespect to decorator interoperability and quality assurance), en-route\nto resolving feature request #374 kindly indirectly submitted by bestest\n@beartype users @danielward27 and @patrick-kidger courtesy parent\nfeature request #368. Specifically, this commit implements support for\nthis functionality in `beartype.claw` import hooks. Nothing remains\ntested, yet everything remains worky. Would @leycec lie!?\n(*Invincible principalities invoke your princely pal, Vince!*)","shortMessageHtmlLink":"Import hook decoration position x 2."}},{"before":"f4fb42c699835f6411bfe16b0e26e22bc8a90d5b","after":"72e3eb19a012860536e2255defeb59bd288622a5","ref":"refs/heads/main","pushedAt":"2024-05-15T07:41:16.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Import hook decoration position x 1.\n\nThis commit is the first in a commit chain enabling end users to\nexplicitly configure **import hook decoration positions** (i.e.,\ncompeting locations to which the `@beartype` decorator will be\nimplicitly injected into existing chains of one or more decorators\ndecorating classes and callables defined by modules imported under\n`beartype.claw` import hooks, each with concomitant tradeoffs with\nrespect to decorator interoperability and quality assurance), en-route\nto resolving feature request #374 kindly indirectly submitted by bestest\n@beartype users @danielward27 and @patrick-kidger courtesy parent\nfeature request #368. Specifically, this commit:\n\n* Defines a new public `beartype.BeartypeDecorationPosition`\n configuration enumeration, currently containing this pair of members:\n * `BeartypeDecorationPosition.FIRST`, the **first (i.e., bottom-most)\n decorator position**. Passing this member configures\n :mod:`beartype.claw` import hooks to inject the\n :func:`beartype.beartype` decorator as the first (i.e., bottom-most)\n decorator in relevant decorator chains. Examples below or it didn't\n happen.\n * `BeartypeDecorationPosition.LAST`, the **last (i.e., top-most)\n decorator position**. As the default, this position need *not* be\n explicitly passed\n* Defines a pair of new optional parameters with which to instantiate\n **beartype configurations** (i.e., `beartype.BeartypeConf` objects):\n * `claw_decoration_position_funcs`, the **import hook callable\n decorator position** (i.e., location to which the `@beartype`\n decorator will be implicitly injected into existing chains of one or\n more decorators decorating functions and methods defined by modules\n imported under :mod:`beartype.claw` import hooks). Defaults to\n `BeartypeDecorationPosition.LAST`.\n\n Modifying this configures import hooks to inject `@beartype` as the\n first (rather than last) decorator for callables. If your codebase\n requires this, consider submitting an issue to the @beartype issue\n tracker. Ideally, the `@beartype` decorator should be\n order-invariant with respect to decorator chaining and thus support\n decoration in *any* position – including the default last position:\n e.g.,\n\n ```python\n # Registering this import hook...\n from beartype import BeartypeConf, BeartypeDecorationPosition\n from beartype.claw import beartype_this_package\n beartype_this_package(conf=BeartypeConf(\n claw_decoration_position_funcs=(\n BeartypeDecorationPosition.FIRST)))\n\n # ...transforms chains of function decorators like this...\n from functools import cache\n @cache\n def chad_func() -> int:\n return 42\n\n # ...into chains of function decorators like this.\n from beartype import beartype\n from functools import cache\n @cache\n @beartype # <-- @beartype decorates first rather than last! \\\\o/\n def chad_func() -> int:\n return 42\n ```\n * `claw_decoration_position_types`, the **import hook class decorator\n position** (i.e., location to which the `@beartype` decorator will\n be implicitly injected into existing chains of one or more\n decorators decorating classes defined by modules imported under\n `beartype.claw` import hooks). Defaults to\n `BeartypeDecorationPosition.LAST`.\n\n Modifying this configures import hooks to inject `@beartype` as the\n first (rather than last) decorator for classes. As above, if your\n codebase requires this, consider submitting an issue to the\n @beartype issue tracker: e.g.,\n\n ```python\n # Registering this import hook...\n from beartype import BeartypeConf, BeartypeDecorationPosition\n from beartype.claw import beartype_this_package\n beartype_this_package(conf=BeartypeConf(\n claw_decoration_position_types=BeartypeDecorationPosition.FIRST))\n\n # ...transforms chains of class decorators like this...\n from dataclasses import dataclass\n @dataclass\n class ClassyData(object):\n integral_datum: int\n\n # ...into chains of class decorators like this.\n from beartype import beartype\n from dataclasses import dataclass\n @dataclass\n @beartype # <-- @beartype decorates first rather than last! \\\\o/\n class ClassyData(object):\n integral_datum: int\n ```\n\nNaturally, not much is tested and even less is likely to work. (*Boomy looms of doomy rooms!*)","shortMessageHtmlLink":"Import hook decoration position x 1."}},{"before":"910579ef1a31bf255bb93e1c2657ea2c321c14e8","after":"f4fb42c699835f6411bfe16b0e26e22bc8a90d5b","ref":"refs/heads/main","pushedAt":"2024-05-14T07:33:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Forward reference proxy recursion resolved.\n\nThis commit resolves a *possible* infinite recursion loop\ngrimace induced by **forward reference proxies** (i.e.,\n@beartype-specific dynamically generated subclasses proxying external\nuser-defined classes that have yet to be defined), resolving no issue\nnobody ever submitted. What's creepy about this one is that CPython\nprobably *should* have been – but wasn't – raising a `RecursionError`\nfrom the `__instancecheck__()` dunder method of the metaclass of these\nproxies. But... CPython wasn't doing that. For unknown reasons, CPython\nitself was just quietly breaking the recursion after a certain number of\nrecursive iterations. It's all kinda creepy, honestly. What is this,\nTyping Halloween all over again!? *Annnnway.* Everything is resolved\nnow. Sure took forever, too. I've been sitting on this commit for a\nweek, because every time I touched anything another unit test died.\nThis. This is why we test. Let's pretend this commit message isn't\nconcerning you as we just push this onto `main` already! (*A woozy doozy!*)","shortMessageHtmlLink":"Forward reference proxy recursion resolved."}},{"before":"8fc6e2a6eb07ecf5c67be095179465046a295ea6","after":"910579ef1a31bf255bb93e1c2657ea2c321c14e8","ref":"refs/heads/main","pushedAt":"2024-05-04T05:40:03.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"JAX integration test robustness.\n\nThis commit improves the robustness (i.e., portability) of JAX-specific\nintegration tests in our test suite, preventing these tests from\nerroneously failing with spurious warnings in the event of a mismatch\nbetween the CPU flags with which the low-level C-based `jaxlib` package\nwas compiled and the CPU flags supported by the current system.\n(*Unsettling settlement of unmentionable sediment!*)","shortMessageHtmlLink":"JAX integration test robustness."}},{"before":"0612105e9d04d5b34edbe6f6fadf0e3097492613","after":"8fc6e2a6eb07ecf5c67be095179465046a295ea6","ref":"refs/heads/main","pushedAt":"2024-05-02T07:15:59.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`@bearytype` + `__call__()` + `__wrapped__` x 6.\n\nThis commit is the next in a commit chain generalizing the `@beartype`\ndecorator to support **pseudo-callable wrapper objects** (i.e., objects\ndefining both the `__call__()` and `__wrapped__` dunder attributes),\nen-route to resolving feature request #368 kindly submitted by\n@danielward27 (Daniel Ward). Specifically, this commit is the last in a\ncommit subchain generalizing our **argument parser** (i.e., the private\n`beartype._util.func.arg.utilfuncargiter.iter_func_args()` generator) to\ntransparently parse bound method descriptor parameters by omitting the\nfirst mandatory `self` parameter implicitly passed by all bound method\ndescriptors. Frankly, it's best not to think too hard about any of this.\n(*Eruditely lost on Fhloston Paradise!*)","shortMessageHtmlLink":"@bearytype + __call__() + __wrapped__ x 6."}},{"before":"86c429698668176b01d002765c4893e6f7078e92","after":"0612105e9d04d5b34edbe6f6fadf0e3097492613","ref":"refs/heads/main","pushedAt":"2024-05-01T06:58:13.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`@bearytype` + `__call__()` + `__wrapped__` x 5.\n\nThis commit is the next in a commit chain generalizing the `@beartype`\ndecorator to support **pseudo-callable wrapper objects** (i.e., objects\ndefining both the `__call__()` and `__wrapped__` dunder attributes),\nen-route to resolving feature request #368 kindly submitted by\n@danielward27 (Daniel Ward). Specifically, this commit is the first in a\ncommit subchain generalizing our **argument parser** (i.e., the private\n`beartype._util.func.arg.utilfuncargiter.iter_func_args()` generator) to\ntransparently parse bound method descriptor parameters by omitting the\nfirst mandatory `self` parameter implicitly passed by all bound method\ndescriptors. Frankly, it's best not to think too hard about any of this.\n(*Sunny fauna in a funny sauna!*)","shortMessageHtmlLink":"@bearytype + __call__() + __wrapped__ x 5."}},{"before":"8ce81876c682263c8c8581fcc47c3056e1b7b0cb","after":"86c429698668176b01d002765c4893e6f7078e92","ref":"refs/heads/main","pushedAt":"2024-04-30T07:04:23.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`@bearytype` + `__call__()` + `__wrapped__` x 4.\n\nThis commit is the next in a commit chain generalizing the `@beartype`\ndecorator to support **pseudo-callable wrapper objects** (i.e., objects\ndefining both the `__call__()` and `__wrapped__` dunder attributes),\nen-route to resolving feature request #368 kindly submitted by\n@danielward27 (Daniel Ward). Specifically, this commit continues\nimproving the internal extensibility of @beartype's dynamic code\ngenerator by refactoring:\n\n* The current approach that laboriously passes `n` metadatum as hidden\n parameters to type-checking wrapper functions into...\n* A new approach that efficiently and trivially passes a single\n `BeartypeCheckMeta` dataclass instance as a hidden parameter to\n type-checking wrapper functions. Naturally, this instance encapsulates\n those `n` metadatum as instance variables. Naturally, I have no idea\n what I'm talking about. This is why coding and Friday nights is a\n volatile admixture at best.\n\nFrankly, it's best not to think too hard about any of this. (*Externalize the magnetic magma in a diegetic exegesis!*)","shortMessageHtmlLink":"@bearytype + __call__() + __wrapped__ x 4."}},{"before":"57c0f7bda72ac87ced525bd7140cf8d78764a4fa","after":"8ce81876c682263c8c8581fcc47c3056e1b7b0cb","ref":"refs/heads/main","pushedAt":"2024-04-27T07:13:54.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`@bearytype` + `__call__()` + `__wrapped__` x 3.\n\nThis commit is the next in a commit chain generalizing the `@beartype`\ndecorator to support **pseudo-callable wrapper objects** (i.e., objects\ndefining both the `__call__()` and `__wrapped__` dunder attributes),\nen-route to resolving feature request #368 kindly submitted by\n@danielward27 (Daniel Ward). Specifically, this commit improves the\ninternal extensibility of @beartype's dynamic code generator by\nrefactoring:\n\n* The current approach that laboriously passes `n` metadatum as hidden\n parameters to type-checking wrapper functions into...\n* A new approach that efficiently and trivially passes a single\n `BeartypeCheckMeta` dataclass instance as a hidden parameter to\n type-checking wrapper functions. Naturally, this instance encapsulates\n those `n` metadatum as instance variables. Naturally, I have no idea\n what I'm talking about. This is why coding and Friday nights is a\n volatile admixture at best.\n\nFrankly, it's best not to think too hard about any of this. (*Certainly certifiably friable!*)","shortMessageHtmlLink":"@bearytype + __call__() + __wrapped__ x 3."}},{"before":"b2303e04732d2267184d22e9c04242c1bc632168","after":"57c0f7bda72ac87ced525bd7140cf8d78764a4fa","ref":"refs/heads/main","pushedAt":"2024-04-26T07:03:56.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`@bearytype` + `__call__()` + `__wrapped__` x 2.\n\nThis commit is the next in a commit chain generalizing the `@beartype`\ndecorator to support **pseudo-callable wrapper objects** (i.e., objects\ndefining both the `__call__()` and `__wrapped__` dunder attributes),\nen-route to resolving feature request #368 kindly submitted by\n@danielward27 (Daniel Ward). Specifically, this commit further explores\nthe horrifying intricacies of the insane shambolic horror that is the\npseudo-callable C-based object dynamically created and returned by the\nthird-party `@jax.jit` decorator. Frankly, it's best not to think too\nhard about any of this.\n\nUnrelatedly, this commit also temporarily circumvents upstream issue\nactions/setup-python#852 by removing macOS as a support platform from\nour GitHub Actions-based continuous integration (CI) workflow. It is\nsad. (*Surely surly!*)","shortMessageHtmlLink":"@bearytype + __call__() + __wrapped__ x 2."}},{"before":"c35763f622a4b719185a153aa554c279d5e8623c","after":"b2303e04732d2267184d22e9c04242c1bc632168","ref":"refs/heads/main","pushedAt":"2024-04-25T08:06:31.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Decorator closures accepting only `*args`.\n\nThis commit resolves an unexpected incompatibility between the\n`@beartype` decorator and decorator closures accepting only positional\nvariadic arguments (i.e., `*args`), resolving issue #375 kindly\nsubmitted by bestest @beartype QA beastie @danielward27 (Daniel Ward).\nDoing so ensures that @beartype now properly type-checks decorator\nchains resembling:\n\n```python\nfrom beartype import beartype\nfrom functools import wraps\n\ndef my_decorator(fn):\n @wraps(fn)\n def wrapped(*args) -> int:\n return fn(*args)\n\n return wrapped\n\n@beartype\n@my_decorator\ndef my_func(a: int):\n return a\n```\n\n@beartype: *someday it will behave as expected.* (*Illegitimate elliptics, mate!*)","shortMessageHtmlLink":"Decorator closures accepting only *args."}},{"before":"c96584a043aaf3be855aa9c13fdffeeaa90fbf17","after":"c35763f622a4b719185a153aa554c279d5e8623c","ref":"refs/heads/main","pushedAt":"2024-04-24T07:50:21.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`@bearytype` + `__call__()` + `__wrapped__` x 1.\n\nThis commit is the first in a commit chain generalizing the `@beartype`\ndecorator to support **pseudo-callable wrapper objects** (i.e., objects\ndefining both the `__call__()` and `__wrapped__` dunder attributes),\nen-route to resolving feature request #368 kindly submitted by\n@danielward27 (Daniel Ward). Specifically, this commit generalizes\ninternal logic detecting and unwrapping **isomorphic wrappers** (i.e.,\ncallables whose signatures resemble `@wraps(...)\ndef isomorphic_wrapper(*args, **kwargs): ...`) to unwrap a different\ncallable object than the object detected for isomorphism. Frankly, it's\nbest not to think too hard about any of this. (*Uncallable carbuncle!*)","shortMessageHtmlLink":"@bearytype + __call__() + __wrapped__ x 1."}},{"before":"7e9eef4868f9c0a140ca7db973fbc17abb3a5702","after":"c96584a043aaf3be855aa9c13fdffeeaa90fbf17","ref":"refs/heads/main","pushedAt":"2024-04-21T07:24:53.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"**Beartype 0.18.6** started.","shortMessageHtmlLink":"**Beartype 0.18.6** started."}},{"before":"fe980799d35677a08d3f57d3cc0b3cce14d90711","after":"7e9eef4868f9c0a140ca7db973fbc17abb3a5702","ref":"refs/heads/main","pushedAt":"2024-04-21T07:19:18.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"Nested beartype validators.\n\nThis commit resolves a critical low-level issue in @beartype's dynamic\ntype-checking code generator for **nested beartype\nvalidator-in-container type hints** (e.g., type hints of the form\n`list[typing.Annotated[{type}, Is[{validator}]]]`), resolving issue #372\nkindly submitted by @ArneBachmann, fearless author of the peerless\nprogramming language [AWFUL (Arguably Worst F*cked-Up\nLanguage)](https://github.com/ArneBachmann/awful), which @leycec is\npromptly going to port the @beartype codebase to. Press F to doubt. The\naccursed @beartype 0.18.X release cycle continues to bedevil our world.\n(*Inchoate incoherence is the GOAT!*)","shortMessageHtmlLink":"Nested beartype validators."}},{"before":"fd0096a1a22201ec58b1b54b3a2bda3a5417f6e4","after":"fe980799d35677a08d3f57d3cc0b3cce14d90711","ref":"refs/heads/main","pushedAt":"2024-04-19T07:33:45.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"**Beartype 0.18.5** started.","shortMessageHtmlLink":"**Beartype 0.18.5** started."}},{"before":"8deda40b237b0100f512c3351fb193234c9ce628","after":"fd0096a1a22201ec58b1b54b3a2bda3a5417f6e4","ref":"refs/heads/main","pushedAt":"2024-04-19T07:26:40.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"leycec","name":"Cecil Curry","path":"/leycec","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/217028?s=80&v=4"},"commit":{"message":"`dict[tuple[...], ...]` type hints.\n\nThis commit resolves a critical low-level issue in @beartype's dynamic\ntype-checking code generator for **nested tuple-in-dictionary type\nhints** (i.e., type hints of the form `dict[tuple[...], ...]`),\nresolving issue #371 kindly submitted by that wascally typing wabbit\n@alisaifee (Ali-Akber Saifee). The accursed @beartype 0.18.X release\ncycle continues to bedevil our poor world. (*Flattened madness is no glad flattery!*)","shortMessageHtmlLink":"dict[tuple[...], ...] type hints."}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEXMhSsAA","startCursor":null,"endCursor":null}},"title":"Activity · beartype/beartype"}