Josh Rosenberg added the comment: So it predates the existence of type code 'n', which would be the appropriate type code, but no one updated it.
Antoine: Inability to perform a 2GB+ read properly is not something that should be worked around on a case by case basis. There is one compatibility risk here, which is that 'n' requires index integers (__index__), where 'l' will accept coercible types (__int__). If you think people are reading from files using Fraction and Decimal, then this would be a compatibility issue (and you could work around it be making it use type code 'L' only on 64 bit Windows), but this just looks like an oversight from the upgrade from int to Py_ssize_t across the Python code base. ---------- nosy: +josh.rosenberg _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21199> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
