Mailman 3 May 2000 - Python-Dev

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

15 May '00

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 code were already broken. on the other hand: >>> array.array("H", [65535]) Traceback (most recent call last): File "<stdin>", line 1, in ? OverflowError: signed short integer is greater than maximum oops. dunno if the right thing would be to add support for various kinds of unsigned integers to Python/getargs.c, or to hack around this in the array module... </F>

2 1

cvs for dummies
by Fredrik Lundh 15 May '00

15 May '00

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 13 May '00

13 May '00

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 13 May '00

13 May '00

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 cStringIO doesn't work under e.g. Gordon's installer?) </F>

3 3

Landmark
by M.-A. Lemburg 12 May '00

12 May '00

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/ Python Pages: http://www.lemburg.com/python/

3 5

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

12 May '00

>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 value, while two mutable objects are the same iff they have the same id(). I heartily agree, and I think that this notion of sameness is the single most useful variant of the "equals" relation. Indeed, I think it worthwhile to consider modifying the "is" operator to compute this notion of sameness. (This would break only exceedingly strange user code.) "is" would then be the natural comparator of dictionary keys, which could then be any object. The usefulness of this idea is limited by the absence of user-definable immutable instances. It might be nice to be able to declare a class -- eg, Point -- to be have immutable instances. This declaration would promise that: 1. When the expression Point(3.0,4.0) is evaluated, its reference count will be zero. 2. After Point(3.0,4.0) is evaluated, its attributes will not be changed. I sent the above thoughts to Guido, who graciously and politely responded that they struck him as somewhere between bad and poorly presented. (Which surprised me. I would have guessed that the ideas were already in his head.) Nevertheless, he mentioned passing them along to you, so I have. Regards, Greg

2 1

c.l.p.announce
by David Ascher 12 May '00

12 May '00

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

5 5

Unicode and its partners...
by M.-A. Lemburg 12 May '00

12 May '00

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\u1234abc' >>> print "abcäöü\u1234" + u"abc" abc\344\366\374\u1234abc Any takers ? BTW, has anyone tried to use the codec design for other tasks than converting text ? It should also be usable for e.g. compressing/decompressing or other data oriented content. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

2 1

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

11 May '00

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. 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

3 3

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

11 May '00

> 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. 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

1 0