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.
- 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).
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.