Mailman 3 May 2000 - Python-Dev

hey, who broke the array module?
by Fredrik Lundh May 15, 2000

May 15, 2000

sigh. never resync the CVS repository until you've fixed all bugs in your *own* code ;-) in 1.5.2: >>> array.array("h", [65535]) array('h', [-1]) >>> array.array("H", [65535]) array('H', [65535]) in the current CVS version: >>> array.array("h", [65535]) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: signed short integer is greater than maximum okay, this might break some existing code -- but one can always argue that such … [View More]

2 1

cvs for dummies
by Fredrik Lundh May 15, 2000

May 15, 2000

what's the best way to make sure that a "cvs update" really brings everything up to date, even if you've accidentally changed some- thing in your local workspace? </F>

5 5

Re: [Patches] getpath patch
by Fredrik Lundh May 13, 2000

May 13, 2000

MAL wrote: > Note: Python will dump core if it cannot find the exceptions > module. Perhaps we should add a builtin _exceptions module > (basically a frozen exceptions.py) which is then used as > fallback solution ?! or use this one: http://w1.132.telia.com/~u13208596/exceptions.htm </F>

1 0

for the todo list: cStringIO uses string.joinfields
by Fredrik Lundh May 13, 2000

May 13, 2000

the O_writelines function in Modules/cStringIO contains the following code: if (!string_joinfields) { UNLESS(string_module = PyImport_ImportModule("string")) { return NULL; } UNLESS(string_joinfields= PyObject_GetAttrString(string_module, "joinfields")) { return NULL; } Py_DECREF(string_module); } I suppose someone should fix this some day... (btw, the C API reference implies that ImportModule doesn't use import hooks. does that mean that … [View More]

3 3

Landmark
by M.-A. Lemburg May 12, 2000

May 12, 2000

While trying to configure an in-package Python interpreter I found that the interpreter still uses 'string.py' as landmark for finding the standard library. Since string.py is being depreciated, I think we should consider a new landmark (such as os.py) or maybe even a whole new strategy for finding the standard lib location. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ … [View More]

3 5

"is", "==", and sameness
by weeks＠golden.dtc.hp.com May 12, 2000

May 12, 2000

>From the Python Reference Manual [emphasis added]: Types affect almost all aspects of object behavior. Even the importance of object IDENTITY is affected in some sense: for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed. This seems to be saying that two immutable objects are (in some sense) the same iff they have the same type and … [View More]

2 1

c.l.p.announce
by David Ascher May 12, 2000

May 12, 2000

What's the status of comp.lang.python.announce and the 'reviving' thereof? --david

5 5

Unicode and its partners...
by M.-A. Lemburg May 12, 2000

May 12, 2000

It got a little silent around the 7-bit vs. 8-bit vs. UTF-8 discussion. Not that I would like it to restart (I think everybody has made their point), but it kind of surprised me that now with the ability to actually set the default string encoding at run-time, noone seems to have played around with it... >>> import sys >>> sys.set_string_encoding('unicode-escape') >>> "abcäöü" + u"abc" u'abc\344\366\374abc' >>> "abcäöü\u1234" + u"abc" u'abc\344\366\374\… [View More]

2 1

Re: [Patches] fix float_hash and complex_hash for 64-bit *nix
by Trent Mick May 11, 2000

May 11, 2000

On Wed, May 10, 2000 at 12:53:16AM -0400, Tim Peters wrote: > [Trent Mick] > > Discussion: > > > > Okay, it is debatable to call float_hash and complex_hash broken, > > but their code presumed that sizeof(long) was 32-bits. As a result > > the hashed values for floats and complex values were not the same > > on a 64-bit *nix system as on a 32-bit *nix system. With this > > patch they are. > > The goal is laudable but the analysis seems flawed. … [View More] For example, this new > comment: Firstly, I should have admitted my ignorance with regards to hash functions. > Looks to me like the real problem in the original was here: > > x = hipart + (long)fractpart + (long)intpart + (expo << 15); > ^^^^^^^^^^^^^ > > The difficulty is that intpart may *not* fit in 32 bits, so the cast of > intpart to long is ill-defined when sizeof(long) == 4. > > That is, the hash function truly is broken for "large" values with a > fractional part, and I expect your after-patch code suffers the same > problem: Yes it did. > The > solution to this is to break intpart in this branch into pieces no larger > than 32 bits too Okay here is another try (only for floatobject.c) for discussion. If it looks good then I will submit a patch for float and complex objects. So do the same for 'intpart' as was done for 'fractpart'. static long float_hash(v) PyFloatObject *v; { double intpart, fractpart; long x; fractpart = modf(v->ob_fval, &intpart); if (fractpart == 0.0) { // ... snip ... } else { int expo; long hipart; fractpart = frexp(fractpart, &expo); fractpart = fractpart * 2147483648.0; hipart = (long)fractpart; fractpart = (fractpart - (double)hipart) * 2147483648.0; x = hipart + (long)fractpart + (expo << 15); /* combine the fract parts */ intpart = frexp(intpart, &expo); intpart = intpart * 2147483648.0; hipart = (long)intpart; intpart = (intpart - (double)hipart) * 2147483648.0; x += hipart + (long)intpart + (expo << 15); /* add in the int parts */ } if (x == -1) x = -2; return x; } > Note this consequence under the Win32 Python: With this change, on Linux32: >>> base = 2.**40 + 0.5 >>> base 1099511627776.5 >>> for i in range(32, 45): ... x = base + 2.**i ... print x, hash(x) ... 1.10380659507e+12 -2141945856 1.10810156237e+12 -2137751552 1.11669149696e+12 -2129362944 1.13387136614e+12 -2112585728 1.16823110451e+12 -2079031296 1.23695058125e+12 -2011922432 1.37438953472e+12 -1877704704 1.64926744166e+12 -1609269248 2.19902325555e+12 -2146107392 3.29853488333e+12 -1609236480 5.49755813888e+12 -1877639168 9.89560464998e+12 -2011824128 1.86916976722e+13 -2078900224 On Linux64: >>> base = 2.**40 + 0.5 >>> base 1099511627776.5 >>> for i in range(32, 45): ... x = base + 2.**i ... print x, hash(x) ... 1.10380659507e+12 2153021440 1.10810156237e+12 2157215744 1.11669149696e+12 2165604352 1.13387136614e+12 2182381568 1.16823110451e+12 2215936000 1.23695058125e+12 2283044864 1.37438953472e+12 2417262592 1.64926744166e+12 2685698048 2.19902325555e+12 2148859904 3.29853488333e+12 2685730816 5.49755813888e+12 2417328128 9.89560464998e+12 2283143168 1.86916976722e+13 2216067072 >-- and that should also fix your 64-bit woes "by magic". > As you can see it did not, but for another reason. The summation of the parts overflows 'x'. Is this a problem? I.e., does it matter if a hash function returns an overflowed integral value (my hash function ignorance is showing)? And if this does not matter, does it matter that a hash returns different values on different platforms? > a hash function should never ignore any bit in its input. Which brings up a question regarding instance_hash(), func_hash(), meth_hash(), HKEY_hash() [or whatever it is called], and other which cast a pointer to a long (discarding the upperhalf of the pointer on Win64). Do these really need to be fixed. Am I nitpicking too much on this whole thing? Thanks, Trent -- Trent Mick trentm(a)activestate.com [View Less]

3 3

testing the C API in the test suite (was: bug in PyLong_FromLongLong (PR#324))
by Trent Mick May 11, 2000

May 11, 2000

> Date: Wed, 10 May 2000 15:37:30 -0400 > From: Thomas.Malik(a)t-online.de > To: python-bugs-list(a)python.org > cc: bugs-py(a)python.org > Subject: [Python-bugs-list] bug in PyLong_FromLongLong (PR#324) > > Full_Name: Thomas Malik > Version: 1.5.2 > OS: all > Submission from: p3e9ed447.dip.t-dialin.net (62.158.212.71) > > > there's a bug in PyLong_FromLongLong, resulting in truncation of negative 64 bi > t > integers. … [View More]PyLong_FromLongLong starts with: > if( ival <= (LONG_LONG)LONG_MAX ) { > return PyLong_FromLong( (long)ival ); > } > else if( ival <= (unsigned LONG_LONG)ULONG_MAX ) { > return PyLong_FromUnsignedLong( (unsigned long)ival ); > } > else { > .... > > Now, if ival is smaller than -LONG_MAX, it falls outside the long integer range > (being a 64 bit negative integer), but gets handled by the first if-then-case i > n > above code ('cause it is, of course, smaller than LONG_MAX). This results in > truncation of the 64 bit negative integer to a more or less arbitrary 32 bit > number. The way to fix it is to compare the absolute value of imax against > LONG_MAX in the first condition. The second condition (ULONG_MAX) must, at > least, check wether ival is positive. > To test this error I found the easiest way was to make a C extension module to Python that called the C API functions under test directly. I can't quickly think of a way I could have shown this error *clearly* at the Python level without a specialized extension module. This has been true for other things that I have been testing. Would it make sense to create a standard extension module (called '__test' or something like that) in which direct tests on the C API could be made? This would be hooked into the standard testsuite via a test_capi.py that would: - import __test - run every exported function in __test (or everyone starting with 'test_', or whatever) - the ImportError could continue to be used to signify skipping, etc (although, I think that a new, more explicit TestSuiteError class would be more appropriate and clear) Does something like this already exist that I am missing? This would make testing some things a lot easier, and clearer. Where some interface is exposed to the Python programmer it is appropriate to test it at the Python level. Python also provides a C API and it would be appropriate to test that at the C level. I would like to hear some people's thoughts before I go off and put anything together. Thanks, Trent -- Trent Mick trentm(a)activestate.com [View Less]

1 0