latin1 and cp1252 inconsistent?

[Ian Kelly]

On Sat, Nov 17, 2012 at 11:08 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Sat, Nov 17, 2012 at 9:56 AM,  <buck at yelp.com> wrote:
>> "should" is a wish. The reality is that documents (and especially URLs) exist that can be decoded with latin1, but will backtrace with cp1252. I see this as a sign that a small refactorization of cp1252 is in order. The proposal is to change those "UNDEFINED" entries to "<control>" entries, as is done here:
>>
>> http://dvcs.w3.org/hg/encoding/raw-file/tip/index-windows-1252.txt
>>
>> and here:
>>
>> ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt
>
> The README for the "BestFit" document states:
>
> """
> These tables include "best fit" behavior which is not present in the
> other files. Examples of best fit
> are converting fullwidth letters to their counterparts when converting
> to single byte code pages, and
> mapping the Infinity character to the number 8.
> """
>
> This does not sound like appropriate behavior for a generalized
> conversion scheme.  It is also noted that the "BestFit" document is
> not authoritative at:
>
> http://www.iana.org/assignments/charset-reg/windows-1252

I meant to also comment on the first link, but forgot.  As that
document is published by the W3C, I understand it to be specific to
the Web, which Python is not.  Hence I think the more general Unicode
specification is more appropriate for Python.