Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Martin, there are two reasons for hiding away these details:
- we need to be able to change the codec state without breaking the APIs
That will be possible with the currently-proposed patch. The _codecs methods are not public API, so changing them would not be an API change.
Uhm, I wasn't talking about the builtin codecs only (of course, we can change those to our liking). I'm after a generic interface for stateful codecs.
- we don't want the state to be altered by the user
We are all consenting adults, and we can't *really* prevent it, anyway. For example, the user may pass an old state, or a state originating from a different codec (instance). We need to support this gracefully (i.e. with a proper Python exception).
True, but the codec writer should be in control of the state object, its format and what the user can or cannot change.
A single object serves this best and does not create a whole plethora of new APIs in the _codecs module. This is not over-design, but serves a reason.
It does put a burden on codec developers, which need to match the "official" state representation policy. Of course, if they are allowed to return a tuple representing their state, that would be fine with me.
They can use any object they like to keep the state in whatever format they choose. I think this makes it easier on the codec writer, rather than harder.
Furthermore, they can change the way they store state e.g. to accomodate for new features they may want to add to the codec, without breaking the interface.