Co-authored-by: hauntsaninja <>

PyPI stats indicates that 0.00% of downloads are for Python 3.4:
https://www.pypistats.org/packages/mypy-extensions

Other supported Python versions have non-trivial downloads, so let's
continue to support them for now.

I'm not updating .travis.yml since Travis CI is no longer
functioning.

Now `tox run` runs tests on all supported Python versions. One 3.11 test
is still failing -- I'll look at it later.

Integers are now accepted as types in many runtime contexts:
python/cpython#90802

Fixes #24.

Mypy has dropped Python 2 support some time ago, and maintaining
Python 2 support is getting too complicated for little benefit.

Mypy 1.0 is release is going out soon, so let's make mypy_extensions 1.0
as well.

In code compiled with mypyc, these can be used in annotations to use
faster native int operations that don't check for overflow, as an
alternative to the default arbitrary-precision int type.

See mypyc/mypyc/issues/837 for more context. Note that only i64 and
i32 are currently supported by mypyc, but I'm adding the planned i16
and u8 types as well since their implementation is essentially the
same.

These are not real classes. In particular, there can be no instances
of these types. In code that is not compiled with mypyc, there are
just regular 'int' objects, in order to allow code using these types
to be run without compilation. In code compiled with mypyc, these are
represented as native integers that don't have a 1:1 Python
replacement. The native integers are impliciticly converted to/from
'int' objects when boxed/unboxed.

I originally was planning to make these aliases of `int`, but there
are runtime type checking and introspection use cases where it's
important to make these distinct objects.

The types only support a few runtime operations:

* Conversions from numbers and strings
* `isinstance` checks

We could also add at least the `from_bytes` class method, but it
doesn't seem urgent as long as mypyc doesn't support it as a primitive
operation.

Also a few other minor updates to the description.

Followed these instructions:
https://packaging.python.org/en/latest/guides/dropping-older-python-versions/

I'm not going to make a release with python_requires>='2.7' first as suggested
by the docs, since dropping universal wheels should be enough to not have this
version installed on Python 2, and since 3.4 and earlier are basically non-existent
at this point.