Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>> Marc-Andre, if the original patch (diff.txt) was applied: >>> What *specific* change in that patch would break code? >>> What *specific* code (C or Python) would break under that >>> change? > > [...] > >> Let's flesh this out some more and get a better understanding >> of what is needed and how the separation between the stream queue, >> the stream codec and the underlying codec implementation can >> be put to good use. > > > That really didn't answer the question: What would be technically > wrong with accepting Walter's patches? > > I smell over-designing: there is a specific problem at hand > (incomplete reads resulting in partial decoding); any solution > should attempt to *only* solve this problem, not any other > problem. The specific problem is that of providing a codec that can run in feeding mode where you can feed in data and read it in a way that allows incomplete input data to fail over nicely. Since this requires two head positions (one for the writer, one for the reader), a queue implementation is the right thing to use. We are having this discussion to find a suitable design to provide this functionality in a nice and clean way. I don't see anything wrong with this. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 19 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