Walter Dörwald wrote: > Martin v. Löwis wrote: > >> M.-A. Lemburg wrote: >> >>> I like the idea, but don't think the implementation is >>> the right way to do it. Instead, I'd suggest using a new >>> error handling strategy "break" ( = break processing as >>> soon as errors are found). >> >> >> Can you demonstrate this approach in a patch? I think it >> is unimplementable: the codec cannot communicate to the >> error callback that it ran out of data. > > > We would need a special attribute in the exception for > that, but the problem IMHO is a different one. This makes > it impossible to use other error handling schemes than > "break" in stateful decoders. I don't understand... are you referring to some extra attribute for storing arbitrary state ? If so, why would adding such an attribute make it impossible to use other error handling schemes ? The problem with your patch is that you are adding a whole new set of decoders to the core which duplicate much of what the already existing decoders implement. I don't like that duplication and would like to find a way to only have *one* implementation per decode operation. Of course, encoders would have to provide the same interfaces for symmetry reasons. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 28 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4