Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
On Tue, May 3, 2011 at 3:19 PM, victor.stinner
wrote:
> +# Issue #10276 - check that inputs of 2 GB are handled correctly.
> +# Be aware of issues #1202, #8650, #8651 and #10276
> +class ChecksumBigBufferTestCase(unittest.TestCase):
> + int_max = 0x7FFF
> +
> + @unittest.skipUnless(mmap, "mmap() is not available.")
> + def test_big_buffer(self):
> + if sys.platform[:3] == 'win' or sys.platform == 'darwin':
> + requires('largefile',
> + 'test requires %s bytes and a long time to run' %
> + str(self.int_max))
> + try:
> + with open(TESTFN, "wb+") as f:
> + f.seek(self.int_max-4)
> + f.write("asdf")
> + f.flush()
> + try:
> + m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
> + self.assertEqual(zlib.crc32(m), 0x709418e7)
> + self.assertEqual(zlib.adler32(m), -2072837729)
> + finally:
> + m.close()
> + except (IOError, OverflowError):
> + raise unittest.SkipTest("filesystem doesn't have largefile
> support")
> + finally:
> + unlink(TESTFN)
> +
> +
0x7FFF is (2G-1) bytes. For a 2GB buffer, int_max should be
0x8000. However, if you make this change, crc32() and adler32()
raise OverflowErrors (see changeset a0681e7a6ded). This makes the test
to erroneously report that the filesystem doesn't support large files.
The assertEqual() tests should probably be changed to
assertRaises(..., OverflowError).
Also, the assignment to m needs to be moved outside of the inner
try...finally block. If mmap() fails, the call to m.close() raises a
new exception because m has not yet been bound. This seems to be
causing failures on some of the 32-bit buildbots.
As an aside, in this sort of situation is it better to just go and
commit a fix myself, or is raising it on the mailing list first the
right way to do things?
Cheers,
Nadeem
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raise OSError or RuntimeError in the OS module?
On 02.05.2011 12:06, Victor Stinner wrote: > Hi, > > I introduced recently the signal.pthread_sigmask() function (issue #8407). > pthread_sigmask() (the C function) returns an error code using errno codes. I > choosed to raise a RuntimeError using this error code, but I am not sure that > RuntimeError is the best choice. It is more an OS error than a runtime error: > should signal.pthread_sigmask() raise an OSError instead? > > signal.signal() raises a RuntimeError if setting the signal handler failed. > signal.siginterrupt() raises also a RuntimeError on error. > > signal.setitimer() and signal.getitimer() have their own exception class: > signal.ItimerError, raised on setimer() and getitimer() error. If it has an errno, it should be a subclass of EnvironmentError. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows 2000 Support
On Mon, May 2, 2011 at 19:39, Brian Curtin wrote: > On Mon, May 2, 2011 at 16:14, "Martin v. Löwis" wrote: > >> Am 01.05.2011 22:51, schrieb Brian Curtin: >> > I'm currently writing a post about the process of removing OS/2 and VMS >> > support and thought about a discussion of Windows 2000 some time >> > back. >> http://mail.python.org/pipermail/python-dev/2010-March/098074.html makes >> > a proposal for beginning to walk away from 2000, but doesn't appear to >> > come to any conclusion. >> > >> > Was anything decided off the list? I don't see anything in PEP-11 and >> > don't see any changes in the installer made around Windows 2000. >> >> That's what you get for not following your own processes. It seems the >> discussion just stopped, with no action. I vaguely recall having made >> changes to the installer to produce a warning, but apparently never >> got to commit these changes. >> >> > If nothing was decided, should anything be done for 3.3? >> >> Most certainly. It seems we missed the chance of dropping support for >> W2k, so we still can't actively remove any code. However, I'd >> >> a) add it to PEP 11, and >> b) add a warning to the installer >> >> I stand by >> >> http://mail.python.org/pipermail/python-dev/2010-March/098101.html >> >> i.e. if there are patches that happen not to work on W2k, I'd accept >> them anyway - anybody interested in W2k would then have to provide >> fixes before 3.3rc1. >> >> So please go ahead and change PEP 11. While you are at it, also threaten >> to remove support for systems where the COMSPEC points to command.com >> (#2405). >> > > Done and done - http://hg.python.org/peps/rev/b9390aa12855 > I'll have a look at the installer and add some type of message. > It turns out that you did make the change at some point for 2.7 being the last, but there was no corresponding 3.x version chosen. http://hg.python.org/cpython/rev/de53c52fbcbf changed the installer to list 3.3.0 as the last Windows 2000 release on the default branch. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
Hello, On Tue, 3 May 2011 16:22:27 +0200 Nadeem Vawda wrote: > > As an aside, in this sort of situation is it better to just go and > commit a fix myself, or is raising it on the mailing list first the > right way to do things? Raising it on the mailing-list makes it serve as a kind of post-commit review. Also, it ensures that the committer of the original patch understands the issues with it. cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
Le mardi 03 mai 2011 à 16:22 +0200, Nadeem Vawda a écrit :
> On Tue, May 3, 2011 at 3:19 PM, victor.stinner
> wrote:
> > +# Issue #10276 - check that inputs of 2 GB are handled correctly.
> > +# Be aware of issues #1202, #8650, #8651 and #10276
> > +class ChecksumBigBufferTestCase(unittest.TestCase):
> > +int_max = 0x7FFF
> > +
> > +@unittest.skipUnless(mmap, "mmap() is not available.")
> > +def test_big_buffer(self):
> > +if sys.platform[:3] == 'win' or sys.platform == 'darwin':
> > +requires('largefile',
> > + 'test requires %s bytes and a long time to run' %
> > + str(self.int_max))
> > +try:
> > +with open(TESTFN, "wb+") as f:
> > +f.seek(self.int_max-4)
> > +f.write("asdf")
> > +f.flush()
> > +try:
> > +m = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ)
> > +self.assertEqual(zlib.crc32(m), 0x709418e7)
> > +self.assertEqual(zlib.adler32(m), -2072837729)
> > +finally:
> > +m.close()
> > +except (IOError, OverflowError):
> > +raise unittest.SkipTest("filesystem doesn't have largefile
> > support")
> > +finally:
> > +unlink(TESTFN)
> > +
> > +
>
> 0x7FFF is (2G-1) bytes. For a 2GB buffer, int_max should be
> 0x8000. However, if you make this change, crc32() and adler32()
> raise OverflowErrors (see changeset a0681e7a6ded).
I don't want to check OverflowError: the test is supposed to compute the
checksum of a buffer of 0x7FFF bytes, to check crc32() and
adler32(). 0x7FFF is the biggest size supported by these functions
(zlib doesn't use Py_ssize_t in Python 2.7).
If you use a buffer of 0x8000 bytes, you test PyArg_Parse*()
functions, which have already a dedicated test (in test_xml_etree_c,
it's not the best file to store such test...).
> Also, the assignment to m needs to be moved outside of the inner
> try...finally block.
Yeah, I noticed this with buildbots: already fixed by dd58f8072216.
> As an aside, in this sort of situation is it better to just go and
> commit a fix myself, or is raising it on the mailing list first the
> right way to do things?
I'm not sure that you understood the test, so I think that it's better
to ask first on IRC and/or the mailing list.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #10276: test_zlib checks that inputs of 2 GB are handled correctly by
On Tue, May 3, 2011 at 10:38 PM, Victor Stinner wrote: > I don't want to check OverflowError: the test is supposed to compute the > checksum of a buffer of 0x7FFF bytes, to check crc32() and > adler32(). 0x7FFF is the biggest size supported by these functions > (zlib doesn't use Py_ssize_t in Python 2.7). I see. Since you mentioned issue 10276 in the commit message, I assumed you were testing for the underlying C functions truncating their arguments. It seems that I was mistaken. Sorry for the confusion. Cheers, Nadeem ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
