Steven D'Aprano <steve+comp.lang.pyt...@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 -- http://mail.python.org/mailman/listinfo/python-list