[Python-Dev] PEP 293, Codec Error Handling Callbacks

M.-A. Lemburg mal@lemburg.com
Mon, 12 Aug 2002 19:43:20 +0200

Martin v. Loewis wrote:
> "M.-A. Lemburg" <mal@lemburg.com> writes:
>>>What are new-style exceptions?
>>Exceptions that are built as subclassable types.
> Exceptions first of all inherit from Exception. When/if Exception
> stops being a class, we'll have to deal with more issues than the PEP
> 293 exceptions.

Right. It would be nice to have classes or at least exceptions
turn into new-style types as well. Then you'd have access to
slots and all the other goodies which make a great difference
in accessing performance at C level.

>>There's nothing premature here. By moving exception handling to
>>C level, you get *much* better performance than at Python level.
> Can you give a specific example: What Python code, how much better
> performance?

Walter has the details here.

>>This doesn't work as I've already explained before. The predefined
>>error handling modes of builtin codecs must work with relying on
>>the Python import mechanism.
> You mean "without"? 

Right. s/with/without/.

> Where did you explain this before? 

Hmm, I remember having posted the reasoning I gave here
in another response on this thread, but I can't find it
at the moment.

 > And why is
> that? Guido argues that more of the central interpreter machinery must
> be moved to Python - I can't see why codecs should be an exception
> here.

The problem is the same as what we had with the exceptions.py
module early on in the 1.6 alphas: if this module isn't found
all kinds of things start failing. The same would happen when
you start to use builtin codecs which have external error handler
implementation as .py files, e.g. unicode('utf-8', 'replace')
could then fail because of an ImportError.

For the charmap codec it's mostly about performance. I don't
have objections for other codecs which rely on external

>>What ? That exceptions are immutable ? I think it's a big win that
>>exceptions are in fact mutable -- they are great for transporting
>>extra information up the chain...
> I see. So this is an open issue.

I wouldn't call it an issue. It's a feature :-) (and one that makes
Python's exception mechanism very powerful)

Marc-Andre Lemburg
CEO eGenix.com Software GmbH
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/