"Decoding unicode is not supported" in unusual situation

[Ben Finney]

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:

> On Thu, 08 Mar 2012 08:48:58 +1100, Ben Finney wrote:
> > I think that's a Python bug. If the latter succeeds as a no-op, the
> > former should also succeed as a no-op. Neither should ever get any
> > errors when ‘s’ is a ‘unicode’ object already.
>
> No. The semantics of the unicode function (technically: a type 
> constructor) are well-defined, and there are two distinct behaviours:

That is documented, right. Thanks for drawing my attention to it.

> > Yes, this check should not be necessary; calling the ‘unicode’
> > constructor with an object that's already an instance of ‘unicode’
> > should just return the object as-is, IMO. It shouldn't matter that
> > you've specified how decoding errors are to be handled, because in
> > that case no decoding happens anyway.
>
> I don't believe that it is the job of unicode() to Do What I Mean, but 
> only to Do What I Say. If I *explicitly* tell unicode() to decode the 
> argument (by specifying either the codec or the error handler or both) 

That's where I disagree. Specifying what to do in the case of decoding
errors is *not* explicitly requesting to decode.

The decision of whether to decode is up to the object, not the caller.
Specifying an error handler *in case* decoding errors happen is not the
same as specifying that decoding must happen.

In other words: I think specifying an encoding is saying “decode this”,
but I don't think the same is true of specifying an error handler.

> End-user applications may, with care, try to be smart and DWIM, but 
> library functions should be dumb and should do what they are told.

Agreed, and I think this is compatible with my position.

-- 
 \     “Creativity can be a social contribution, but only in so far as |
  `\         society is free to use the results.” —Richard M. Stallman |
_o__)                                                                  |
Ben Finney