gmane.comp.python.devel

Re: Attribute error: providing type name

Martin v. Löwis — 2008-12-01T23:10:57

I think the standard exception hierarchy should grow additional standard fields. E.g. AttributeError should have attributes 'type','name', or perhaps even 'object','name'. TypeError should have attributes 'expected', 'actual' (or, again, 'expected', 'object'). Also, some languages support nested exceptions (attribute 'inner'); usefulness of this concept should be reviewed. And so on - that might produce quite a large PEP. As 3.0 missed the chance to fix this, compatibility is also an issue. It might be possible to overload exception constructors on the number of parameters, or using keyword parameters for the new way of filling the exception. And no, I don't volunteer to write this PEP :-) Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Python for windows.

Martin v. Löwis — 2008-12-01T22:55:37

I think the debate was about whether it can be "OEM ready", even though you still need to pass the TARGETDIR parameter. If it works for you, it works for me, of course. Please do submit an issue in the bug tracker atleast, asking that the files be renamed. Please confirm explicitly that renaming them would also solve the problem (assuming you are still talking about the files in distutils). Please look in Tools/msi/msi.py for all occurrences of python_icon.exe. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Attribute error: providing type name

Nick Coghlan — 2008-12-01T21:20:36

Perhaps adding something like the following to the C API: void PyErr_FormatAttributeError(PyObject* type, char *attr) { PyErr_Format(PyExc_AttributeError, "object of type %.100s has no attribute '%.200s'", type->tp_name, attr); } This could also be exposed as a class method of AttributeError itself for use in Python code. (Interestingly, I noticed that there are still quite a few attribute errors at least in typeobject.c that don't provide any information on the type of the object that is missing an attribute - they appeared to mostly be obscure errors that will only turn up if something has gone very strange, but they're there) Cheers, Nick.

Re: Python for windows.

Koenig, Gerald — 2008-12-01T19:08:10

Mark, We do not install that on first boot. I can not tell how it is install but on first boot python is already there and installed properly Gerald -----Original Message----- From: Koenig, Gerald Sent: Monday, December 01, 2008 11:05 AM To: '"Martin v. Löwis"'; mhammond< at >skippinet.com.au Cc: 'Nick Coghlan'; python-dev< at >python.org Subject: RE: [Python-Dev] Python for windows. Hi all, I didn't look at the thread until this morning. The OEM ready program required that the installed force to program files. But as we preinstalled we use your msi with a normal parameter: python-2.5.2.msi TARGETDIR=c:\program files\python" That why I didn't ask you about that. WE have done already few weeks of test and nothing is breaking up to now :) Now about the 2 others issues what will be the easier way to fix them properly ? - for the executable without manifest as we are on vista OS only I can add a manifest for vista outside the executable it should work. - for python_icon.exe I do not know what is calling it in start menu can you help me on that ? Gerald -----Original Message----- From: python-dev-bounces+gerald.koenig=hp.com< at >python.org [mailto:python-dev-bounces+gerald.koenig=hp.com< at >python.org] On Behalf Of "Martin v. Löwis" Sent: Sunday, November 30, 2008 2:24 PM To: mhammond< at >skippinet.com.au Cc: 'Nick Coghlan'; python-dev< at >python.org Subject: Re: [Python-Dev] Python for windows. Perhaps. However, "help where we can" is about right. If its only the changes HP discussed so far, I think we should be able to help. For the Program Files issue, without going into the discussion whether Python's defaults are good or not, I think there would be still a number of technical solutions (such as providing a merge module which changes the default). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Python for windows.

Koenig, Gerald — 2008-12-01T19:05:01

Hi all, I didn't look at the thread until this morning. The OEM ready program required that the installed force to program files. But as we preinstalled we use your msi with a normal parameter: python-2.5.2.msi TARGETDIR=c:\program files\python" That why I didn't ask you about that. WE have done already few weeks of test and nothing is breaking up to now :) Now about the 2 others issues what will be the easier way to fix them properly ? - for the executable without manifest as we are on vista OS only I can add a manifest for vista outside the executable it should work. - for python_icon.exe I do not know what is calling it in start menu can you help me on that ? Gerald -----Original Message----- From: python-dev-bounces+gerald.koenig=hp.com< at >python.org [mailto:python-dev-bounces+gerald.koenig=hp.com< at >python.org] On Behalf Of "Martin v. Löwis" Sent: Sunday, November 30, 2008 2:24 PM To: mhammond< at >skippinet.com.au Cc: 'Nick Coghlan'; python-dev< at >python.org Subject: Re: [Python-Dev] Python for windows. Perhaps. However, "help where we can" is about right. If its only the changes HP discussed so far, I think we should be able to help. For the Program Files issue, without going into the discussion whether Python's defaults are good or not, I think there would be still a number of technical solutions (such as providing a merge module which changes the default). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: format specification mini-language docs...

Eric Smith — 2008-12-01T18:15:03

Thanks! I'll take care of it. Eric. _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: format specification mini-language docs...

Dino Viehland — 2008-12-01T17:56:08

Yep, after the thanksgiving delay I've opened bug #4482 (http://bugs.python.org/issue4482). I either don't know how to or don't have the power to change who a bug is assigned to so it appears to be currently unassigned. -----Original Message----- From: Eric Smith [mailto:eric< at >trueblade.com] Sent: Tuesday, November 25, 2008 4:38 AM To: Dino Viehland Cc: python-dev< at >python.org dev Subject: Re: [Python-Dev] format specification mini-language docs... Dino Viehland wrote: I think the inf one is a bug. Would you mind opening a bug and assigning it to me? Thanks. Eric. _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Attribute error: providing type name

Alex Martelli — 2008-12-01T15:35:34

I wonder if there's some desiderata left for future Python versions to make this standard behavior easier (for C-coded, Python-coded, and Cython-coded classes, ones made by SWIG, etc) without too much black magic... Alex On Mon, Dec 1, 2008 at 1:30 AM, Filip Gruszczyński gmail.com> wrote: _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Python under valgrind

Kristján Valur Jónsson — 2008-12-01T15:32:24

Probably because of the object memory allocator. It reads the start of memory pages to see if a block belongs tot the obmalloc system or not. You want to remove the following line: #define WITH_PYMALLOC 1 K -----Original Message----- From: python-dev-bounces+kristjan=ccpgames.com< at >python.org [mailto:python-dev-bounces+kristjan=ccpgames.com< at >python.org] On Behalf Of Hrvoje Niksic Sent: 28. nóvember 2008 13:52 Cc: Python-Dev Subject: Re: [Python-Dev] Python under valgrind Amaury Forgeot d'Arc wrote: Thanks for the suggestion (as well as to Gustavo and Victor), but my question wasn't about how to suppress the messages, but about why the messages appear in the first place. I think my last paragraph answers my own question, but I'm not sure. _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Attribute error: providing type name

Filip Gruszczyński — 2008-12-01T09:30:27

He does. It is supposed to appear in 4.8. So I guess that's it, thanks a lot for your help.

Re: Patch to speed up non-tracing case inPyEval_EvalFrameEx (2% on pybench)

Jeffrey Yasskin — 2008-12-01T04:34:27

Done: http://bugs.python.org/issue4477 On Sun, Nov 30, 2008 at 8:14 PM, Brett Cannon python.org> wrote:

Re: Patch to speed up non-tracing case inPyEval_EvalFrameEx (2% on pybench)

Brett Cannon — 2008-12-01T04:14:45

Can you toss the patch into the issue tracker, Jeffrey, so that any patch comments can be done there? -Brett On Sun, Nov 30, 2008 at 17:54, Jeffrey Yasskin gmail.com> wrote: _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Patch to speed up non-tracing case inPyEval_EvalFrameEx (2% on pybench)

Jeffrey Yasskin — 2008-12-01T01:54:02

Tracing support shows up fairly heavily an a Python profile, even though it's nearly always turned off. The attached patch against the trunk speeds up PyBench by 2% for me. All tests pass. I have 2 questions: 1) Can other people corroborate this speedup on their machines? I'm running on a Macbook Pro (Intel Core2 processor, probably Merom) with a 32-bit build from Apple's gcc-4.0.1. (Apple's gcc consistently produces a faster python than gcc-4.3.) 2) Assuming this speeds things up for most people, should I check it in anywhere besides the trunk? I assume it's out for 3.0; is it in for 2.6.1 or 3.0.1? Pybench output: ------------------------------------------------------------------------------- PYBENCH 2.0 ------------------------------------------------------------------------------- * using CPython 2.7a0 (trunk:67458M, Nov 30 2008, 17:14:10) [GCC 4.0.1 (Apple Inc. build 5488)] * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.time ------------------------------------------------------------------------------- Benchmark: pybench.out ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID: Darwin-9.5.0-i386-32bit Processor: i386 Python: Implementation: CPython Executable: /Users/jyasskin/src/python/trunk-fast-tracing/build/python.exe Version: 2.7.0 Compiler: GCC 4.0.1 (Apple Inc. build 5488) Bits: 32bit Build: Nov 30 2008 17:14:10 (#trunk:67458M) Unicode: UCS2 ------------------------------------------------------------------------------- Comparing with: ../build_orig/pybench.out ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID: Darwin-9.5.0-i386-32bit Processor: i386 Python: Implementation: CPython Executable: /Users/jyasskin/src/python/trunk-fast-tracing/build_orig/python.exe Version: 2.7.0 Compiler: GCC 4.0.1 (Apple Inc. build 5488) Bits: 32bit Build: Nov 30 2008 13:51:09 (#trunk:67458) Unicode: UCS2 Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 127ms 130ms -2.4% 129ms 132ms -2.1% BuiltinMethodLookup: 90ms 93ms -3.2% 91ms 94ms -3.1% CompareFloats: 88ms 91ms -3.3% 89ms 93ms -4.3% CompareFloatsIntegers: 97ms 99ms -2.1% 97ms 100ms -2.4% CompareIntegers: 79ms 82ms -4.2% 79ms 85ms -6.1% CompareInternedStrings: 90ms 92ms -2.4% 94ms 94ms -0.9% CompareLongs: 86ms 83ms +3.6% 87ms 84ms +3.5% CompareStrings: 80ms 82ms -3.1% 81ms 83ms -2.3% CompareUnicode: 103ms 105ms -2.3% 106ms 108ms -1.5% ComplexPythonFunctionCalls: 139ms 137ms +1.3% 140ms 139ms +0.1% ConcatStrings: 142ms 151ms -6.0% 156ms 154ms +1.1% ConcatUnicode: 87ms 92ms -5.4% 89ms 94ms -5.7% CreateInstances: 142ms 144ms -1.4% 144ms 145ms -1.1% CreateNewInstances: 107ms 109ms -2.3% 108ms 111ms -2.1% CreateStringsWithConcat: 114ms 137ms -17.1% 117ms 139ms -16.0% CreateUnicodeWithConcat: 92ms 101ms -9.2% 95ms 102ms -7.2% DictCreation: 77ms 81ms -4.4% 80ms 85ms -5.9% DictWithFloatKeys: 91ms 107ms -14.5% 93ms 109ms -14.6% DictWithIntegerKeys: 95ms 94ms +1.4% 108ms 96ms +12.3% DictWithStringKeys: 83ms 88ms -5.8% 84ms 88ms -4.7% ForLoops: 72ms 72ms -0.1% 79ms 74ms +5.8% IfThenElse: 83ms 80ms +3.9% 85ms 80ms +5.3% ListSlicing: 117ms 118ms -0.7% 118ms 121ms -1.8% NestedForLoops: 116ms 119ms -2.4% 121ms 121ms +0.0% NormalClassAttribute: 106ms 115ms -7.7% 108ms 117ms -7.7% NormalInstanceAttribute: 96ms 98ms -2.3% 97ms 100ms -3.1% PythonFunctionCalls: 92ms 95ms -3.7% 94ms 99ms -5.2% PythonMethodCalls: 147ms 147ms +0.1% 152ms 149ms +2.1% Recursion: 135ms 136ms -0.3% 140ms 144ms -2.9% SecondImport: 101ms 99ms +2.1% 103ms 101ms +2.2% SecondPackageImport: 107ms 103ms +3.5% 108ms 104ms +3.3% SecondSubmoduleImport: 134ms 134ms +0.3% 136ms 136ms -0.0% SimpleComplexArithmetic: 105ms 111ms -5.0% 110ms 112ms -1.4% SimpleDictManipulation: 95ms 106ms -10.6% 96ms 109ms -12.0% SimpleFloatArithmetic: 90ms 99ms -9.3% 93ms 102ms -8.2% SimpleIntFloatArithmetic: 78ms 76ms +2.3% 79ms 77ms +2.0% SimpleIntegerArithmetic: 78ms 77ms +1.8% 79ms 77ms +2.0% SimpleListManipulation: 80ms 78ms +2.4% 80ms 79ms +1.9% SimpleLongArithmetic: 110ms 113ms -2.0% 111ms 113ms -2.1% SmallLists: 128ms 117ms +9.5% 130ms 124ms +4.9% SmallTuples: 115ms 114ms +1.7% 117ms 114ms +2.2% SpecialClassAttribute: 101ms 112ms -10.3% 104ms 114ms -8.9% SpecialInstanceAttribute: 173ms 177ms -1.9% 176ms 179ms -1.6% StringMappings: 165ms 167ms -1.2% 168ms 169ms -0.5% StringPredicates: 126ms 134ms -5.7% 127ms 134ms -5.6% StringSlicing: 125ms 123ms +1.9% 131ms 130ms +0.7% TryExcept: 79ms 80ms -0.6% 80ms 80ms -0.8% TryFinally: 110ms 107ms +3.0% 111ms 112ms -1.1% TryRaiseExcept: 99ms 101ms -1.6% 100ms 102ms -1.7% TupleSlicing: 127ms 127ms +0.6% 137ms 137ms +0.0% UnicodeMappings: 144ms 144ms -0.3% 145ms 145ms -0.4% UnicodePredicates: 116ms 114ms +1.3% 117ms 115ms +1.1% UnicodeProperties: 106ms 102ms +3.6% 107ms 104ms +3.1% UnicodeSlicing: 95ms 111ms -14.0% 99ms 112ms -11.8% WithFinally: 157ms 152ms +3.3% 159ms 154ms +3.3% WithRaiseExcept: 123ms 125ms -1.1% 125ms 126ms -1.2% ------------------------------------------------------------------------------- Totals: 6043ms 6182ms -2.2% 6185ms 6301ms -1.9% (this=pybench.out, other=../build_orig/pybench.out) 2to3 times: Before: $ time ./python.exe ~/src/2to3/2to3 -f all ~/src/2to3/ >/dev/null real0m56.685s user0m55.620s sys0m0.380s After: $ time ./python.exe ~/src/2to3/2to3 -f all ~/src/2to3/ >/dev/null real0m55.067s user0m53.843s sys0m0.376s == 3% faster Gory details: The meat of the patch is: < at >< at > -884,11 +891,12 < at >< at > fast_next_opcode: f->f_lasti = INSTR_OFFSET(); /* line-by-line tracing support */ -if (tstate->c_tracefunc != NULL && !tstate->tracing) { +if (_Py_TracingPossible && + tstate->c_tracefunc != NULL && !tstate->tracing) { This converts the generated assembly (produced with `gcc -S -dA ...`, then manually annotated a bit) from: # basic block 17 # ../Python/ceval.c:885 LM541: movl8(%ebp), %ecx LVL319: subl-316(%ebp), %edx movl%edx, 60(%ecx) # ../Python/ceval.c:889 LM542: # %esi = tstate movl-336(%ebp), %esi LVL320: # %eax = tstate->c_tracefunc movl28(%esi), %eax LVL321: # if tstate->c_tracefunc == 0 testl%eax, %eax # goto past-if () jeL567 # more if conditions here to: # basic block 17 # ../Python/ceval.c:889 LM542: movl8(%ebp), %ecx LVL319: subl-316(%ebp), %edx movl%edx, 60(%ecx) # ../Python/ceval.c:893 LM543: # %eax = _Py_TracingPossible movl__Py_TracingPossible-"L00000000033$pb"(%ebx), %eax LVL320: # if _Py_TracingPossible != 0 testl%eax, %eax # goto rest-of-if (nearby) jneL2321 # opcode = NEXTOP(); continues here The branch should be predicted accurately either way, so there are 2 things that may be contributing to the performance change. First, adding the global caching variable halves the amount of memory that has to be read to check the prediction. The memory that is read is still read one instruction before it's used, but adding a local variable to read the memory earlier doesn't affect the performance. Without the global variable, the compiler puts the tracing code immediately after the if; with the global, it moves it away and puts the non-tracing code immediately after the first test in the if. This may affect branch prediction and may affect the icache. I tried using gcc's __builtin_expect() to ensure that the tracing code is always out-of-line. This moved it much farther away and cost about 1% in performance (i.e. 1% instead of 2% faster than "before"). I don't know why the __builtin_expect() version would be slower. If anyone feels inspired to test this out on another processor or compiler version, let me know how it goes. Jeffrey _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Attribute error: providing type name

Alex Martelli — 2008-12-01T01:14:08

Yes, but he should be able to change it in one place (in sip, the C++ to Python wrapper generator he's also authored and uses for PyQt) AND it would make sip even better, so he may want to put it on his backlog. Alex _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Python for windows.

Martin v. Löwis — 2008-11-30T22:23:51

Perhaps. However, "help where we can" is about right. If its only the changes HP discussed so far, I think we should be able to help. For the Program Files issue, without going into the discussion whether Python's defaults are good or not, I think there would be still a number of technical solutions (such as providing a merge module which changes the default). Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: [ANN] VPython 0.1

Jeffrey Yasskin — 2008-11-30T22:19:32

Here's another data point. My results are similar to Skip's (unsurprising since I'm also using a mac). My wild guess is that the 30% vs 10% improvement is an AMD vs. Intel thing? It's not 32-bit vs. 64-bit since both David and Jakob got a 30% speedup, but David had a 32-bit build while Jakob had a 64-bit build. There's also a crashing bug on: def f(): a+=1 f() I have a fix by changing the load_fast opcode to adjust the stack on error, but it requires removing all the superinstructions involving load_fast, which costs me 1-2% in performance. The fix is not included in these numbers. ------------------------------------------------------------------------------- PYBENCH 2.0 ------------------------------------------------------------------------------- * using CPython 2.6+ (unknown, Nov 19 2008, 09:14:51) [GCC 4.0.1 (Apple Inc. build 5484)] * disabled garbage collection * system check interval set to maximum: 2147483647 * using timer: time.time ------------------------------------------------------------------------------- Benchmark: /Users/jyasskin/src/python/bzr/2.6_cxx/build_c4.0/pybench.out ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID: Darwin-9.5.0-i386-32bit Processor: i386 Python: Implementation: CPython Executable: /Users/jyasskin/src/python/bzr/2.6_cxx/build_c4.0/python.exe Version: 2.6.0 Compiler: GCC 4.0.1 (Apple Inc. build 5484) Bits: 32bit Build: Nov 19 2008 09:14:51 (#unknown) Unicode: UCS2 ------------------------------------------------------------------------------- Comparing with: /Users/jyasskin/src/python/bzr/2.6_vmgen/build/pybench.out ------------------------------------------------------------------------------- Rounds: 10 Warp: 10 Timer: time.time Machine Details: Platform ID: Darwin-9.5.0-i386-32bit Processor: i386 Python: Implementation: CPython Executable: /Users/jyasskin/src/python/bzr/2.6_vmgen/build/python.exe Version: 2.6.0 Compiler: GCC 4.0.1 (Apple Inc. build 5488) Bits: 32bit Build: Nov 24 2008 20:20:04 (#unknown) Unicode: UCS2 Test minimum run-time average run-time this other diff this other diff ------------------------------------------------------------------------------- BuiltinFunctionCalls: 131ms 118ms +10.9% 134ms 120ms +11.3% BuiltinMethodLookup: 109ms 90ms +20.9% 111ms 96ms +15.7% CompareFloats: 91ms 65ms +40.4% 92ms 66ms +39.2% CompareFloatsIntegers: 99ms 85ms +16.5% 99ms 85ms +16.4% CompareIntegers: 83ms 49ms +67.3% 83ms 50ms +67.2% CompareInternedStrings: 93ms 72ms +30.3% 95ms 73ms +29.3% CompareLongs: 84ms 62ms +36.6% 86ms 63ms +37.3% CompareStrings: 82ms 68ms +20.2% 84ms 71ms +17.7% CompareUnicode: 104ms 89ms +17.5% 109ms 94ms +15.1% ComplexPythonFunctionCalls: 139ms 126ms +11.1% 142ms 127ms +11.4% ConcatStrings: 149ms 138ms +8.0% 154ms 148ms +3.8% ConcatUnicode: 88ms 84ms +4.7% 90ms 85ms +5.8% CreateInstances: 142ms 130ms +9.5% 143ms 131ms +9.0% CreateNewInstances: 106ms 99ms +7.4% 107ms 99ms +7.6% CreateStringsWithConcat: 116ms 94ms +23.3% 118ms 95ms +25.0% CreateUnicodeWithConcat: 91ms 83ms +10.3% 92ms 84ms +9.6% DictCreation: 92ms 80ms +14.8% 93ms 81ms +14.8% DictWithFloatKeys: 95ms 90ms +5.2% 98ms 91ms +6.7% DictWithIntegerKeys: 99ms 91ms +9.1% 104ms 92ms +13.8% DictWithStringKeys: 83ms 73ms +13.8% 87ms 76ms +14.9% ForLoops: 77ms 62ms +23.2% 79ms 63ms +24.5% IfThenElse: 78ms 55ms +41.6% 79ms 56ms +42.7% ListSlicing: 115ms 185ms -37.7% 120ms 187ms -36.1% NestedForLoops: 135ms 100ms +35.0% 136ms 102ms +33.8% NormalClassAttribute: 105ms 98ms +6.9% 106ms 99ms +6.8% NormalInstanceAttribute: 93ms 84ms +11.2% 94ms 85ms +10.8% PythonFunctionCalls: 102ms 90ms +13.5% 105ms 93ms +13.4% PythonMethodCalls: 147ms 133ms +10.5% 148ms 135ms +9.7% Recursion: 142ms 118ms +20.2% 147ms 119ms +22.9% SecondImport: 99ms 98ms +1.3% 100ms 100ms +0.1% SecondPackageImport: 102ms 101ms +1.2% 104ms 102ms +1.8% SecondSubmoduleImport: 133ms 133ms +0.4% 135ms 134ms +1.0% SimpleComplexArithmetic: 100ms 93ms +7.3% 101ms 94ms +7.8% SimpleDictManipulation: 110ms 93ms +18.3% 111ms 94ms +18.3% SimpleFloatArithmetic: 92ms 76ms +19.9% 94ms 82ms +15.5% SimpleIntFloatArithmetic: 73ms 62ms +16.8% 73ms 63ms +16.4% SimpleIntegerArithmetic: 73ms 64ms +13.5% 74ms 65ms +13.0% SimpleListManipulation: 79ms 67ms +18.6% 80ms 69ms +15.6% SimpleLongArithmetic: 111ms 98ms +13.3% 112ms 99ms +13.3% SmallLists: 126ms 112ms +12.9% 129ms 114ms +12.7% SmallTuples: 123ms 104ms +18.5% 125ms 105ms +18.7% SpecialClassAttribute: 101ms 95ms +6.5% 102ms 97ms +5.2% SpecialInstanceAttribute: 173ms 154ms +12.8% 175ms 158ms +10.7% StringMappings: 165ms 163ms +1.1% 166ms 164ms +1.3% StringPredicates: 126ms 121ms +4.3% 130ms 124ms +5.0% StringSlicing: 125ms 107ms +17.1% 130ms 111ms +16.4% TryExcept: 83ms 57ms +44.6% 84ms 58ms +45.3% TryFinally: 102ms 104ms -1.8% 107ms 105ms +2.2% TryRaiseExcept: 98ms 95ms +2.9% 99ms 97ms +2.7% TupleSlicing: 124ms 141ms -12.5% 138ms 144ms -4.4% UnicodeMappings: 142ms 142ms -0.2% 143ms 143ms +0.1% UnicodePredicates: 107ms 100ms +7.4% 108ms 101ms +7.2% UnicodeProperties: 109ms 101ms +7.8% 111ms 102ms +8.3% UnicodeSlicing: 107ms 84ms +27.8% 111ms 89ms +24.4% WithFinally: 156ms 151ms +3.4% 157ms 151ms +3.9% WithRaiseExcept: 124ms 120ms +3.1% 125ms 121ms +3.0% ------------------------------------------------------------------------------- Totals: 6137ms 5548ms +10.6% 6258ms 5653ms +10.7% (this=/Users/jyasskin/src/python/bzr/2.6_cxx/build_c4.0/pybench.out, other=/Users/jyasskin/src/python/bzr/2.6_vmgen/build/pybench.out) On Wed, Oct 22, 2008 at 5:48 PM, David Ripton ripton.net> wrote:

Re: Python for windows.

Mark Hammond — 2008-11-30T22:06:58

But wouldn't that leave us in the situation where Python's installer is *not* "OEM Ready", nor has it been certified as such - but an installer based on ours, but with unspecified changes has? Of course, I don't object to that and still think we should help where we can, but if that is true it would make the premise of this thread a little misleading, as obviously HP could then make *any* necessary changes without our agreement or even knowledge. Cheers, Mark _______________________________________________ Python-Dev mailing list Python-Dev< at >python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: Attribute error: providing type name

Filip Gruszczyński — 2008-11-30T22:02:09

I guess, this means that I have to go to Phil Thompson at Riverbank and try to convince him to change the message.

Re: Attribute error: providing type name

Nick Coghlan — 2008-11-30T21:50:33

Yeah, any time someone implements their own attribute lookup process for a class (be it via __getattr__, __getattribute__ or the C equivalents), it is up to the reimplementation to appropriately format their error message if they raise AttributeError directly. This could possibly be made easier to do correctly via a specific AttributeError class method (also exposed through the C API) that accepted a type object and an attribute name and then produced a nicely formatted error message the way the builtin types do. Cheers, Nick.

Re: Attribute error: providing type name

Filip Gruszczyński — 2008-11-30T21:39:12

I have done some testing and it seems, that it might not be Python problem. Well, when I use only pure Python objects, I get really nice description of the object (which means the type). But I am using PyQt and it seems, that when an object is subclassing QObject (or possibly some other class from qt, that can be not derived from QObject) it can only display information about the name of the function. PyQt are python bindings for C++ qt library. Can this be the reason for not displaying type of the object? 2008/11/30 Nick Coghlan gmail.com>:

Re: Attribute error: providing type name

Nick Coghlan — 2008-11-30T20:35:13

It wouldn't be the first time we've broken doc tests that way. Since the details of the error messages aren't guaranteed to remain the same across releases, doctests that aren't part of Python's own test suite really should be using IGNORE_EXCEPTION_DETAIL when checking for exceptions that are raised directly by the interpreter or standard library. Cheers, Nick.