Argh

---------------------------

Bugs fixed:

- wrong type annotation of `errors` in `wrap_errors` (PR 229 by laazy)
- tests were failing under Python 3.13 (issue 228 by mgorny)
- regression: can't set argument name with `dest` via decorator
(issue 224 by mathieulongtin)

---------------------------

Bugs fixed:

- broken support for `Optional[List]` (but not `Optional[list]`), a narrower
case of the problem fixed earlier (issue 216).

---------------------------

Bugs fixed:

- broken support for type alias `List` (issue 216).

Enhancements:

- cleaned up the README, rearranged other documentation.

---------------------------

Breaking changes:

- The typing hints introspection feature is automatically enabled for any
command (function) which does **not** have any arguments specified via `arg`
decorator.

This means that, for example, the following function used to fail and now
it will pass::

def main(count: int):
assert isinstance(count, int)

This may lead to unexpected behaviour in some rare cases.

- A small change in the legacy argument mapping policy `BY_NAME_IF_HAS_DEFAULT`
concerning the order of variadic positional vs. keyword-only arguments.

The following function now results in ``main alpha [args ...] beta`` instead of
``main alpha beta [args ...]``::

def main(alpha, *args, beta): ...

This does **not** concern the default name mapping policy. Even for the
legacy one it's an edge case which is extremely unlikely to appear in any
real-life application.

- Removed the previously deprecated decorator `expects_obj`.

Enhancements:

- Added experimental support for basic typing hints (issue 203)

The following hints are currently supported:

- ``str``, ``int``, ``float``, ``bool`` (goes to ``type``);
- ``list`` (affects ``nargs``), ``list[T]`` (first subtype goes into ``type``);
- ``Literal[T1, T2, ...]`` (interpreted as ``choices``);
- ``Optional[T]`` AKA ``T | None`` (currently interpreted as
``required=False`` for optional and ``nargs="?"`` for positional
arguments; likely to change in the future as use cases accumulate).

The exact interpretation of the type hints is subject to change in the
upcoming versions of Argh.

- Added `always_flush` argument to `dispatch()` (issue 145)

- High-level functions `argh.dispatch_command()` and `argh.dispatch_commands()`
now accept a new parameter `old_name_mapping_policy`. The behaviour hasn't
changed because the parameter is `True` by default. It will change to
`False` in Argh v.0.33 or v.1.0.

Deprecated:

- the `namespace` argument in `argh.dispatch()` and `argh.parse_and_resolve()`.
Rationale: continued API cleanup. It's already possible to mutate the
namespace object between parsing and calling the endpoint; it's unlikely that
anyone would need to specify a custom namespace class or pre-populate it
before parsing. Please file an issue if you have a valid use case.

Other changes:

- Refactoring.

---------------------------

Bugs fixed:

- A combination of `nargs` with a list as default value would lead to the
values coming from CLI being wrapped in another list (issue 212).

Enhancements:

- Argspec guessing: if `nargs` is not specified but the default value
is a list, ``nargs="*"`` is assumed and passed to argparse.

---------------------------

There were complaints about the lack of a deprecation cycle for the legacy name
mapping policy. This version addresses the issue:

- The handling introduced in v.0.30.2 (raising an exception for clarity)
is retained for cases when no name mapping policy is specified but function
signature contains defaults in non-kwonly args **and kwonly args are also
defined**::

def main(alpha, beta=1, *, gamma=2): error — explicit policy required

In a similar case but when **kwonly args are not defined** Argh now assumes
the legacy name mapping policy (`BY_NAME_IF_HAS_DEFAULT`) and merely issues
a deprecation warning with the same message as the exception mentioned above::

def main(alpha, beta=2): `[-b BETA] alpha` + DeprecationWarning

This ensures that most of the old scripts still work the same way despite the
new policy being used by default and enforced in cases when it's impossible
to resolve the mapping conflict.

Please note that this "soft" handling is to be removed in version v0.33
(or v1.0 if the former is not deemed necessary). The new name mapping policy
will be used by default without warnings, like in v0.30.