Mailman 3 June 2003 - pypy-dev

Profiling results
by Michael Hudson 13 Jun '03

13 Jun '03

Armin and I are on IRC talking about mhy my new types module takes so long to load and this is a bit big for that medium :-) >>> profile.run("main.run_string('import types', '', space)") the slice is empty 1167131 function calls (876696 primitive calls) in 36.760 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 36.760 36.760 <string>:1(?) 4 0.000 0.000 0.000 0.000 appfile.py:38(__init__) 44 0.000 0.000 0.380 0.009 appfile.py:45(get) 44/1 0.000 0.000 36.680 36.680 appfile.py:51(call) 4 0.000 0.000 0.090 0.022 appfile.py:58(runbytecode) 4 0.000 0.000 0.090 0.022 appfile.py:73(__init__) 208 0.060 0.000 0.180 0.001 baseobjspace.py:108(unpacktuple) 706 0.040 0.000 0.720 0.001 baseobjspace.py:122(exception_match) 2 0.000 0.000 0.020 0.010 baseobjspace.py:154(call_function) 3 0.000 0.000 0.000 0.000 baseobjspace.py:37(get_builtin_module) 101 0.040 0.000 0.040 0.000 baseobjspace.py:49(getexecutioncontext) 44 0.010 0.000 0.100 0.002 baseobjspace.py:61(gethelper) 22094 2.340 0.000 16.390 0.001 baseobjspace.py:74(is_) 22362 0.180 0.000 0.180 0.000 baseobjspace.py:80(newbool) 197 0.060 0.000 0.610 0.003 baseobjspace.py:86(unpackiterable) 44367 0.350 0.000 0.350 0.000 boolobject.py:27(bool_is_true) 31 0.000 0.000 0.010 0.000 builtin.py:103(len) 1 0.000 0.000 0.010 0.010 builtin.py:112(getattr) 58 0.000 0.000 0.080 0.001 builtin.py:139(issubclass) 3/1 0.000 0.000 36.600 36.600 builtin.py:36(__import__) 3 0.000 0.000 0.000 0.000 builtin.py:71(compile) 32 0.000 0.000 0.000 0.000 cpythonobject.py:131(cpython_f) 56 0.000 0.000 0.040 0.001 cpythonobject.py:139(cpython_f) 121 0.000 0.000 0.000 0.000 cpythonobject.py:20(cpython_unwrap) 52 0.000 0.000 0.000 0.000 cpythonobject.py:8(__init__) 44158 1.780 0.000 3.480 0.000 default.py:37(default_id) 7 0.000 0.000 0.010 0.001 default.py:46(default_not) 38 0.000 0.000 0.010 0.000 default.py:64(default_inplace) 810 0.010 0.000 0.010 0.000 dictobject.py:10(__init__) 8 0.000 0.000 0.000 0.000 dictobject.py:109(len_dict) 1783 0.030 0.000 0.040 0.000 dictobject.py:13(get) 452 0.010 0.000 0.010 0.000 dictobject.py:18(set) 7 0.000 0.000 0.000 0.000 dictobject.py:21(make_empty) 42721 0.270 0.000 0.270 0.000 dictobject.py:26(is_empty) 475 0.080 0.000 0.270 0.001 dictobject.py:38(__init__) 2436 0.580 0.000 0.840 0.000 dictobject.py:47(non_empties) 452 0.040 0.000 0.350 0.001 dictobject.py:51(_cell) 240 0.010 0.000 0.010 0.000 dictobject.py:71(dict_is_true) 2181 1.350 0.001 30.100 0.014 dictobject.py:84(getitem_dict_any) 452 0.030 0.000 0.390 0.001 dictobject.py:93(setitem_dict_any_any) 7 0.000 0.000 0.170 0.024 dictobject.py:99(delitem_dict_any) 4 0.000 0.000 0.000 0.000 executioncontext.py:18(get_w_builtins) 197 0.000 0.000 0.000 0.000 executioncontext.py:202(__init__) 2948 0.030 0.000 0.030 0.000 executioncontext.py:205(push) 2948 0.030 0.000 0.030 0.000 executioncontext.py:208(pop) 434 0.000 0.000 0.000 0.000 executioncontext.py:211(top) 110 0.000 0.000 0.000 0.000 executioncontext.py:216(depth) 142 0.010 0.000 0.010 0.000 executioncontext.py:219(empty) 4 0.000 0.000 0.000 0.000 executioncontext.py:24(make_standard_w_globals) 8 0.000 0.000 0.000 0.000 executioncontext.py:31(exception_trace) 1 0.000 0.000 0.000 0.000 executioncontext.py:5(__init__) 804 0.010 0.000 0.010 0.000 executioncontext.py:56(__init__) 8 0.000 0.000 0.000 0.000 executioncontext.py:62(record_application_traceback) 698 0.050 0.000 0.890 0.001 executioncontext.py:65(match) 8 0.000 0.000 0.000 0.000 executioncontext.py:88(record_interpreter_traceback) 98/1 0.010 0.000 36.730 36.730 executioncontext.py:9(eval_frame) 93/1 0.010 0.000 36.600 36.600 extmodule.py:40(eval_code) 3 0.000 0.000 0.000 0.000 extmodule.py:7(__get__) 62 0.000 0.000 0.000 0.000 funcobject.py:11(__init__) 215/1 0.010 0.000 36.670 36.670 funcobject.py:35(func_call) 44 0.000 0.000 0.010 0.000 funcobject.py:47(func_get) 1 0.000 0.000 0.010 0.010 funcobject.py:52(func_getattr) 42/25 0.000 0.000 14.460 0.578 instmethobject.py:31(instmeth_call) 44 0.010 0.000 0.010 0.000 instmethobject.py:9(__init__) 31 0.000 0.000 0.000 0.000 intobject.py:102(int_int_gt) 15 0.000 0.000 0.000 0.000 intobject.py:108(int_int_ge) 61 0.010 0.000 0.010 0.000 intobject.py:141(int_int_add) 46 0.010 0.000 0.010 0.000 intobject.py:153(int_int_sub) 23 0.000 0.000 0.000 0.000 intobject.py:177(int_int_floordiv) 46676 1.490 0.000 1.810 0.000 intobject.py:26(__init__) 39 0.000 0.000 0.000 0.000 intobject.py:323(int_is_true) 16 0.000 0.000 0.000 0.000 intobject.py:385(int_int_and) 1167 0.010 0.000 0.010 0.000 intobject.py:46(int_unwrap) 114 0.000 0.000 0.000 0.000 intobject.py:78(int_int_lt) 23 0.000 0.000 0.000 0.000 intobject.py:84(int_int_le) 22102 0.370 0.000 0.550 0.000 intobject.py:90(int_int_eq) 393 0.010 0.000 0.470 0.001 iterobject.py:22(next_seqiter) 205 0.000 0.000 0.000 0.000 iterobject.py:8(__init__) 8 0.000 0.000 0.000 0.000 listobject.py:109(list_int_mul) 20 0.000 0.000 0.000 0.000 listobject.py:13(__init__) 15 0.000 0.000 0.000 0.000 listobject.py:166(setitem_list_int) 19 0.000 0.000 0.000 0.000 listobject.py:211(_roundupsize) 29 0.000 0.000 0.000 0.000 listobject.py:260(_list_resize) 2 0.000 0.000 0.010 0.005 listobject.py:35(list_unwrap) 16 0.000 0.000 0.000 0.000 listobject.py:52(getitem_list_int) 8 0.000 0.000 0.000 0.000 listobject.py:84(list_iter) 1 0.000 0.000 0.000 0.000 listobject.py:90(list_add) 1 0.000 0.000 36.760 36.760 main.py:7(run_string) 7 0.000 0.000 0.060 0.009 moduleobject.py:21(getattr_module_any) 2 0.000 0.000 0.000 0.000 moduleobject.py:33(setattr_module_any_any) 3 0.000 0.000 0.010 0.003 moduleobject.py:9(__init__) 37 0.000 0.000 0.000 0.000 multimethod.py:103(is_empty) 140658 1.070 0.000 1.070 0.000 multimethod.py:109(__init__) 140654/53 6.020 0.000 36.720 0.693 multimethod.py:113(__call__) 4 0.000 0.000 0.000 0.000 multimethod.py:12(__init__) 140685/53 9.800 0.000 36.720 0.693 multimethod.py:136(perform_call) 33 0.000 0.000 0.000 0.000 multimethod.py:158(is_empty) 116 0.000 0.000 0.000 0.000 multimethod.py:24(register) 140788 3.330 0.000 4.400 0.000 multimethod.py:36(__get__) 4 0.000 0.000 0.000 0.000 multimethod.py:41(cache_dependency) 140685 1.380 0.000 1.560 0.000 multimethod.py:44(buildchoices) 3065/134 0.180 0.000 0.180 0.001 multimethod.py:56(internal_buildchoices) 4 0.000 0.000 0.000 0.000 multimethod.py:96(slicetable) 173 0.000 0.000 0.030 0.000 objectobject.py:120(object_type) 164 0.060 0.000 0.770 0.005 objectobject.py:28(object_getattr) 17 0.000 0.000 0.070 0.004 objectobject.py:74(object_setattr) 12 0.000 0.000 0.000 0.000 objecttype.py:14(objecttype_new) 52116 0.380 0.000 0.380 0.000 objspace.py:16(__init__) 389 0.010 0.000 0.030 0.000 objspace.py:173(get_typeinstance) 5405/5372 0.280 0.000 0.830 0.000 objspace.py:183(wrap) 79 0.000 0.000 0.000 0.000 objspace.py:19(get_builtin_impl_class) 378 0.040 0.000 0.060 0.000 objspace.py:215(newtuple) 11 0.000 0.000 0.000 0.000 objspace.py:219(newlist) 472 0.040 0.000 0.310 0.001 objspace.py:223(newdict) 16 0.000 0.000 0.000 0.000 objspace.py:227(newslice) 62 0.000 0.000 0.000 0.000 objspace.py:232(newfunction) 3 0.000 0.000 0.010 0.003 objspace.py:237(newmodule) 1 0.000 0.000 0.000 0.000 objspace.py:26(registerimplementation) 7 0.000 0.000 0.010 0.001 opcode.py:14(__call__) 15 0.000 0.000 4.590 0.306 opcode.py:140(slice) 7 0.000 0.000 2.060 0.294 opcode.py:149(SLICE_1) 8 0.000 0.000 2.530 0.316 opcode.py:153(SLICE_2) 31 0.000 0.000 0.040 0.001 opcode.py:205(STORE_SUBSCR) 190 0.010 0.000 0.120 0.001 opcode.py:23(__call__) 7 0.000 0.000 0.000 0.000 opcode.py:238(BREAK_LOOP) 1 0.000 0.000 3.780 3.780 opcode.py:244(RAISE_VARARGS) 2 0.000 0.000 0.000 0.000 opcode.py:271(LOAD_LOCALS) 97 0.000 0.000 0.000 0.000 opcode.py:274(RETURN_VALUE) 1 0.000 0.000 0.000 0.000 opcode.py:278(YIELD_VALUE) 14 0.000 0.000 0.000 0.000 opcode.py:297(POP_BLOCK) 2 0.000 0.000 0.020 0.010 opcode.py:313(BUILD_CLASS) 69 0.000 0.000 0.140 0.002 opcode.py:322(STORE_NAME) 7 0.000 0.000 0.170 0.024 opcode.py:328(DELETE_NAME) 1123 0.110 0.000 8.770 0.008 opcode.py:35(LOAD_FAST) 17 0.000 0.000 0.710 0.042 opcode.py:350(STORE_ATTR) 60 0.000 0.000 6.860 0.114 opcode.py:376(LOAD_NAME) 254 0.020 0.000 10.160 0.040 opcode.py:406(LOAD_GLOBAL) 49 0.000 0.000 0.010 0.000 opcode.py:477(BUILD_TUPLE) 350 0.030 0.000 0.070 0.000 opcode.py:48(LOAD_CONST) 11 0.010 0.001 0.010 0.001 opcode.py:483(BUILD_LIST) 8 0.000 0.000 0.000 0.000 opcode.py:489(BUILD_MAP) 156 0.020 0.000 0.610 0.004 opcode.py:495(LOAD_ATTR) 114 0.020 0.000 0.060 0.001 opcode.py:503(cmp_lt) 23 0.000 0.000 0.000 0.000 opcode.py:504(cmp_le) 8 0.000 0.000 0.000 0.000 opcode.py:505(cmp_eq) 31 0.010 0.000 0.010 0.000 opcode.py:507(cmp_gt) 15 0.000 0.000 0.000 0.000 opcode.py:508(cmp_ge) 62 0.000 0.000 0.010 0.000 opcode.py:514(cmp_is) 8 0.000 0.000 0.000 0.000 opcode.py:518(cmp_exc_match) 344 0.020 0.000 0.460 0.001 opcode.py:52(STORE_FAST) 261 0.000 0.000 0.090 0.000 opcode.py:534(COMPARE_OP) 3/1 0.000 0.000 36.730 36.730 opcode.py:544(IMPORT_NAME) 1 0.000 0.000 0.100 0.100 opcode.py:557(IMPORT_FROM) 104 0.000 0.000 0.000 0.000 opcode.py:564(JUMP_FORWARD) 374 0.070 0.000 0.180 0.000 opcode.py:567(JUMP_IF_FALSE) 15 0.000 0.000 0.000 0.000 opcode.py:572(JUMP_IF_TRUE) 23 0.000 0.000 0.000 0.000 opcode.py:577(JUMP_ABSOLUTE) 391 0.010 0.000 0.010 0.000 opcode.py:58(POP_TOP) 8 0.000 0.000 0.000 0.000 opcode.py:580(GET_ITER) 16 0.000 0.000 0.000 0.000 opcode.py:585(FOR_ITER) 17 0.000 0.000 0.000 0.000 opcode.py:599(SETUP_LOOP) 38 0.000 0.000 0.000 0.000 opcode.py:603(SETUP_EXCEPT) 164/1 0.010 0.000 36.610 36.610 opcode.py:611(call_function_extra) 156/1 0.000 0.000 36.610 36.610 opcode.py:637(CALL_FUNCTION) 8 0.000 0.000 15.470 1.934 opcode.py:640(CALL_FUNCTION_VAR) 30 0.010 0.000 0.030 0.001 opcode.py:649(MAKE_FUNCTION) 15 0.000 0.000 0.000 0.000 opcode.py:67(ROT_THREE) 1040 0.000 0.000 0.000 0.000 opcode.py:684(SET_LINENO) 5339 0.050 0.000 0.050 0.000 opcode.py:715(has_arg) 804/577 0.020 0.000 4.780 0.008 opcode.py:718(dispatch_noarg) 4535/6 0.140 0.000 36.730 6.122 opcode.py:726(dispatch_arg) 24 0.010 0.000 0.010 0.000 opcode.py:85(DUP_TOP) 6 0.000 0.000 0.000 0.000 posixpath.py:168(exists) 6 0.000 0.000 0.000 0.000 posixpath.py:44(join) 1 0.000 0.000 36.760 36.760 profile:0(main.run_string('import types', '', space)) 0 0.000 0.000 profile:0(profiler) 93/1 0.000 0.000 36.660 36.660 pycode.py:113(eval_code) 493 0.000 0.000 0.000 0.000 pycode.py:29(__init__) 215/153 0.080 0.000 13.660 0.089 pycode.py:37(build_arguments) 37 0.000 0.000 0.000 0.000 pycode.py:76(__init__) 37/7 0.000 0.000 0.000 0.000 pycode.py:91(_from_code) 55 0.000 0.000 0.000 0.000 pyframe.py:140(__init__) 55 0.000 0.000 0.000 0.000 pyframe.py:144(cleanupstack) 14 0.000 0.000 0.000 0.000 pyframe.py:148(cleanup) 7 0.000 0.000 0.000 0.000 pyframe.py:160(unroll) 34/12 0.000 0.000 24.180 2.015 pyframe.py:179(unroll) 98 0.000 0.000 4.690 0.048 pyframe.py:22(__init__) 112/30 0.010 0.000 24.180 0.806 pyframe.py:250(unrollstack) 97 0.000 0.000 0.000 0.000 pyframe.py:283(emptystack) 1 0.000 0.000 0.000 0.000 pyframe.py:291(unrollstack) 98/1 0.200 0.002 36.730 36.730 pyframe.py:33(eval) 14409 0.220 0.000 0.220 0.000 pyframe.py:70(nextop) 4535 0.180 0.000 0.290 0.000 pyframe.py:75(nextarg) 350 0.000 0.000 0.000 0.000 pyframe.py:80(getconstant) 1467 0.010 0.000 0.010 0.000 pyframe.py:83(getlocalvarname) 567 0.010 0.000 0.010 0.000 pyframe.py:86(getname) 98 0.010 0.000 4.690 0.048 pyframe.py:99(load_builtins) 4053 0.040 0.000 0.040 0.000 rarray.py:19(__init__) 4053 0.150 0.000 0.150 0.000 rarray.py:22(setvalue) 910 0.040 0.000 0.040 0.000 rarray.py:30(hash) 1239 0.000 0.000 0.000 0.000 rarray.py:35(value) 27946 0.210 0.000 0.210 0.000 rarray.py:43(charat) 4053 0.180 0.000 0.370 0.000 rarray.py:8(CharArrayFromStr) 16 0.000 0.000 0.000 0.000 restricted_int.py:104(__and__) 71 0.000 0.000 0.000 0.000 restricted_int.py:158(__new__) 30 0.000 0.000 0.000 0.000 restricted_int.py:161(__add__) 11 0.000 0.000 0.000 0.000 restricted_int.py:177(__mul__) 11 0.000 0.000 0.000 0.000 restricted_int.py:215(__lshift__) 84 0.000 0.000 0.000 0.000 restricted_int.py:22(__add__) 11 0.000 0.000 0.000 0.000 restricted_int.py:230(__rrshift__) 46 0.000 0.000 0.000 0.000 restricted_int.py:28(__sub__) 31 0.000 0.000 0.000 0.000 restricted_int.py:38(__mul__) 23 0.000 0.000 0.000 0.000 restricted_int.py:46(__div__) 8 0.000 0.000 0.000 0.000 restricted_int.py:76(__lshift__) 24 0.000 0.000 0.000 0.000 restricted_int.py:88(__rshift__) 16 0.000 0.000 0.000 0.000 sliceobject.py:13(__init__) 15 0.000 0.000 4.550 0.303 sliceobject.py:18(indices) 45 0.030 0.001 0.180 0.004 sliceobject.py:29(getattr_slice_any) 1 0.000 0.000 0.010 0.010 slicetype.py:9(slicetype_new) 329 0.010 0.000 0.010 0.000 stringobject.py:188(str_unwrap) 4053 0.100 0.000 0.500 0.000 stringobject.py:19(__init__) 910 0.030 0.000 0.110 0.000 stringobject.py:198(str_hash) 21284 2.040 0.000 21.370 0.001 stringobject.py:211(string_richcompare) 21284 0.490 0.000 21.860 0.001 stringobject.py:277(str_str_eq) 492 0.010 0.000 0.030 0.000 tupleobject.py:10(__init__) 8 0.000 0.000 0.000 0.000 tupleobject.py:29(tuple_is_true) 231 0.000 0.000 0.030 0.000 tupleobject.py:34(tuple_len) 860 0.020 0.000 0.060 0.000 tupleobject.py:40(getitem_tuple_int) 15 0.020 0.001 4.580 0.305 tupleobject.py:51(getitem_tuple_slice) 197 0.000 0.000 0.000 0.000 tupleobject.py:67(tuple_iter) 50 0.000 0.000 0.000 0.000 tupleobject.py:73(tuple_add) 8 0.000 0.000 0.080 0.010 tupletype.py:11(tupletype_new) 32 0.000 0.000 0.000 0.000 typeobject.py:109(getdefaults) 64 0.000 0.000 0.000 0.000 typeobject.py:116(slice) 31 0.010 0.000 0.610 0.020 typeobject.py:130(eval_code) 49/37 0.000 0.000 15.000 0.405 typeobject.py:157(type_call) 70 0.000 0.000 0.070 0.001 typeobject.py:164(type_issubtype) 36 0.000 0.000 0.100 0.003 typeobject.py:174(type_getattr) 6 0.030 0.005 0.040 0.007 typeobject.py:18(__init__) 454 0.000 0.000 0.000 0.000 typeobject.py:31(getbases) 538/238 0.040 0.000 0.440 0.002 typeobject.py:39(getmro) 145 0.010 0.000 0.780 0.005 typeobject.py:47(lookup) 233 0.030 0.000 0.110 0.000 typeobject.py:57(lookup_exactly_here) 18 0.000 0.000 0.000 0.000 typeobject.py:69(acceptclass) 13 0.000 0.000 0.000 0.000 typeobject.py:89(hack_out_multimethods) 456 0.010 0.000 0.010 0.000 typeobject.py:96(__init__) 16 0.000 0.000 0.100 0.006 typetype.py:13(typetype_new) 1 0.010 0.010 0.010 0.010 userobject.py:1(?) 12 0.000 0.000 0.140 0.012 userobject.py:20(__init__) 31 0.000 0.000 0.000 0.000 userobject.py:52(get_builtin_impl_class) 12 0.000 0.000 0.090 0.008 userobject.py:59(getsinglebuiltintype) 1 0.000 0.000 0.000 0.000 userobject.py:6(W_UserObject) 15 0.010 0.001 0.010 0.001 userobject.py:74(user_type) 30 0.000 0.000 0.000 0.000 userobject.py:80(user_getdict) 62 0.000 0.000 0.000 0.000 userobject.py:92(build_user_operation) 31 0.000 0.000 1.290 0.042 userobject.py:93(user_operation) 2 0.000 0.000 0.020 0.010 usertype.py:15(__init__) 149 0.010 0.000 0.400 0.003 usertype.py:25(getbases) 94 0.000 0.000 0.380 0.004 usertype.py:32(lookup_exactly_here) 12 0.010 0.001 14.790 1.232 usertype.py:45(usertype_new) -- Hey, if I thought I was wrong, I'd change my mind. :) -- Grant Edwards, comp.lang.python

1 0

Re: deep breakage
by Guido van Rossum 12 Jun '03

12 Jun '03

> From: Armin Rigo <arigo(a)tunes.org> > To: Michael Hudson <mwh(a)python.net> > Subject: Re: [pypy-dev] [gmane.comp.python.pypy] deep breakage > > Hello Michael, > > On Sat, Jun 07, 2003 at 08:38:32PM +0100, Michael Hudson wrote: > > try: > > "x" + 1 > > except TypeError, e: > > raise e > > > > because here 'e' gets bound to a *string* and then this is what's > > reraised. This is of course false. e gets a TypeError instance (or at least that's what it does in CPython, and what it should do). > This is the same problem as in CPython. Most failing internal > operations call PyErr_SetString(), which causes a string to be used > as the exception value. No, as the argument to the exception constructor. > The hack is that when the user code reaches an 'except' clauses the > exception is "normalized", which translates the pair "TypeError > class + string" into the pair "TypeError class + TypeError > instance". Right, and for all practical purposes, raise TypeError, "foo" is the same as raise TypeError("foo") > We might either choose to mimic this behavior or clean it up a bit, > e.g. by always using internally a single object as the exception > instance. That's fine. CPython uses the pair so that for certain exceptions raised *internally* (by C code, not by raise statements) the instantiation is never done if the exception is caught and cleared by C code further down the stack. For example, when iterating over a built-in sequence, the StopIteration exception is raised but never instantiated. > String exceptions are being deprecated, but still we could > reasonably emulate them, say by inventing a StringException > class. This would isolate the hacky parts around this specific class > (like setting sys.exc_type to something else than > current_exception.__class__ for this particular case). I would not even bother. String exceptions are strongly deprecated part of the language. --Guido van Rossum (home page: http://www.python.org/~guido/)

2 2

OSCON paper
by Laura Creighton 12 Jun '03

12 Jun '03

What do you all suggest I report? Due Wednesday, but will of course be revised to cover what we do between now and OSCON (July 7-11). Laura

1 0

RE: [pypy-dev] Re: Objects and types in the stdobjspace
by roccomoretti＠netscape.net 12 Jun '03

12 Jun '03

Michael Hudson <mwh(a)python.net> wrote: >roccomoretti(a)netscape.net (Rocco Moretti) writes: >> Secondly, the testing framework as written will only run tests at the >> interpreter level. Some tests (such as test_exceptcomp and test_exec) >> should be run at the application level. > >Yes. I don't see how to easily and gracefully allow this. Naming convention? test_excptcomp_app.py and test_exec_app.py for example? >Hmm, maybe. regrtest has become somewhat crufty over the years, I >don't think we need all of it. In a way, I'd prefer to keep things >within the unittest framework if possible regrtest has provisions for working with unittest files, and if we want to work with the CPython regression tests, we need to deal with regrtest in some fashion anyway. (But I agree - regrtest is intimidating to work with.) >(although working closely >with it for the first time has made its Java heritage unpleasantly >clear...). How so? >We also need a LOT more tests! Like what? (Knowing what to test is 73.495% of the battle [+- 50%]) >> And in keeping with my rearranging mood, I think main.py should >> probably be placed in the pypy/ directory. > >Hmm. Maybe, or maybe the executable that people actually run will >look like this: > >#!/usr/bin/python >from pypy.interpreter import main >main.main() I think: #!/usr/bin/python from pypy import main main.main() is a bit cleaner, especially if we start to expand into the realm of multiple BytecodeSpaces/ExecutionSpaces (i.e. if interpreter becomes std_interpreter) >Thanks, I think we really moved things forward. Are you able to come >to the next sprint? Unfortunately no, I'm not able to travel at this time. (Too busy.) -Rocco __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

2 2

Re: [pypy-dev] Objects and types in the stdobjspace
by roccomoretti＠netscape.net 10 Jun '03

10 Jun '03

holger krekel <hpk(a)trillke.net> wrote: >Btw, I don't like the duplicated testsupport.py files. I think Rocco already >suggested to put one version into a fixed place which i agree too. >pypy.test.support seems like a canonical place. The one problem with that is if you are sitting in /norwegian/blue/pypy/interpreter/test, and '/norwegian/blue/' isn't on your PYTHONPATH, you choke on trying to import pypy.test.support. One of the main reasons (that I see, at least) for testsupport is that by doing a relative 'import testsupport', it automagically massages your PYTHONPATH such that 'from pypy...' imports work. But I agree that it probably should be pared down to a stub, and it looks like someone (mwh?) has already started that by moving a bunch of code to testtools.py My suggestion was to move all the other files for general test support (unittest_w.py, testtools.py etc) to a single directory, to leave the main directory and the interpreter directory relatively uncluttered. >Filename completions >on "te<tab>" should result in "test_" :-) Could we rename it 'support_tests.py'? -Rocco __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

2 1

Re: deep breakage
by Guido van Rossum 09 Jun '03

09 Jun '03

> From: Armin Rigo <arigo(a)tunes.org> > To: Michael Hudson <mwh(a)python.net> > Subject: Re: [pypy-dev] [gmane.comp.python.pypy] deep breakage > > Hello Michael, > > On Sat, Jun 07, 2003 at 08:38:32PM +0100, Michael Hudson wrote: > > try: > > "x" + 1 > > except TypeError, e: > > raise e > > > > because here 'e' gets bound to a *string* and then this is what's > > reraised. This is of course false. e gets a TypeError instance (or at least that's what it does in CPython, and what it should do). > This is the same problem as in CPython. Most failing internal > operations call PyErr_SetString(), which causes a string to be used > as the exception value. No, as the argument to the exception constructor. > The hack is that when the user code reaches an 'except' clauses the > exception is "normalized", which translates the pair "TypeError > class + string" into the pair "TypeError class + TypeError > instance". Right, and for all practical purposes, raise TypeError, "foo" is the same as raise TypeError("foo") > We might either choose to mimic this behavior or clean it up a bit, > e.g. by always using internally a single object as the exception > instance. That's fine. CPython uses the pair so that for certain exceptions raised *internally* (by C code, not by raise statements) the instantiation is never done if the exception is caught and cleared by C code further down the stack. For example, when iterating over a built-in sequence, the StopIteration exception is raised but never instantiated. > String exceptions are being deprecated, but still we could > reasonably emulate them, say by inventing a StringException > class. This would isolate the hacky parts around this specific class > (like setting sys.exc_type to something else than > current_exception.__class__ for this particular case). I would not even bother. String exceptions are strongly deprecated part of the language. --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2

[gmane.comp.python.pypy] deep breakage
by Michael Hudson 09 Jun '03

09 Jun '03

What's going on? -- The above comment may be extremely inflamatory. For your protection, it has been rot13'd twice. -- the signature of "JWhitlock" on slashdot

2 5

Re: [pypy-dev] Objects and types in the stdobjspace
by roccomoretti＠netscape.net 09 Jun '03

09 Jun '03

Armin Rigo <arigo(a)tunes.org> wrote: >On Sat, Jun 07, 2003 at 08:51:51AM +0200, holger krekel wrote: >> - how the new test-machinery works so i can make sure that i >> don't break big stuff while trying to fix/play around > >pypy/testall.py runs all the tests, using the object space specified in the >environment variable OBJSPACE -- which must be exactly >pypy.objspace.std.StdObjSpace to use the standard object space; the >trivial >object space is used otherwise. > >pypy/testwice.py is a hack around the previous one to run all the tests in >both object spaces. ("previous" being the pypy/testall.py file, not any pre-sprint test hook.) ... and pypy/testcts.py is a rather clever piece of code to run tests on StdObjSpace, keep track of the results, and report any difference from run to run. >The individual .../test/test_xxx.py files are still runnable. There is a >testsupport.py file in all test directories for glueing purposes; running >it directly should execute all the tests in that directory. I've been playing around with it over the weekend, and I feel things (testing wise) need to be clarified slightly. First, I think we should move all pypy-as-a-whole testing related stuff into an approriate subdirectory ("pypy/testing" or some such. As it is now, pieces are scattered in pypy and pypy/interpreter. Secondly, the testing framework as written will only run tests at the interpreter level. Some tests (such as test_exceptcomp and test_exec) should be run at the application level. Additionally, there is no provision for running the CPython regression tests automatically within the current testing framework. The thought occured to me if it would not be easiest to "appropriate" the CPython regrtest.py framework for our purposes. As best I can tell, it's written in a general fashion already, so "all" we would need to do is get it to recognize when to run tests under interpreter level and when to run tests under application level. (Which could potentially be accomplished by a naming convention.) >> - any "entry points" other than interactive.py? > >There is main.py in the same directory. Its purpose is that 'python >main.py >script-and-options' should be the same as 'pypy script-and-options' if we >had >a working 'pypy' program. I guess that main.py should invoke >interactive.py >when started with no argument (it doesn't right now). Other problems, I assume (from code inspection, not from direct running) are that the commandline arguments are not passed to sys.argv, sys.path may or may not contain the directory of the script, and sys.modules['__main__'] is not set equal to the script module (only a problem, I think, when running unittest.main()). And in keeping with my rearranging mood, I think main.py should probably be placed in the pypy/ directory. -- I also think someone should give me <Dr. Evil> ONE BILLION DOLLARS </Dr. Evil> and melons should taste more like currants, so that shows you what *I* know. >> - a recap of the current StdObjsSpace registration/multimethod >> mechanisms. > >The W_XxxObject classes of the standard object space are, precisely, >*implementations* of objects. This is not the same as the *type* of the >object. It is possible to provide several implementations for the same >type >(the user should not see the difference, though). Typical uses of this >would >be to hide the int/long disctinction to the user altogether, or more >interestingly to provide more efficient versions of the data structures >like >string, list or dict when they become large. FANTASTIC! An excellent way of looking at things. But I'm still a little hazy. Could you walk us through how this scheme would work with multiple implementations of the same type and specifics as to how this would be different from the (CPython) current implementation of types being the same as the implementation? Congrats to the spriters - it looks like quite a few good things have been accomplished. -Rocco __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455

3 2

Pypy-dev-owner Lose Weight Easy
by Josefina Giles 08 Jun '03

08 Jun '03

1 0

[gmane.comp.python.pypy] a few things
by Michael Hudson 02 Jun '03

02 Jun '03

For some reason, posting via gmane doesn't. -- 31. Simplicity does not precede complexity, but follows it. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

2 3