Paul Rubin a écrit : > Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > >>I've rarely encoutered "silent" data corruption with Python - FWIW, I >>once had such a problem, but with a lower-level statically typed >>language (integer overflow), and I was a very newbie programmer by that >>time. Usually, one *very quickly* notices when something goes wrong. > > > The same thing can happen in Python, and the resulting bugs can be > pretty subtle. I noticed the following example as the result of > another thread, which was about how to sort an 85 gigabyte file. > Try to put a slice interface on a file-based object and you can > hit strange integer-overflow bugs once the file gets larger than 2GB: > > Python 2.3.4 (#1, Feb 2 2005, 12:11:53) > [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> print slice(0, 3**33) > slice(0, 5559060566555523L, None) # OK ... > > So we expect slicing with large args to work properly. But then: > > >>> class A: > ... def __getitem__(self, s): > ... print s > ... > >>> a = A() > >>> a[0:3**33] > slice(0, 2147483647, None) # oops!!!! > >>>
Looks like a Python bug, not a programmer error. And BTW, it doesn't happens with >=2.4.1 Python 2.4.1 (#1, Jul 23 2005, 00:37:37) [GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print slice(0, 3**33) slice(0, 5559060566555523L, None) >>> class A(object): ... def __getitem__(self, s): ... print s ... >>> A()[0:3**33] slice(0, 5559060566555523L, None) >>> -- http://mail.python.org/mailman/listinfo/python-list
