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 "", 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!
>>> 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 "", 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
[Python-Dev] Python tests fails on HP-UX 11.11 and core dumps
Hello Experts,
I tried
python -4.2.1 on a HP-UX 11.11 PA machine. I was able to
python. Gmake passes, gmake test results in
error. The python reported
that test_pty fails,when running this
test alone.
Can anyone help to find why core dumps at running
the test_subprocess.py test.
Also how can I solve it?
Have anyone faced the same problem
earlier.
The details are given below;
# ../../python
test_pty.pyCalling master_open()Got master_fd '3', slave_name
'/dev/pts/0'Calling slave_open('/dev/pts/0')Got slave_fd
'4'Traceback (most recent call last): File "test_pty.py", line 58,
in ? test_basic_pty() File "test_pty.py", line
29, in test_basic_pty if not
os.isatty(slave_fd): File "test_pty.py", line 50, in
handle_sig raise TestFailed, "isatty
hung"test.test_support.TestFailed: isatty hung#
# ../../python
test_subprocess.pytest_args_string (__main__.ProcessTestCase) ...
oktest_call_kwargs (__main__.ProcessTestCase) ... oktest_call_seq
(__main__.ProcessTestCase) ... oktest_call_string (__main__.ProcessTestCase)
... oktest_communicate (__main__.ProcessTestCase) ...
oktest_communicate_pipe_buf (__main__.ProcessTestCase) ...
oktest_communicate_returns (__main__.ProcessTestCase) ... oktest_cwd
(__main__.ProcessTestCase) ... oktest_env (__main__.ProcessTestCase) ...
oktest_exceptions (__main__.ProcessTestCase) ... oktest_executable
(__main__.ProcessTestCase) ... oktest_invalid_args
(__main__.ProcessTestCase) ... oktest_invalid_bufsize
(__main__.ProcessTestCase) ... oktest_list2cmdline
(__main__.ProcessTestCase) ... oktest_no_leaking (__main__.ProcessTestCase)
... oktest_poll (__main__.ProcessTestCase) ... oktest_preexec
(__main__.ProcessTestCase) ... oktest_run_abort (__main__.ProcessTestCase)
... oktest_shell_sequence (__main__.ProcessTestCase) ...
oktest_shell_string (__main__.ProcessTestCase) ... oktest_stderr_filedes
(__main__.ProcessTestCase) ... oktest_stderr_fileobj
(__main__.ProcessTestCase) ... oktest_stderr_none (__main__.ProcessTestCase)
... oktest_stderr_pipe (__main__.ProcessTestCase) ...
oktest_stdin_filedes (__main__.ProcessTestCase) ... oktest_stdin_fileobj
(__main__.ProcessTestCase) ... oktest_stdin_none (__main__.ProcessTestCase)
... oktest_stdin_pipe (__main__.ProcessTestCase) ...
oktest_stdout_filedes (__main__.ProcessTestCase) ...
oktest_stdout_fileobj (__main__.ProcessTestCase) ...
ok this bit of output is from a test of stdout in
a different process ...test_stdout_none (__main__.ProcessTestCase)
... oktest_stdout_pipe (__main__.ProcessTestCase) ...
oktest_stdout_stderr_file (__main__.ProcessTestCase) ...
oktest_stdout_stderr_pipe (__main__.ProcessTestCase) ...
oktest_universal_newlines (__main__.ProcessTestCase) ...
oktest_universal_newlines_communicate (__main__.ProcessTestCase) ...
oktest_wait (__main__.ProcessTestCase) ...
oktest_writes_before_communicate (__main__.ProcessTestCase) ...
ok
--Ran
38 tests in 8.171s
Analysing the core file through GDB;
# gdb ../../python coreHP gdb 4.5 for PA-RISC
1.1 or 2.0 (narrow), HP-UX 11.00and target
hppa1.1-hp-hpux11.00.Copyright 1986 - 2001 Free Software Foundation,
Inc.Hewlett-Packard Wildebeest 4.5 (based on GDB) is covered by theGNU
General Public License. Type "show copying" to see the conditions tochange
it and/or distribute copies. Type "show warranty" for
warranty/support...Core was generated by `python'.Program terminated
with signal 6, Aborted.#0 0xc020bad0 in kill+0x10 () from
/usr/lib/libc.2(gdb) bt#0 0xc020bad0 in kill+0x10 () from
/usr/lib/libc.2#1 0xc01a655c in raise+0x24 () from
/usr/lib/libc.2#2 0xc01e69a8 in abort_C+0x160 () from
/usr/lib/libc.2#3 0xc01e6a04 in abort+0x1c () from
/usr/lib/libc.2#4 0xffbe4 in posix_abort (self=0x40029098, noargs=0x0)
at ./Modules/posixmodule.c:7158#5 0xc9b7c in PyEval_EvalFrame
(f=0x40028e54) at Python/ceval.c:3531#6 0xc01a655c in raise+0x24 ()
from /usr/lib/libc.2#7 0x475b0 in freechildren (n=0x0) at
Parser/node.c:131(gdb)
Build Environment;
GCC - gcc version 3.4.3
HP-UX omega B.11.11 U 9000/800
./configure --prefix=/opt/iexpress/python
--disable-ipv6 --with-signal-module --with-threads
Earlier, I faced problem while gmake, and make
changes as per the following link;
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_id=5470
And I was able to build Python
succesfully.
Also, the overall result of tests
are;
250 tests OK.1 test
failed: test_pty39 tests
skipped: test_aepack test_al test_applesingle test_bsddb
test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl
test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
test_codecmaps_kr test_codecmaps_tw test_curses test_dl
test_gdbm test_gl test_imgfile test_largefile
test_linuxaudiodev test_locale test_macfs test_macostools
test_nis test_normalization test_ossaudiodev test_pep277
test_plistlib test_scriptpackages test_soc
