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 terry.reedy
Recipients brian.curtin, pitrou, schlamar, serhiy.storchaka, terry.reedy, tim.golden
Date 2012-12-23.23:09:52
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1356304192.86.0.413326435956.issue16743@psf.upfronthosting.co.za>
In-reply-to
Content
To me, Marc's title and penultimate sentence imply that he thinks that mmap should not accept such files. (But he should speak for himself.) As I said, not accepting such files could break working code.

As for the alternative of 'fixing' methods: Is it only slicing or other methods, even *every* method that 'misbehaves' when attempting to read (or write) beyond the 1 gig limit? I am guessing the last. If so, just about every method (inherited from bytearray, like slicing, or mmap specific) would need a fix conditional on the build and access location (and OS or hardware?).

Even for slices, what change would you (or anyone) make? Keep in mind that is it a *feature* of slices that they generally always work, and that this is specifically true of bytearrays. ("Memory-mapped file objects behave like both bytearray and like file objects.") 

I am actually a bit surprised that the limit is 1 gb rather than 2, 3, or 4 gb. Is it the same on *nix? What is the limit for a bytearray on Win 7?
History
Date User Action Args
2012-12-23 23:09:52terry.reedysetrecipients: + terry.reedy, pitrou, tim.golden, brian.curtin, schlamar, serhiy.storchaka
2012-12-23 23:09:52terry.reedysetmessageid: <1356304192.86.0.413326435956.issue16743@psf.upfronthosting.co.za>
2012-12-23 23:09:52terry.reedylinkissue16743 messages
2012-12-23 23:09:52terry.reedycreate