[Python-Dev] Codecs and StreamCodecs

[Fred L. Drake, Jr.]

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