This commit is the first in a titanic commit chain refactoring our
documentation from its current monolithic home in our top-level
`README.rst` file to its eventual modular home at [ReadTheDocs
(RTD)](https://beartype.readthedocs.io), en-route to resolving issue #8
(!) kindly submitted a literal lifetime ago by visionary computer vision
export and long-standing phenomenal Finn @felix-hilden (Felix Hildén).
Specifically, this commit refactors our top-level `sphinx` entry point
for sanity and resurrects our core Sphinx configuration from its early
grave -- which now actually builds nothing without raising errors. Is
this an accomplishment? In 2022, mere survival is an accomplishment!
So... **yes.** (*Innocuous incunabula!*)

This commit is the next in a titanic commit chain refactoring our
documentation from its current monolithic home in our top-level
`README.rst` file to its eventual modular home at [ReadTheDocs
(RTD)](https://beartype.readthedocs.io), en-route to resolving issue #8
(!) kindly submitted a literal lifetime ago by visionary computer vision
export and long-standing phenomenal Finn @felix-hilden (Felix Hildén).
Specifically, this commit:

* Refactors our top-level `sphinx` entry point to unconditionally
  disable Sphinx caching by forcing *all* target documentation files to
  be rebuilt regardless of whether their underlying source files have
  been since modified or not.
* Resolves a warning related to our `doc/source/404.rst` file by...
  temporarily moving that file aside. Look, we're not here to actually
  solve deep issues; we're here to just get documentation building,
  which it's not. Sphinx, you have much to answer for.

(*Dodecal tribal decal!*)

This commit is the next in a titanic commit chain refactoring our
documentation from its current monolithic home in our top-level
`README.rst` file to its eventual modular home at [ReadTheDocs
(RTD)](https://beartype.readthedocs.io), en-route to resolving issue #8
(!) kindly submitted a literal lifetime ago by visionary computer vision
export and long-standing phenomenal Finn @felix-hilden (Felix Hildén).
Specifically, I squandered the entire evening attempting to coerce
Sphinx's `autodoc` extension into resolving cross references to
anything. I failed utterly. `autodoc` refuses to resolve cross
references to even **standard pure-Python CPython modules that are both
guaranteed to exist and be trivially importable.** In short, `autodoc`
is Hell Incarnate. I am on the precipice of abandoning all hope of
`autodoc` ever behaving as expected. In a desperate eleventh-hour
attempt to reinstate sanity, I've posted a StackOverflow question on the
topic at:

    https://stackoverflow.com/questions/71626179/sphinx-autodoc-extension-unable-to-even-find-standard-modules-guaranteed-to-ex

Since I've wasted far too many scarce unpaid volunteer evenings on
wrestling with this insanity and now harbour profound doubts that anyone
will even be able to provide relevant advice, it's likely that @beartype
will be abandoning `autodoc` entirely. Instead, I'll just document our
public API manually. That's the opposite of ideal -- but I'll take
working of a non-working ideal. Thanks for wasting weeks, `autodoc`.
(*Syrupy uructations of fructose!*)

This commit is the next in a titanic commit chain refactoring our
documentation from its current monolithic home in our top-level
`README.rst` file to its eventual modular home at [ReadTheDocs
(RTD)](https://beartype.readthedocs.io), en-route to resolving issue #8
(!) kindly submitted a literal lifetime ago by visionary computer vision
export and long-standing phenomenal Finn @felix-hilden (Felix Hildén).
Specifically, this commit activates and configures the effectively
mandatory `autosectionlabels` builtin Sphinx extension. (*Empirical umpire!*)

This minor release unleashes a major firestorm of support for **class
decoration,** **colourful exceptions,** **pyright + PyLance + VSCode,**
[PEP 484][PEP 484], [PEP 544][PEP 544], [PEP 561][PEP 561],
[PEP 563][PEP 563], [PEP 585][PEP 585], [PEP 604][PEP 604],
[PEP 612][PEP 612], and [PEP 647][PEP 647].

This minor release resolves a mammoth **29 issues** and merges **12 pull
requests.** Noteworthy changes include:

## Compatibility Improved

* **Class decoration.** The `@beartype` decorator now decorates both
  higher-level classes *and* lower-level callables (i.e., functions,
  methods), resolving feature request #152 kindly submitted by @posita
  the positively sublime. All possible edge cases are supported,
  including:
  * Classes defining methods decorated by builtin decorators: i.e.,
    * Class methods via `@classmethod`.
    * Static methods via `@staticmethod`.
    * Property getters, setters, and deleters via `@property`.
  * Arbitrarily deeply nested (i.e., inner) classes.
  * Arbitrarily deeply nested (i.e., inner) classes whose type hints are
    postponed under [PEP 563][PEP 563].
  Since this was surprisingly trivial, @leycec
  probably should have done this a few years ago. He didn't. This is why
  he laments into his oatmeal in late 2022.
* **[PEP 484][PEP 484]- and [PEP 585][PEP 585]-compliant nested
  generics.** @beartype now supports arbitrarily complex [PEP 484][PEP
  484]- and [PEP 585][PEP 585]-compliant inheritance trees subclassing
  non-trivial combinations of the `typing.Generic` superclass and other
  `typing` pseudo-superclasses, resolving issue #140 kindly submitted by
  @langfield (William Blake – yes, *that* William Blake). Notably,
  this release extricated our transitive visitation of the tree of all
  pseudo-superclasses of any PEP 484- and 585-compliant generic type
  hint (*...don't ask*) from its prior hidden sacred cave deep within
  the private `beartype._decor._code._pep._pephint` submodule into a new
  reusable `iter_hint_pep484585_generic_bases_unerased_tree()`
  generator, which is now believed to be the most fully-compliant
  algorithm for traversing generic inheritance trees at runtime. This
  cleanly resolved all lingering issues surrounding generics,
  dramatically reduced the likelihood of more issues surrounding
  generics, and streamlined the resolution of any more issues
  surrounding generics should they arise... *which they won't.*
  Generics: we have resoundingly beaten you. Stay down, please.
* **[PEP 544][PEP 544] compatibility.** @beartype now supports
  arbitrarily complex [PEP 544][PEP 544]-compliant inheritance trees
  subclassing non-trivial combinations of the `typing.Protocol` +
  `abc.ABC` superclasses, resolving #117 kindly submitted by
  too-entertaining pun master @twoertwein (Torsten Wörtwein).
  Notably, `@beartype` now:
  * Correctly detects non-protocols as non-protocols. Previously,
    @beartype erroneously detected a subset of non-protocols as
    PEP 544-compliant protocols. It's best not to ask why.
  * Ignores both the unsubscripted `beartype.typing.Protocol` superclass
    *and* parametrizations of that superclass by one or more type
    variables (e.g., `beartype.typing.Protocol[typing.TypeVar('T')]`) as
    semantically meaningless in accordance with similar treatment of the
    `typing.Protocol` superclass.
  * Permits caller-defined abstract protocols subclassing our caching
    `beartype.typing.Protocol` superclass to themselves be subclassed by
    one or more concrete subclasses. Previously, attempting to do so
    would raise non-human-readable exceptions from the `typing` module;
    now, doing so behaves as expected.
  * Relaxed our prior bad assumption that the second-to-last superclass
    of all generics – and thus protocols – is the `typing.Generic`
    superclass. That assumption *only* holds for standard generics and
    protocols; non-standard protocols subclassing non-`typing`
    superclasses (e.g., the `abc.ABC` superclass) *after* the list
    `typing` superclass in their method resolution order (MRO)
    flagrantly violate this assumption. Well, that's fine. We're fine
    with that. What's not fine about that? **Fine. This is fine.**
  * Avoids a circular import dependency. Previously, our caching
    `beartype.typing.Protocol` superclass leveraged the general-purpose
    `@beartype._util.cache.utilcachecall.callable_cached decorator` to
    memoize its subscription; however, since that decorator transitively
    imports from the `beartype.typing` subpackage, doing so induced a
    circular import dependency. To circumvent this, a new
    `@beartype.typing._typingcache.callable_cached_minimal` decorator
    implementing only the minimal subset of the full
    `@beartype._util.cache.utilcachecall.callable_cached` decorator has
    been defined; the `beartype.typing` subpackage now safely defers to
    this minimal variant for all its caching needs.
* **[PEP 563][PEP 563] compatibility.** @beartype now resolves [PEP
  563][PEP 563]-postponed **self-referential type hints** (i.e., type
  hints circularly referring to the class currently being decorated).
  **Caveat:** this support requires that external callers decorate the
  *class* being referred to (rather than the *method* doing the
  referring) by the `@beartype` decorator. For this and similar reasons,
  users are advised to begin refactoring their object-oriented codebases
  to decorate their *classes* rather than *methods* with `@beartype`.
* **[PEP 612][PEP 612] partial shallow compatibility.** @beartype now
  shallowly detects [PEP 612][PEP 612]-compliant `typing.ParamSpec`
  objects by internally associating such objects with our
  `beartype._data.hint.pep.sign.datapepsigns.HintSignParamSpec`
  singleton, enabling @beartype to portably introspect
  `Callable[typing.ParamSpec(...), ...]` type hints.
* **Static type-checking.** @beartype is now substantially more
  compliant with static type-checkers, including:
  * **Microsoft [pyright](https://github.com/microsoft/pyright) +
    [PyLance](https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-pylance)
    + [VSCode](https://visualstudio.com).** @beartype now officially
    supports pyright, Microsoft's in-house static type-checker oddly
    implemented in pure-TypeScript, <sup>*gulp*</sup> resolving issues
    #126 and #127 kindly submitted by fellow Zelda aficionado @rbroderi.
    Specifically, this release resolves several hundred false warnings
    and errors issued by pyright against the @beartype codebase. It is,
    indeed, dangerous to go alone – but we did it anyway.
  * **mypy `beartype.typing.Protocol` compatibility.** The
    @beartype-specific `beartype.typing.Protocol` superclass implementing
    [PEP 544][PEP 544]-compliant fast caching protocols is now fully
    compatible with mypy, Python's official static type-checker.
    Specifically, `beartype.typing.Protocol` now circumvents:
    * python/mypy#11013 by explicitly annotating the type of its
      `__slots__` as `Any`.
    * python/mypy#9282 by explicitly setting the `typing.TypeVar()`
      `bounds` parameter to this superclass.
* **[PEP 647][PEP 647] compatibility.** @beartype now supports
  arbitrarily complex **[type
  narrowing](https://mypy.readthedocs.io/en/latest/type_narrowing.html)**
  in [PEP 647][PEP 647]-compliant static type-checkers (e.g., mypy,
  pyright), resolving issues #164 and #165 kindly submitted in parallel
  by foxy machine learning gurus @justinchuby (Justin Chuby) and @rsokl
  (Ryan Soklaski). Thanks to their earnest dedication, @beartype is now
  believed to be the most fully complete type narrower. Specifically,
  the return of both the `beartype.door.is_bearable()` function and
  corresponding `beartype.door.TypeHint.is_bearable()` method are now
  annotated by the [PEP 647][PEP 647]-compliant `typing.TypeGuard[...]`
  type hint under both Python ≥ 3.10 *and* Python < 3.10 when the
  optional third-party `typing_extensions` dependency is installed.
  Doing so substantially reduces false positives from static type
  checkers on downstream codebases deferring to these callables.
  Thanks so much for improving @beartype so much, @justinchuby and
  @rsokl!
* **`@{classmethod,staticmethod,property}` chaining.** The `@beartype`
  decorator now implicitly supports callables decorated by both
  `@beartype` *and* one of the builtin method decorators `@classmethod`,
  `@staticmethod`, or `@property` regardless of decoration order,
  resolving issue #80 kindly requested by @qiujiangkun (AKA, Type
  Genius-kun). Previously, `@beartype` explicitly raised an exception
  when ordered *after* one of those builtin method decorators. This
  releseae relaxes this constraint, enabling callers to list `@beartype`
  either before or after one of those builtin method decorators.
* **`beartype.vale.Is[...]` integration.** Functional validators (i.e.,
  `beartype.vale.Is[...]`) now integrate more cleanly with the remainder
  of the Python ecosystem, including:
  * **IPython.** Functional validators localized to a sufficiently
    intelligent REPL (e.g., IPython) that caches locally defined
    callables to the standard `linecache` module now raise
    human-readable errors on type-checking, resolving issue #123 kindly
    submitted by typing brain-child @braniii. Relatedly, @beartype now
    permissively accepts both physical on-disk files and dynamic
    in-memory fake files cached with `linecache` as the files defining
    an arbitrary callable.
  * **NumPy,** which publishes various **bool-like tester functions**
    (i.e., functions returning a non-`bool` object whose class defines
    at least one of the `__bool__()` or `__len__()` dunder methods and
    is thus implicitly convertible into a `bool`). Functional validators
    now support subscription by these functions, resolving issue #153
    kindly submitted by molecular luminary @braniii (Daniel Nagel).
    Specifically, @beartype now unconditionally wraps *all* tester
    callables subscripting (indexing) `beartype.vale.Is` with a new
    private `_is_valid_bool()` closure that (in order):
    1. Detects when those tester callables return bool-like objects.
    2. Coerces those objects into corresponding `bool` values.
    3. Returns those `bool` values instead.
* **Moar fake builtin types.**@beartype now detects all known **fake
  builtin types** (i.e., C-based types falsely advertising themselves as
  being builtin and thus *not* require explicit importation), succinctly
  resolving issue #158 kindly submitted by the decorous typing gentleman
  @langfield. Specifically, @beartype now recognizes instances of all of
  the following as fake builtin types:
  * `beartype.cave.AsyncCoroutineCType`.
  * `beartype.cave.AsyncGeneratorCType`.
  * `beartype.cave.CallableCodeObjectType`.
  * `beartype.cave.CallableFrameType`.
  * `beartype.cave.ClassDictType`.
  * `beartype.cave.ClassType`.
  * `beartype.cave.ClosureVarCellType`.
  * `beartype.cave.EllipsisType`.
  * `beartype.cave.ExceptionTracebackType`.
  * `beartype.cave.FunctionType`.
  * `beartype.cave.FunctionOrMethodCType`.
  * `beartype.cave.GeneratorCType`.
  * `beartype.cave.MethodBoundInstanceDunderCType`.
  * `beartype.cave.MethodBoundInstanceOrClassType`.
  * `beartype.cave.MethodDecoratorBuiltinTypes`.
  * `beartype.cave.MethodUnboundClassCType`.
  * `beartype.cave.MethodUnboundInstanceDunderCType`.
  * `beartype.cave.MethodUnboundInstanceNondunderCType`.
  * `beartype.cave.MethodUnboundPropertyNontrivialCExtensionType`.
  * `beartype.cave.MethodUnboundPropertyTrivialCExtensionType`.

## Compatibility Broken

* **Python 3.6.x support dropped.** This release unilaterally drops
  support for the Python 3.6.x series, which somnambulantly collided
  with its End-of-Life (EOL) a year ago and now constitutes a compelling
  security risk. Doing so substantially streamlines the codebase, whose
  support for Python 3.6.x required an unmaintainable writhing nest of
  wicked corner cases. We all now breathe a sigh of contentment in the
  temporary stillness of morning.
* **`beartype.cave` deprecation removals.** This release removes all
  deprecated third-party attributes from the `beartype.cave` submodule.
  The continued existence of these attributes substantially increased
  the cost of importing *anything* from our mostly undocumented
  `beartype.cave` submodule, rendering that submodule even less useful
  than it already is. Specifically, this release removes these
  previously deprecated attributes:
  * `beartype.cave.NumpyArrayType`.
  * `beartype.cave.NumpyScalarType`.
  * `beartype.cave.SequenceOrNumpyArrayTypes`.
  * `beartype.cave.SequenceMutableOrNumpyArrayTypes`.
  * `beartype.cave.SetuptoolsVersionTypes`.
  * `beartype.cave.VersionComparableTypes`.
  * `beartype.cave.VersionTypes`.

## Exceptions Improved

* **Colour** – the sensation formerly known as "color." @beartype now
  emits colourized type-checking violations (i.e.,
  `beartype.roar.BeartypeCallHintViolation` exceptions) raised by both
  `@beartype`-decorated callables *and* statement-level type-checkers
  (e.g., `beartype.door.die_if_unbearable()`,
  `beartype.door.TypeHint.die_if_unbearable()`), resolving issue #161
  kindly submitted by foxy machine learning expert @justinchuby (Justin
  Chu). When standard output is attached to an interactive terminal
  (TTY), ANSII-flavoured colours now syntactically highlight various
  substrings of those violations for improved visibility, readability,
  and debuggability. Since *all* actively maintained versions of Windows
  (i.e., Windows ≥ 10) now widely support ANSII escape sequences across
  both Microsoft-managed terminals (e.g., Windows Terminal) and
  Microsoft-managed Integrated Development Environments (IDEs) (e.g.,
  VSCode), this supports extends to Windows as well. The bad old days of
  non-standard behaviour are behind us all. Thanks *so* much to
  @justinchuby for his immense contribution to the righteous cause of
  eye-pleasing user experience (UX)!
* **Types disambiguated.** @beartype now explicitly disambiguates the
  types of parameters and returns that violate type-checking in
  exception messages raised by the `@beartype` decorator, resolving
  issue #124 kindly submitted by typing brain-child @braniii. Thus was
  justice restored to the QAverse.
* **Stack frame squelched.** @beartype now intentionally squelches
  (i.e., hides) the ignorable stack frame encapsulating the call to our
  private `beartype._decor._error.errormain.get_beartype_violation()`
  getter from the parent type-checking wrapper function generated by the
  :mod:`beartype.beartype` decorator, resolving issue #140 kindly
  submitted by @langfield (William Blake – yes, *that* William Blake).
  That stack frame only needlessly complicated visual inspection of
  type-checking violations in tracebacks – especially from testing
  frameworks like :mod:`pytest` that recapitulate the full definition of
  the `get_beartype_violation()` getter (including verbose docstring) in
  those tracebacks. Specifically, this release:
  * Renamed the poorly named `raise_pep_call_exception()` function to
    `get_beartype_violation()` for clarity.
  * Refactored `get_beartype_violation()` to return rather than raise
    `BeartypeCallHintViolation` exceptions (while still raising all
    other types of unexpected exceptions for robustness).
  * Refactored type-checking wrapper functions to directly raise the
    exception returned by calling `get_beartype_violation()`.
* **``None`` type.** The type of the ``None`` singleton is no longer
  erroneously labelled as a PEP 544-compliant protocol in type-checking
  violations. Let's pretend that never happened.
* **`beartype.abby.die_if_unbearable()` violations.** The
  `beartype.abby.die_if_unbearable()` validator function no longer
  raises non-human-readable exception messages prefixed by the
  unexpected substring `"@beartyped
  beartype.abby._abbytest._get_type_checker._die_if_unbearable()
  return"`. "Surely that never happened, @beartype!"

## Features Added

* **`beartype.door.** @beartype now provides a new public framework for
  introspecting, sorting, and type-checking type hints at runtime in
  constant time. N-n-now... hear me out here. @leycec came up with a
  ludicrous acronym and we're going to have to learn to live with it:
  the **D**ecidedly **O**bject-**O**rientedly **R**ecursive (DOOR) API.
  Or, `beartype.door` for short. Open the door to a whole new
  type-hinting world, everyone. `beartype.door` enables type hint
  arithmetic via an object-oriented type hint class hierarchy
  encapsulating the crude non-object-oriented type hint declarative API
  standardized by the :mod:`typing` module, resolving issues #133 and
  #138 kindly submitted by Harvard microscopist and general genius
  @tlambert03. The new `beartype.door` subpackage defines a public:
  * `TypeHint({type_hint})` superclass, enabling rich comparisons
    between pairs of arbitrary type hints. Altogether, this class
    implements a partial ordering over the countably infinite set of all
    type hints. Pedagogical excitement ensues. Instances of this class
    efficiently satisfy both the `collections.abc.Sequence` and
    `collections.abc.FrozenSet` abstract base classes (ABC) and thus
    behave just like tuples and frozen sets over child type hints.
    Public attributes defined by this class include:
    * A pair of `die_if_unbearable()` and `is_bearable()` runtime
      type-checking methods, analogous in behaviour to the existing
      `beartype.abby.die_if_unbearable()` and
      `beartype.abby.is_bearable()` runtime type-checking functions.
    * `TypeHint.is_bearable()`, currently implemented in terms of the
      procedural `beartype.abby.is_bearable()` tester.
    * An `is_ignorable` property evaluating to `True` only if the
      current type hint is semantically ignorable (e.g., `object`,
      `typing.Any`). There exist a countably infinite number of
      semantically ignorable type hints. The more you know, the less you
      want to read this changeset.
    * The equality comparison operator (e.g., `==`), enabling type hints
      to be compared according to semantic equivalence.
    * Rich comparison operators (e.g., `<=`, `>`), enabling type hints
      to be compared and sorted according to semantic narrowing.
    * A sane `__bool__()` dunder method, enabling type hint wrappers to
      be trivially evaluated as booleans according to the child type
      hints subscripting the wrapped type hints.
    * A sane `__len__()` dunder method, enabling type hint wrappers to
      be trivially sized according to the child type hints subscripting
      the wrapped type hints.
    * A sane `__contains__()` dunder method, enabling type hint wrappers
      to be tested for child type hint membership – just like builtin
      sets, frozen sets, and dictionaries.
    * A sane `__getindex__()` dunder method, enabling type hint wrappers
      to be subscripted by both positive and negative indices as well as
      slices of such indices – just like builtin tuples.
  * `beartype.door.AnnotatedTypeHint` subclass.
  * `beartype.door.CallableTypeHint` subclass.
  * `beartype.door.LiteralTypeHint` subclass.
  * `beartype.door.NewTypeTypeHint` subclass.
  * `beartype.door.TupleTypeHint` subclass.
  * `beartype.door.TypeVarTypeHint` subclass.
  * `beartype.door.UnionTypeHint` subclass.
  * `is_subtype({type_hint_a}, {type_hint_b})` function, enabling
    @beartype users to decide whether any type hint is a **subtype**
    (i.e., narrower type hint) of any other type hint.
  * `beartype.roar.BeartypeDoorNonpepException` type, raised when the
    `beartype.door.TypeHint` constructor is passed an object that is
    *not* a PEP-compliant type hint currently supported by the DOOR API.
  Thanks so much to @tlambert03 for his phenomenal work here. He ran
  GitHub's PR gauntlet so that you did not have to. Praise be to him.
  Some people are the living embodiment of quality. @tlambert03 is one
  such people.
* **`beartype.peps`.** @beartype now publicizes runtime support for
  `typing`-centric Python Enhancement Proposals (PEPs) that currently
  lack official runtime support via a new public subpackage:
  `beartype.peps`. Notably, @beartype now provides:
  . Specifically, this commit:
  * A new public `beartype.peps.resolve_pep563()` function resolving
    [PEP 563][PEP 563]-postponed type hints on behalf of third-party
    Python packages. This function is intended to be "the final word" on
    runtime resolution of [PEP 563][PEP 563]. May no other third-party
    package suffer as we have suffered. This commit is for you,
    everyone. And "by everyone," we of course mostly mean @wesselb of
    [Plum](github.com/wesselb/plum) fame. See also beartype/plum#53.
* **`beartype.vale.Is*[...] {&,|}` short-circuiting.** `&`- and
  `|`-chained beartype validators now explicitly short-circuit when
  raising human-readable exceptions from type-checking violations
  against those validators, resolving issue #125 kindly submitted by
  typing brain-child @braniii.

## Features Optimized

* **`beartype.abby.is_bearable()` when returning `False`.** Previously,
  the public `beartype.abby.is_bearable()` runtime type-checker behaved
  reasonably optimally when the passed object satisfied the passed type
  hint but *extremely* suboptimally when that object violated that hint;
  this was due to our current naive implementation of that tester using
  the standard Easier to Ask for Permission than Forgiveness (EAFP)
  approach. This release fundamentally refactored
  `beartype.abby.is_bearable()` in terms of our new private
  `beartype._check.checkmake.make_func_tester()` type-checking tester
  function factory function. Ad-hoc profiling shows a speedup on
  the order of eight orders of magnitude – the single most intense
  optimization @beartype has ever brought to bear (*heh*). Our core code
  generation API now transparently generates both:
  * **Runtime type-checking testers** (i.e., functions merely returning
    ``False`` on type-checking violations).
  * **Runtime type-checking validators** (i.e., functions raising
    exceptions on type-checking violations).
* **[PEP 604][PEP 604]-compliant new unions** (e.g., `int | str |
  None`). Since these unions are **non-self-caching type hints** (i.e.,
  hints that do *not* implicitly cache themselves to reduce space and
  time consumption), @beartype now efficiently coerces these unions into
  singletons in the same manner as [PEP 585][PEP 585]-compliant type
  hints – which are similarly non-self-caching.

## Features Deprecated

* **`beartype.abby` → `beartype.door`.** This release officially
  deprecates the poorly named `beartype.abby` subpackage in favour of
  the sorta less poorly named `beartype.door` subpackage, whose name
  actually means something – even if that something is a punny acronym
  no one will ever find funny. Specifically:
  * `beartype.abby.die_if_unbearable()` has been moved to
    `beartype.door.die_if_unbearable()`.
  * `beartype.abby.is_bearable()` has been moved to
    `beartype.door.is_bearable()`.
  To preserve backward compatibility, the `beartype.abby` subpackage
  continues to dynamically exist (and thus be importable from) – albeit
  as a deprecated alias of the `beartype.door` subpackage.

## Deprecations Resolved

* **Setuptools licensing.** This release resolves a mostly negligible
  `setuptools` deprecation warning concerning the deprecated
  `license_file` setting in the top-level `setup.cfg` file. *Next!*

## Tests Improved

* **[PEP 544][PEP 544] compatibility.** All [PEP 544][PEP 544]-specific
  test type hints have been generalized to apply to both the non-caching
  `typing.Protocol` superclass *and* our caching
  `beartype.typing.Protocol` superclass.
* **[PEP 561][PEP 561] compatibility via pyright.** Our test suite now
  enforces static type-checking with `pyright`. Notably:
  * A new `test_pep561_pyright` functional test statically type-checks
    the @beartype codebase against the external `pyright` command in the
    current `${PATH}` (if available) specific to the version of the
    active Python interpreter currently being tested. For personal
    sanity, this test is currently ignored on remote continuous
    integration (CI) workflows. Let this shrieking demon finally die!
  * The private `beartype_test.util.cmd.pytcmdrun` submodule underlying
    our cross-platform portable forking of testing subprocesses now
    transparently supports vanilla Windows shells (e.g., `CMD.exe`,
    PowerShell).
* **Tarball compatibility.** `beartype` may now be fully tested from
  non-`git` repositories, including source tarballs containing the
  `beartype_test` package. Previously, three functional tests making
  inappropriate assumptions about the existence of a top-level `.git/`
  directory failed when exercised from a source tarball.
* **Sphinx documentation.** Our test suite now exercises that our
  documentation successfully builds with Sphinx via a new
  `test_sphinx_build()` functional test. This was surprisingly
  non-trivial – thanks to the `pytest`-specific `sphinx.testing`
  subpackage being mostly undocumented, behaving non-orthogonally, and
  suffering a host of unresolved issues that required we monkey-patch
  the core `pathlib.Path` class. Insanity, thy name is Sphinx.
* **GitHub Actions dependencies bumped.** This release bumps our GitHub
  Actions-based continuous integration (CI) workflows to both the
  recently released `checkout@v3` and `setup-python@v3` actions,
  inspired by a pair of sadly closed PRs by @RotekHandelsGmbH CTO
  @bitranox (Robert Nowotny). Thanks so much for the great idea,
  @bitranox!
* **`beartype.door` conformance.** A new smoke test guarantees
  conformance between our DOOR API and abstract base classes (ABCs)
  published by the standard `typing` module.
* **python/mypy#13627 circumvention.** This release pins our GitHub
  Actions-based CI workflow to Python 3.10.6 rather than 3.10.7,
  resolving a mypy-specific complaint inducing spurious test failures.

## Documentation Improved

* **[`beartype.abby`
  documented](https://github.com/beartype/beartype#beartype-at-any-time-api).**
  The new "Beartype At Any Time API" subsection of our front-facing
  `README.rst` file now documents our public `beartype.abby` API,
  resolving issue #139 kindly submitted by @gelatinouscube42 (i.e., the
  user whose username is the answer to the question: "What is the
  meaning of collagen sustainably harvested from animal body parts?").
* **[GitHub Sponsors activated](https://github.com/sponsors/leycec).**
  @beartype is now proudly financially supported by **GitHub Sponsors.**
  Specifically, this release:
  * Defines a new GitHub-specific funding configuration (i.e.,
    `.github/FUNDING.yml`).
  * Injects a hopefully non-intrusive advertising template
    <sup>*gulp*</sup> at the head of our `README.rst` documentation.
* **Sphinx configuration sanitized.** As the first tentative step
  towards chain refactoring our documentation from its current
  monolithic home in our top-level `README.rst` file to its eventual
  modular home at [ReadTheDocs (RTD)](https://beartype.readthedocs.io),
  en-route to resolving issue #8 (!) kindly submitted a literal lifetime
  ago by visionary computer vision export and long-standing phenomenal
  Finn @felix-hilden (Felix Hildén):
  * Our core Sphinx configuration has been resurrected from its early
    grave – which now actually builds nothing without raising errors. Is
    this an accomplishment? In 2022, mere survival is an accomplishment!
    So... *yes.* Significant improvements include:
    * Activation and configuration of the effectively mandatory
      `autosectionlabels` builtin Sphinx extension.
  * Our `doc/source/404.rst` file has been temporarily moved aside,
    resolving a non-fatal warning pertaining to that file. Look, we're
    not here to actually solve deep issues; we're here to just get
    documentation building, which it's not. Sphinx, you have much to
    answer for.
  * Our top-level `sphinx` entry point now:
    * Temporarily disables Sphinx's nit-picky mode (i.e., the `-n`
      option previously passed to `sphinx-build`) due to Sphinx's
      `autodoc` extension locally failing to generate working
      references.
    * Unconditionally disables Sphinx caching by forcing *all* target
      documentation files to be rebuilt regardless of whether their
      underlying source files have since been modified or not, obviating
      spurious build issues.

  [PEP 484]: https://www.python.org/dev/peps/pep-0484/
  [PEP 544]: https://www.python.org/dev/peps/pep-0544/
  [PEP 561]: https://www.python.org/dev/peps/pep-0561/
  [PEP 563]: https://www.python.org/dev/peps/pep-0563/
  [PEP 585]: https://www.python.org/dev/peps/pep-0585/
  [PEP 604]: https://www.python.org/dev/peps/pep-0604/
  [PEP 612]: https://www.python.org/dev/peps/pep-0612/
  [PEP 647]: https://www.python.org/dev/peps/pep-0647/

(*Impossible journey on an implacable placard-studded gurney!*)

This commit is the first in a commit chain reconfiguring Sphinx of what
will hopefully be the final nail in the lackluster coffin that is our
Sphinx configuration, en-route to resolving issue #8 (!) kindly
submitted a literal lifetime ago by visionary computer vision export and
long-standing phenomenal Finn @felix-hilden (Felix Hildén).
Specifically, this commit:

* Switches from the default Read The Docs (RTD) Sphinx theme to the
  third-party Furo theme. We selected this theme according to mostly
  objective (albeit ultimately subjective) heuristic criteria. In
  descending order of importance, we selected the theme with:
  1. The most frequent git commit history.
  2. The open issues and pull requests (PRs).
  3. The most GitHub stars as a crude proxy for aggregate rating.
  Furo handily bested all other themes across all three criteria. Furo
  is very well-maintained, frequently closes out open issues and merges
  open PRs, and sports the highest quantity of GitHub stars by an
  overwhelming margin.
* Enables the builtin `intersphinx` extension, enabling attributes
  defined by the standard library (e.g., the `typing` module, the
  `types.GenericAlias` type) to be cross-referenced as a fallback when
  *not* already defined by this project.
* Reconfigured RTD through our top-level `.readthedocs.yml`
  configuration to:
  * Build under the most recent Long Term Service (LTS) release of
    Ubuntu.
  * Build under the most recently released minor version of CPython.
  * Configure Sphinx via our `doc/source/conf.py` script.

(*Availing a hungry pungency prevails!*)

This commit is the next in a commit chain reconfiguring Sphinx of what
will hopefully be the final nail in the lackluster coffin that is our
Sphinx configuration, en-route to resolving issue #8 (!) kindly
submitted a literal lifetime ago by visionary computer vision export and
long-standing phenomenal Finn @felix-hilden (Felix Hildén).
Specifically, this commit:

* Substantially improved the robustness of our Sphinx configuration
  (i.e., `doc/src/conf.py`), which now intelligently detects
  documentation paths via the standard `pathlib.Path` API.
* Successfully transitions from Sphinx's builtin `autodoc` and
  `autosummary` extensions to Read The Doc (RTD)'s  third-party
  `autoapi`, which behaves substantially saner – as evidenced by
  @beartype successfully performing this transition in a single commit.
* Successfully generated `doc/src/_links.rst`, a **URI repository**
  (i.e., hidden reStructuredText (reST) document centralizing common URI
  links in reST format, automatically exposed to all other reST
  documents in this project via the `rst_epilog` setting in `conf.py`).
* Removed a medley of obsolete reST (and mostly empty) documents.

(*Enabled gables gab about incredibly inedible grab-bags!*)

This commit is the next in a commit chain reconfiguring Sphinx of what
will hopefully be the final nail in the lackluster coffin that is our
Sphinx configuration, en-route to resolving issue #8 (!) kindly
submitted a literal lifetime ago by visionary computer vision export and
long-standing phenomenal Finn @felix-hilden (Felix Hildén).
Specifically, this commit ruthlessly circumvents the upstream
sphinx-doc/sphinx#4961 issue causing Sphinx to emit literally hundreds
of ignorable warnings resembling ``"WARNING: more than one target found
for cross-reference 'TypeHint': beartype.door._doorcls.TypeHint,
beartype.door.TypeHint"`` with a [trivial circumvention shamelessly
pilfered from
@RDFLib](https://github.com/RDFLib/rdflib/blob/3a418218d6bcdb46f78342e14c024063e2f53e71/docs/conf.py#L255).
(*Unacceptable scepter of powdered pewter!*)

This minor release expands the infinitely vast (yet mostly empty) universe of
@beartype into the hitherto uncharted realms of **configuration,** **exception
identification,** **Nuitka,** **`typing.NamedTuple`,** and **Python 3.11.**
Also, other things were done. We swear it!

This minor release resolves **16 issues** and merges **2 pull requests.**
Noteworthy changes include:

## Compatibility Improved.

* **Python 3.11.** This is the first @beartype support to officially support the
  recently released Python 3.11. Notably, this release:
  * Synchronizes our public `beartype.typing` subpackage against upstream
    changes in the standard `typing` module introduced in Python 3.11.
  * Supports PEP-compliant type hints subscripted by the empty tuple (e.g.,
    `typing.Tuple[()]`), whose low-level implementation fundamentally changed
    under Python 3.11.
  * Updates our GitHub Actions-based continuous integration (CI) workflow to
    exercise @beartype against Python 3.11.
* **Nuitka.** This is the first @beartype release to officially support Nuitka
  (i.e., the increasingly popular Python compiler that stuns us all), resolving
  feature request #197 kindly submitted by @shenwpo (also known as the giant
  flaming metallic letter e). This includes a new `test_nuitka()` integration
  test showing that Nuitka successfully compiles a minimal-length example (MLE)
  runtime type-checked by @beartype.
* **`typing.NamedTuple`.** This release adds support for deeply type-checking
  subclasses of the PEP 484-compliant `typing.NamedTuple` superclass.
  Specifically, this release improves the resiliency of our PEP 563 resolution
  mechanism (i.e., the public `beartype.peps.resolve_pep563()` function) against
  callables whose `__module__` dunder attributes lie. This includes *all*
  `typing.NamedTuple` subclasses, which synthesize callables whose `__module__`
  dunder attributes erroneously claim to reside in the non-existent
  `"namedtuple_Foo"` module. Doing so resolves issue #181 kindly submitted by
  probably ingenious "Probabilistic Machine Learning" author @murphyk (Kevin P.
  Murphy).

## Features Added

* **Beartype configuration API.** This release publishes a new public API for
  externally configuring @beartype via the now-official `beartype.BeartypeConf`
  type and `beartype.BeartypeStrategy` enumeration. Specifically, this release
  adds:
  * **`beartype.BeartypeConf.is_color`,** a new tri-state boolean enabling end
    users to control how and whether beartype colours **type-checking
    violations** (i.e., :class:`beartype.roar.BeartypeCallHintViolation`
    exceptions) with POSIX-compliant ANSI escape sequences for readability,
    resolving issue #178 kindly submitted by the foxy ZeroGuard and River
    Oakfield founder @foxx (Cal Leeming). Rejoice, typing acolytes, for you have
    now been freed from the prismatic shackles of the rainbow!
  * **`beartype.BeartypeConf.is_pep484_tower`**, a new standard boolean enabling
    end users to control whether @beartype supports the [implicit numeric tower
    standardized by PEP
    484](https://peps.python.org/pep-0484/#the-numeric-tower) or not, resolving
    issue #174 kindly submitted by dashing French Canadian @felixchenier (Félix
    Chénier).
  * **`beartype.BeartypeStrategy.O0`**, a new **no-time strategy** (i.e.,
    beartype configuration option generalizing the standard
    `@typing.no_type_check` decorator). Enabling this strategy instructs the
    `@beartype` decorator to recall and preserve previously applied no-time
    strategies; internally, `@beartype` detects and reduces configurations
    resembling `conf=BeartypeConf(strategy=BeartypeStrategy.O0, ...)` to the
    `@typing.no_type_check` decorator. Users may now blacklist specific
    callables from being type-checked by configuring this strategy as documented
    in our front-facing `README.rst` documentation... *somewhere.* It's in there
    somewhere, people.
* **Beartype exception API.** This release publishes a new public API for
  externally identifying the cause of **type-checking violations** (i.e.,
  instances of the `beartype.roar.BeartypeCallHintViolation` exception
  class) raised by @beartype. These exceptions now publicly expose the
  user-defined objects responsible for those violations via a new
  `BeartypeCallHintViolation.culprits` property, resolving feature request #180
  kindly submitted by @Jasha10 the Supremely Patient and Understanding
  GitHubber. For safety, this property dynamically returns a non-empty tuple of
  the one or more responsible culprits defined as either:
  * For each culprit that supports weak references and is still alive (i.e., has
    yet to be garbage-collected), that culprit as is.
  * Else, the machine-readable string representation of that culprit truncated
    to a reasonable number of characters.

## Features Deprecated

* **`beartype.roar.BeartypeAbby*Exception`.** This release deprecates all
  lingering remnants of the prior `beartype.abby` subpackage – including:
  * `beartype.roar.BeartypeAbbyException`, supplanted by
    `beartype.roar.BeartypeDoorException`.
  * `beartype.roar.BeartypeAbbyHintViolation`, supplanted by
    `beartype.roar.BeartypeDoorHintViolation`.
  * `beartype.roar.BeartypeAbbyTesterException`, supplanted by
    `beartype.roar.BeartypeDoorException`.

## Static Type-checking Improved

* **@beartype exports.** This release terminally pacifies:
  * Mypy by publicizing all exported attributes from the top-level
    `beartype` package via a new `beartype.__all__` dunder attribute. Thanks to
    the stylishly pink-haired @pinkwah (Zohar Malamant) for the rapid pull
    request (PR).
  * `pyright` by explicitly re-exporting all public attributes of the top-level
    `beartype` package, resolving issue #169 kindly submitted by MIT AI
    mastermind @rsokl (Ryan Soklaski).
* **Continuous integration (CI).** This release integrates our GitHub
  Actions-based continuous integration (CI) workflow (i.e.,
  `.github/workflows/python_test.yml`) with third-party GitHub Actions
  statically type-checking beartype against both `mypy` and `pyright` at CI time
  – including on every commit as well as pull request (PR). For both robustness
  and efficiency, this release prevents functional tests in our test suite that
  perform these same static type-checks from running under CI. Doing so resolves
  a furious spate of spurious CI complaints. So what we did there? We rhymed.
  Notably, this release:
  * Leverages @jakebailey's superb `jakebailey/pyright-action` action to
    exercise @beartype against `pyright` at CI time.
  * Manually installs and runs `mypy` in a low-level manner under CI *without*
    leveraging @jpetrucciani's otherwise stellar `jpetrucciani/mypy-check`
    action -- which @beartype hopes to revisit at a later date when the issue
    tracker settles there a bit. Thanks so much, @jpetrucciani! You dah real QA
    MVP.

## Issue Resolved

* **`beartype.door.TypeHint` comparisons.** This release significantly improves
  the robustness of comparison operators overloaded by the object-oriented
  `beartype.door.TypeHint` API, resolving issue #198 kindly submitted by
  @wesselb the phenomenal Amsterdammer of
  [Plum](https://github.com/wesselb/plum) fame. This includes edge cases when:
  * Comparing unions against both other unions *and* non-unions (e.g.,
    `typing.Any`, isinstanceable classes).
  * Comparing tuple type hints against `typing.Any`.
* **`beartype.BeartypeConf` caching.** This release resolves a critical (yet
  ultimately trivial) caching issue with respect to `beartype.BeartypeConf`
  singletons, in which singletons initialized with different parameters could
  conceivably have been erroneously cached to the same object. Hash collisions!
  I see hash collisions everywhere!
* **Call stack iteration robustness.** This release resolves an edge case in our
  private `beartype._util.func.utilfuncframe.iter_frames()` generator iterating
  over stack frames on the current call stack. Specifically, this generator now
  safely reduces to the empty generator (i.e., noop) when the caller requested
  that generator ignore more stack frames than exist on the call stack. Although
  raising an exception would also be feasible, doing so would only needlessly
  increase the fragility of this already fragile mission-critical generator.

## Documentation Resolved

* **Broken anchor links.** This release repairs broken anchor links dotted
  throughout our monolithic `README.rst` to actually point to valid
  (sub)sections.
* **Sphinx configuration.** This release reconfigures the lackluster coffin that
  is our Sphinx configuration, en-route to resolving issue #8 (!) kindly
  submitted a literal lifetime ago by visionary computer vision export and
  long-standing phenomenal Finn @felix-hilden (Felix Hildén). Specifically,
  this release:
  * **Enables Furo,** switching from the default Read The Docs (RTD) Sphinx
    theme to the third-party Furo theme. We selected this theme according to
    mostly objective (albeit ultimately subjective) heuristic criteria. In
    descending order of importance, we selected the theme with:
    1. The most frequent git commit history.
    2. The open issues and pull requests (PRs).
    3. The most GitHub stars as a crude proxy for aggregate rating.
    Furo handily bested all other themes across all three criteria. Furo is very
    well-maintained, frequently closes out open issues and merges open PRs, and
    sports the highest quantity of GitHub stars by an overwhelming margin. `\o/`
  * **Enables the builtin `intersphinx` extension,** enabling attributes
    defined by the standard library (e.g., the `typing` module, the
    `types.GenericAlias` type) to be cross-referenced as a fallback when *not*
    already defined by this project.
  * **Reconfigures RTD** through our top-level `.readthedocs.yml`
    configuration to:
    * Build under the most recent Long Term Service (LTS) release of Ubuntu.
    * Build under the most recently released minor version of CPython.
    * Configure Sphinx via our `doc/source/conf.py` script.
  * **Restores the standard `sys.path` hack** – which, for unknown reasons,
    @leycec disabled but thankfully left commented out. Doing so re-resolves
    issue #120, kindly submitted by @kloczek (Tomasz Kłoczko) five friggin'
    months ago. Thanks so much for the fast patch and rapid turn-around,
    @kloczek!
  * **Improves pathname robustness** by intelligently detecting
    documentation paths via the standard `pathlib.Path` API.
  * **Enables `autoapi`.** This release successfully transitions from Sphinx's
    builtin (but insane) `autodoc` and `autosummary` extensions to Read The Doc
    (RTD)'s non-builtin (but sane) `autoapi` extension.
  * **Adds a local URI store** (i.e., hidden reStructuredText (reST) document
    centralizing common URI links in reST format, automatically exposed to all
    other reST documents in this project via the `rst_epilog` setting in
    `conf.py`) at `doc/src/_links.rst`.
  * **Removes obsolete cruft,** which accrues with time like entropic motes in
    God's eye. That was a reference to a Golden Age of Scifi book, people! Don't
    ask why God only has one eye. It's better not to contemplate these matters.
  * **Ruthlessly circumvents upstream issue sphinx-doc/sphinx#4961,** causing
    Sphinx to emit literally hundreds of ignorable warnings resembling
    ``"WARNING: more than one target found for cross-reference 'TypeHint':``
    ``beartype.door._doorcls.TypeHint, beartype.door.TypeHint"`` with a [trivial
    circumvention shamelessly pilfered from
    @RDFLib](https://github.com/RDFLib/rdflib/blob/3a418218d6bcdb46f78342e14c024063e2f53e71/docs/conf.py#L255).

## Documentation Added

* **[Beartype Object-oriented
  API](https://github.com/beartype/beartype/tree/76aebd63b5f32ac6bdab6420eb0c9bfa2ca09b29#id36).**
  This release prefaces our "Beartype Object-oriented API" subsection with a
  human-readable discussion of the Decidedly Object-Oriented Runtime-checking
  (DOOR) – also known as "That API Which Breaks Hearts and Minds Alike."
* **[Procedural
  Showcase]**(https://github.com/beartype/beartype/#procedural-showcase). This
  release adds a new *Procedural Showcase* subsection containing a new *Detect
  API Breakage* subsubsection exhibiting a real-world usage for our recently
  published `beartype.door.is_subhint()` tester: detecting API breakage across
  the type hints annotating arbitrary callables in exactly ten lines of code.
* **[Near-real-time FAQ
  entry](https://github.com/beartype/beartype/#beartype-realtime).** This
  release adds a new FAQ entry entitled *What does "near-real-time" even mean?*,
  justifying our recent categorization of @beartype as a "near-real-time runtime
  type-checker." Let's pretend @leycec knows what he's talking about.
* **[JAX, Numpy, and PyTorch FAQ
  entries](https://github.com/beartype/beartype/#jax-arrays).** This release
  expands our existing FAQ with entries on typing JAX and NumPy arrays and
  PyTorch tensors to highlight the stupefying potential unlocked by the
  third-party `jaxtyping`, `nptyping`, and TorchTyping packages, resolving
  issue #98 submitted a literal lifetime ago by Edinburgh NLP researcher
  @amitkparekh (Amit Parekh).
* **[VSCode FAQ
  entry](https://github.com/beartype/beartype/tree/76aebd63b5f32ac6bdab6420eb0c9bfa2ca09b29#id28).**
  This release rewrites our entire FAQ entry on `pyright` + Pylance + VSCode to
  be significantly more charitable towards `pyright`, resolving issue #170
  kindly submitted by MIT AI mastermind @rsokl (Ryan Soklaski).
* **[Type narrowing FAQ
  entry](https://github.com/beartype/beartype/tree/76aebd63b5f32ac6bdab6420eb0c9bfa2ca09b29#id30).**
  This release adds a new FAQ entry on type narrowing, strongly inspired by
  (*...wait for it*) MIT AI mastermind @rsokl (Ryan Soklaski)'s equally
  masterful writing at issue #166.

(*Powerful bowers full of flowers!*)

This commit is the last in a commit chain coercing our monolithic
`README.rst` documentation onto Read the Docs (RTD), resolving both
issue #203 kindly submitted by @LittleBigGene (AKA the dynamo
of the cell) and ancient issue #8 kindly submitted by @felix-hilden (AKA
the Finnish computer vision art genius that really made all of this
possible). Specifically, this commit:

* Finishes Sphinx-ifying our entire frickin' document base.
* Officially truncates our `README.rst` documentation.

Readable docos: *engage!* (*Illegible legerdemain has no domain!*)

This minor release delivers pulse-quickening support for **pandera
(pandas) type hints,** **PEP 484,** **PEP 585**, **PEP 591**, **PEP
647**, **PEP 3119**, and **pseudo-callables.**

This minor release resolves **12 issues** and merges **2 pull
requests.** But first, a quiet word from our wondrous sponsors. They are
monocled QA wizards who serve justice while crushing bugs for humanity.
High fives, please!

## Beartype Sponsors

* [**ZeroGuard:** The Modern Threat Hunting
  Platform](https://zeroguard.com). *All the signals, All the time.*

Thunderous applause echoes through the cavernous confines of the Bear
Den. 👏 🐻‍❄️ 👏

And now... the moment we've waited for. A heinous display of plaintext
that assaults all five senses simultaneously.

## Compatibility Added

* **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:
      * `beartype.door.is_bearable()`.
      * `beartype.door.die_if_unbearable()`.
  * Implements a non-trivial trie data structure to efficiently
    detect all type hints produced by subscriptable factories in the
    `pandera.typing` submodule. Let us pretend this never happened,
    @ulfaslakprecis.
* **PEP 484- and 585-compliant generator constraints.** This release
  relaxes prior constraints erroneously imposed by @beartype
  prohibiting both asynchronous and synchronous generator callables from
  being annotated as returning unsubscripted standard abstract base
  classes (ABCs) defined by the `collections.abc` module. Now, @beartype
  permits:
  * Asynchronous generator callables to be annotated as returning the
    unsubscripted `collections.abc.AsyncGenerator` type.
  * Synchronous generator callables to be annotated as returning the
    unsubscripted `collections.abc.Generator` type.
* **PEP 591** (i.e., `typing.Final[...]` type hints), partially
  resolving issue #223 kindly submitted by the acronym known only as
  @JWCS (Jude). @beartype now trivially reduces *all*
  `typing.Final[{hint}]` type hints to merely `{hint}` (e.g.,
  `typing.Final[int]` to `int`). In other words, @beartype no longer
  raises exceptions when confronted with final type hints and instead at
  least tries to do the right thing. This still isn't *quite* what
  everyone wants @beartype to do here; ideally, @beartype should also
  raise exceptions on detecting attempts to redefine instance and class
  variables annotated as `Final[...]`. Doing so is *definitely* feasible
  and exactly what @beartype should *eventually* do – but also
  non-trivial, because whatever @beartype *eventually* does needs to
  preserve compatibility with all implementations of the `@dataclass`
  decorator across all versions of Python now and forever. Cue that
  head-throbbing migraine. It's comin'! Oh, I can feel it!
* **PEP 647** (i.e., `typing.TypeGuard[...] type hints`), resolving
  feature request #221 kindly submitted by Google X researcher
  extraordinaire @patrick-kidger. @beartype now trivially reduces *all*
  `typing.TypeGuard[...]` type hints to the builtin `bool` type.

## Compatibility Improved

* **PEP 3119.** @beartype now detects both
  **non-isinstanceable classes** (i.e., classes whose metaclasses define
  PEP 3119-compliant `__instancecheck__()` dunder methods
  unconditionally raising `TypeError` exceptions) and
  **non-issubclassable classes** (i.e., classes whose metaclasses define
  PEP 3119-compliant `__subclasscheck__()` dunder methods
  unconditionally raising `TypeError` exceptions) more narrowly for
  safety, resolving issue #220 kindly submitted by *ex*traordinary
  Google X researcher @patrick-kidger (Patrick Kidger). Notably,
  @beartype now *only* accepts `TypeError` exceptions as connoting
  non-isinstanceability and non-issubclassability. Previously, @beartype
  broadly treated any class raising any exception whatsoever when passed
  as the second parameter to `isinstance()` and `issubclass()` as
  non-isinstanceable and non-issubclassable. Sadly, doing so erroneously
  raises false positives for isinstanceable and issubclassable
  metaclasses that have yet to be fully "initialized" at the early time
  the `@beartype` decorator performs this detection.

## Features Added

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

## Documentation Revised

* **Literally everything,** also known as the release that migrated
  `README.rst` -> [Read the Docs
  (RtD)](https://beartype.readthedocs.io), resolving both issue #203
  kindly submitted by @LittleBigGene (AKA the dynamo of the cell) and
  ancient issue #8 kindly submitted by @felix-hilden (AKA the Finnish
  computer vision art genius that really made all of this possible).
  Readable documentation slowly emerges from the primordial soup of
  @beartype's shameless past for which we cannot be blamed. @leycec was
  young and "spirited" back then. Specifically, this release:
  * Coerces our prior monolithic slab of unreadable `README.rst`
    documentation into a website graciously hosted by Read the Docs
    (RtD) subdividing that prior documentation into well-structured
    pages, resolving issue #203 kindly submitted by @LittleBigGene (AKA
    the dynamo of the cell).
  * Documents *most* previously undocumented public APIs in the
    @beartype codebase. Although a handful of public APIs remain
    undocumented (notably, the `beartype.peps` submodule), these
    undocumented APIs are assumed to either be sufficiently unpopular or
    non-useful to warrant investing additional scarce resources here.
  * Updates our installation instructions to note @beartype's recent
    availability as official packages in the official package
    repositories of various Linux distributions. Truly, this can only be
    the final mark of pride. These include:
    * Gentoo Linux's Portage tree.
    * Arch Linux's Arch User Repository (AUR).
  * Improves the Python code sample embedded in the ["Are We on the
    Worst Timeline?" subsection of our **Beartype Errors**
    chapter](https://beartype.readthedocs.io/en/latest/api_roar/#are-we-on-the-worst-timeline).
    Thanks to @JWCS for their related pull request (PR) #210, which
    strongly inspired this bald-faced improvement to the usability of
    our `beartype.typing` API.
  * Circumvents multiple long-standing upstream issues in the PyData
    Sphinx theme regarding empty left sidebars via the requisite
    `_templates/sidebar-nav-bs.html` template hack shamelessly
    copy-pasted into literally *every* project requiring this theme.
    This includes @beartype, because why not spew boilerplate that
    nobody understands everywhere? Sadly, doing so requires pinning to a
    maximum obsolete version of this theme that will surely die soon.
    And this is why I facepalm. These issues include:
    * pydata/pydata-sphinx-theme#90.
    * pydata/pydata-sphinx-theme#221.
    * pydata/pydata-sphinx-theme#1181.
  * Truncates our `README.rst` documentation to a placeholder stub that
    just directs everyone to RtD instead.
  * Improves `linecache` integration commentary. Specifically, a pull
    request by @faangbait (AKA the little-known third member of Daft
    Punk) improves internal commentary in our private
    `beartype._util.func.utilfuncmake.make_func()` factory function
    responsible for dynamically synthesizing new in-memory functions
    on-the-fly. Our suspicious usage of `None` as the second item of
    tuples added as values to the standard `linecache.cache` global
    dictionary has now been documented. Thanks so much for this
    stupendous contribution, @faangbait!

## Tests Improved

* **Mypy integration.** This release improves our `test_pep561_mypy()`
  integration test to intentionally ignore unhelpful non-fatal warnings
  improperly emitted by mypy (which encourage usage of
  `typing_extensions`, oddly enough).
* **Sphinx integration.** This release resolves multiple intersecting
  issues involving integration testing of Sphinx + @beartype, including:
  * `test_beartype_in_sphinx()` h0tfix is h0t. This release generalizes
    our test-specific `test_beartype_in_sphinx()` integration test to
    support arbitrary versions of Sphinx, resolving issue #209 kindly
    submitted by @danigm the sun-loving Málaga resident who frolics in
    the sea that Canadians everywhere are openly jealous of.
    Specifically, this release fundamentally refactors this integration
    test to fork a new Python interpreter as a subprocess of the current
    `pytest` process running the `sphinx-build` command.
  * A Python 3.7-specific failure in our continuous integration (CI)
    workflow caused by Sphinx attempting to call deprecated
    functionality of the third-party `pkg_resources` package. This
    release simply avoids installing Sphinx entirely under Python 3.7;
    although admittedly crude, it's unclear how else @beartype could
    possibly resolve this. Since Python 3.7 has almost hit its official
    End-Of-Life (EOL) and thus increasingly poses a security concern,
    this is hardly the worst resolution ever. Really! Believe what we're
    saying.

Break nothing! It's the @beartype way. This is why @leycec cries like a
mewling cat with no milk. (*Thrilling chills spill towards an untoward ontology!*)