datetime.py is peppered with ``assert`` statements that are two restrictive. Specifically, ``isinstance(..., int)`` does not afford compatibility with alternate ``int``-like implementations (e.g., ``future.types.newint``). Some background:

* https://github.com/PythonCharmers/python-future/issues/187
* https://bitbucket.org/pypy/pypy/issues/2193/datetimetimedelta-chokes-on-seconds

In all cases that I can find, ``assert isinstance(..., int)`` is unnecessarily restrictive, since it is always followed by another ``assert`` which validates that the boundaries are far smaller than a Python 2 native `int` type. (See, e.g., `datetype.py at line 395 <https://hg.python.org/cpython/file/ebec1a98ab81/Lib/datetime.py#l395>`__).

I propose replacing instances of ``assert isinstance(..., int)`` and ``assert isinstance(..., (int, long))`` with ``assert isinstance(..., numbers.Integral)`` akin to `this patch <https://bitbucket.org/pypy/pypy/pull-requests/361/fix-2193/diff>`__.

C implementation almost everywhere (except strftime/strptime) accepts long as well as int, but not general integral numbers. Python implementation of the datetime module is not entire compatible with C implementation (default in CPython), therefore alternative Python implementations that doesn't use an accelerator is incompatible with CPython. I consider this as a bug and think that we should weak some of checks isinstance(..., int) to isinstance(..., (int, long)). numbers.Integral is too wide type, C implementation doesn't support it.

> I consider this as a bug and think that we should weak some of checks isinstance(..., int) to isinstance(..., (int, long)). numbers.Integral is too wide type, C implementation doesn't support it.

Oddly enough, the C implementation is what is working with `future` in this case (although I take your point regarding `numbers.Integral` being too wide; `future.types.newint` effectively behaves like a `long`, and `isinstance(future.types.newint(1), long)` returns `True`).

Python 2.7 is no longer supported.