Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>> Martin, there are two reasons for hiding away these details:
>>
>> 1. 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.
Exactly.
>> 2. 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).
The state communicated in the UTF-7 decoder is just a bunch
of values. Checking the type is done via PyArg_ParseTuple().
>> 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.
Looking at the UTF-7 decoder this seems to be the
simplest option.
Bye,
Walter Dörwald
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