This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author posita
Recipients posita
Date 2015-11-23.18:42:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1448304139.86.0.253570018979.issue25714@psf.upfronthosting.co.za>
In-reply-to
Content
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>`__.
History
Date User Action Args
2015-11-23 18:42:19positasetrecipients: + posita
2015-11-23 18:42:19positasetmessageid: <1448304139.86.0.253570018979.issue25714@psf.upfronthosting.co.za>
2015-11-23 18:42:19positalinkissue25714 messages
2015-11-23 18:42:19positacreate