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 vstinner
Recipients Matt.Mackall, benjamin.peterson, brett.cannon, eric.smith, ezio.melotti, josh.r, larry, loewis, ncoghlan, pitrou, vstinner
Date 2014-04-16.06:09:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1397628585.43.0.929567598463.issue21199@psf.upfronthosting.co.za>
In-reply-to
Content
"It is much simpler for Mercurial to add a workaround (which they already did, apparently :-)), than to risk introducing regressions by fixing this. AFAIK nobody else complained before."

We fixed a lot of issues for 32-bit long and 64-bit size_t types (Windows 64 bits) in Python 3.3 and 3.4. I don't think that they were fixed in Python 2.7, because the required changes are large and it would be risky to backport them. At least, I don't feel confortable to backport them.

I suggest to switch to Python 3 if you would like to handle large objects (bigger than 2 GB) on Windows 64-bit.

See the issue #9566 for examples of fixes, but there were many other changes related to 64-bit Windows issues.

I see for example that send() & send_bytes() methods of multiprocessing connection doesn't truncate the length to DWORD_MAX bytes on Windows in Python 2.7, whereas it was fixed in Python 3:
http://hg.python.org/cpython/rev/c75ab7b802df
(On UNIX, the same methods loop on write() to ensure that all bytes are written.)

If you want to announce that Python 2.7.x supports large objects on Windows 64 bits, be prepared to have to fix Python in various different places.
History
Date User Action Args
2014-04-16 06:09:45vstinnersetrecipients: + vstinner, loewis, brett.cannon, ncoghlan, pitrou, larry, eric.smith, benjamin.peterson, ezio.melotti, Matt.Mackall, josh.r
2014-04-16 06:09:45vstinnersetmessageid: <1397628585.43.0.929567598463.issue21199@psf.upfronthosting.co.za>
2014-04-16 06:09:45vstinnerlinkissue21199 messages
2014-04-16 06:09:44vstinnercreate