M.-A. Lemburg writes: > Wouldn't it be possible to have the read/write methods set up > the state when called for the first time ? That slows the down; the constructor should handle initialization. Perhaps what gets registered should be: encoding function, decoding function, stream encoder factory (can be a class), stream decoder factory (again, can be a class). These can be encapsulated either before or after hitting the registry, and can be None. The registry and provide default implementations from what is provided (stream handlers from the functions, or functions from the stream handlers) as required. Ideally, I should be able to write a module with four well-known entry points and then provide the module object itself as the registration entry. Or I could construct a new object that has the right interface and register that if it made more sense for the encoding. > AFAIK, .feed() and .finalize() (or .close() etc.) have a different > backgound: you add data in chunks and then process it at some > final stage rather than for each feed. This is often more Many of the classes that provide feed() do as much work as possible as data is fed into them (see htmllib.HTMLParser); this structure is commonly used to support asynchonous operation. > With respest to codecs this would mean, that you buffer the > output in memory, first doing only preliminary operations on > the feeds and then apply some final logic to the buffer at > the time .finalize() is called. That depends on the encoding. I'd expect it to feed encoded data to a sink as quickly as it could and let the target decide what needs to happen. If buffering is needed, the target could be a StringIO or whatever. -Fred -- Fred L. Drake, Jr. <fdrake@acm.org> Corporation for National Research Initiatives
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