Re: [Python-Dev] Re: marshal / unmarshal
My mail is experincing random delays of up to a few hours at the moment. I wrote this before I saw your comments on my patch. Tim Peters [EMAIL PROTECTED] writes: [Michael Hudson] I've just submitted http://python.org/sf/1180995 which adds format codes for binary marshalling of floats if version 1, but it doesn't quite have the effect I expected (see below): inf = 1e308*1e308 nan = inf/inf marshal.dumps(nan, 2) Traceback (most recent call last): File stdin, line 1, in ? ValueError: unmarshallable object I don't understand. Does binary marshalling _not_ mean just copying the bytes on a 754 platform? No, it means using _PyFloat_Pack8/Unpack8, like the patch description says. Making those functions just fiddle bytes when they can I regard as a separate project (watch a patch manager near you, though). If so, that won't work. I can tell! wink Right. Assuming source and destination boxes both use 754 format, and the implementation adjusts endianess if necessary. Well, I was assuming marshal would do floats little-endian-wise, as it does for integers. Then on a big-endian 754 system, loads() will have to reverse the bytes in the little-endian marshal bytestring, and dumps() likewise. Really? Even I had worked this out... Heh. I have a vague half-memory of _some_ box that stored the two 4-byte words in an IEEE double in one order, but the bytes within each word in the opposite order. It's always something ... I recall stories of machines that stored the bytes of long in some crazy order like that. I think Python would already be broken on such a system, but, also, don't care. Python does very little that depends on internal native byte order, and C hides it in the absence of casting abuse. This surely does: PyObject * PyLong_FromLongLong(PY_LONG_LONG ival) { PY_LONG_LONG bytes = ival; int one = 1; return _PyLong_FromByteArray( (unsigned char *)bytes, SIZEOF_LONG_LONG, IS_LITTLE_ENDIAN, 1); } It occurs that in the IEEE case, special values can be detected with reliablity -- by picking the exponent field out by force -- and a warning emitted or exception raised. Good idea? Hard to say, to me. Cheers, mwh Oh, by the way: http://python.org/sf/1181301 -- It is time-consuming to produce high-quality software. However, that should not alone be a reason to give up the high standards of Python development. -- Martin von Loewis, python-dev ___ 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] Re: marshal / unmarshal
... [mwh] I recall stories of machines that stored the bytes of long in some crazy order like that. I think Python would already be broken on such a system, but, also, don't care. [Tim] Python does very little that depends on internal native byte order, and C hides it in the absence of casting abuse. [mwh] This surely does: PyObject * PyLong_FromLongLong(PY_LONG_LONG ival) { PY_LONG_LONG bytes = ival; int one = 1; return _PyLong_FromByteArray( (unsigned char *)bytes, SIZEOF_LONG_LONG, IS_LITTLE_ENDIAN, 1); } Yes, that's casting abuse'. Python does very little of that. If it becomes necessary, it's straightforward but long-winded to rewrite the above in wholly portable C (peel the bytes out of ival, least-signficant first, via shifting and masking 8 times; ival 0xff is the least-significant byte regardless of memory storage order; etc). BTW, the IS_LITTLE_ENDIAN macro also relies on casting abuse, and more deeply than does the visible cast there. It occurs that in the IEEE case, special values can be detected with reliablity -- by picking the exponent field out by force Right, that works for NaNs and infinities; signed zeroes are a bit trickier to detect. -- and a warning emitted or exception raised. Good idea? Hard to say, to me. It's not possible to _create_ a NaN or infinity from finite operands in 754 without signaling some exceptional condition. Once you have one, though, there's generally nothing exceptional about _using_ it. Sometimes there is, like +Inf - +Inf or Inf / Inf, but not generally. Using a quiet NaN never signals; using a signaling NaN almost always signals. So packing a nan or inf shouldn't complain. On a 754 box, unpacking one shouldn't complain either. Unpacking a nan or inf on a non-754 box probably should complain, since there's in general nothing it can be unpacked _to_ that makes any sense (errors should never pass silently). ___ 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] Re: marshal / unmarshal
Tim Peters [EMAIL PROTECTED] writes: ... [mwh] I recall stories of machines that stored the bytes of long in some crazy order like that. I think Python would already be broken on such a system, but, also, don't care. [Tim] Python does very little that depends on internal native byte order, and C hides it in the absence of casting abuse. [mwh] This surely does: PyObject * PyLong_FromLongLong(PY_LONG_LONG ival) { PY_LONG_LONG bytes = ival; int one = 1; return _PyLong_FromByteArray( (unsigned char *)bytes, SIZEOF_LONG_LONG, IS_LITTLE_ENDIAN, 1); } Yes, that's casting abuse'. Python does very little of that. If it becomes necessary, it's straightforward but long-winded to rewrite the above in wholly portable C (peel the bytes out of ival, least-signficant first, via shifting and masking 8 times; ival 0xff is the least-significant byte regardless of memory storage order; etc). Not arguing with that. BTW, the IS_LITTLE_ENDIAN macro also relies on casting abuse, and more deeply than does the visible cast there. I'd like to claim that was part of my point :) There is a certain, small level of assumption in Python that big-endian or little-endian is the only question to ask -- and I don't think that's a problem! Even in this isn't a big deal, at least if we choose a more interesting 'probe value' that 1.5, it will just lead to an oddball box degrading to the non-ieee code. It occurs that in the IEEE case, special values can be detected with reliablity -- by picking the exponent field out by force Right, that works for NaNs and infinities; signed zeroes are a bit trickier to detect. Hmm. Don't think they're such a big deal. -- and a warning emitted or exception raised. Good idea? Hard to say, to me. It's not possible to _create_ a NaN or infinity from finite operands in 754 without signaling some exceptional condition. Once you have one, though, there's generally nothing exceptional about _using_ it. Sometimes there is, like +Inf - +Inf or Inf / Inf, but not generally. Using a quiet NaN never signals; using a signaling NaN almost always signals. So packing a nan or inf shouldn't complain. On a 754 box, unpacking one shouldn't complain either. Unpacking a nan or inf on a non-754 box probably should complain, since there's in general nothing it can be unpacked _to_ that makes any sense (errors should never pass silently). This sounds like good behaviour to me. I'll try to update the patch soon. Cheers, mwh -- BUGS Never use this function. This function modifies its first argument. The identity of the delimiting character is lost. This function cannot be used on constant strings. -- the glibc manpage for strtok(3) ___ 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] args attribute of Exception objects
[Sébastien de Menten] 2) Could this be changed to .args more in line with: a) first example: e.args = ('foo', NameError: name 'foo' is not defined) b) second example: e.args = (4, 'foo', 'int' object has no attribute 'foo',) the message of the string can even be retrieved with str(e) so it is also redundant. Something like this ought to be explored at some point. It would certainly improve the exception API to be able to get references to the objects without parsing strings. The balancing forces are backwards compatibility and a need to keep the exception mechanism as lightweight as possible. Please log a feature request on SF. Note that the idea is only for making builtin exceptions more informative. User defined exceptions can already attach arbitrary objects: class Boom(Exception): pass x = 10 if x != 5: raise Boom(Value must be a five, x) Traceback (most recent call last): File pyshell#12, line 2, in -toplevel- raise Boom(Value must be a five, x) Boom: ('Value must be a five', 10) Raymond Hettinger ___ 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