[Python-Dev] Low-level exception invariants? (original) (raw)

Guido van Rossum guido at python.org
Fri May 26 19:05:54 CEST 2006


+1, if you can also prove that the traceback will never be null. I failed at that myself last time I tried, but I didn't try very long or hard.

--Guido

On 5/26/06, Tim Peters <tim.peters at gmail.com> wrote:

In various places we store triples of exception info, like a PyFrameObject's fexctype, fexcvalue, and fexctraceback PyObject* members.

No invariants are documented, and that's a shame. Patch 1145039 aims to speed ceval a bit by relying on a weak guessed invariant, but I'd like to make the stronger claim (which allows for stronger speedups) that, at any moment, all three are NULL or all three are not NULL Now I know that's not true, although Python's test suite doesn't provoke a violation. In particular, PyErrSetNone() forces tstate->curexcvalue to NULL. Other code then special-cases the snot out of XYZvalue, replacing NULL with PyNone on the fly, like PyErrFetch(&exc, &val, &tb); if (val == NULL) { val = PyNone; PyINCREF(val); } in the main eval loop. I'd much rather change PyErrSetNone() to set the value to PyNone to begin with -- that function is almost never called, so special-casing in that is less damaging than special-casing NULL everywhere else. The docs are confused about this now too, claiming: void PyErrSetNone(PyObject *type) This is a shorthand for "PyErrSetObject(type, PyNone)". It's actually a shorthand for PyErrSetObject(type, NULL) now. Does anyone see a real problem with establishing an "all NULL or none NULL" invariant? It makes outstanding ;-) conceptual sense to me, and would allow removing some masses of distributed test-branch special-casing in code trying to use these guys.


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/guido%40python.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-Dev mailing list