On Thu, Nov 18, 2010 at 2:41 PM, Terry J. Reedy <report@bugs.python.org> wrote:
..
> I visually parse 0-1,114,111 as 0-1, 114, 111. So I think either the commas
> should be removed or extra spaces are needed: 0-1114111 or 0 - 1,114,111.

What about "0 through 1,114,111"?

> you used (or stayed with) 'hexadecimal' versus 'base 16'. Do we have a standard?
> I *think* I prefer the former.

I prefer 'base 16'.  I thought about changing 'hexadecimal' to 'base
16' in chr/ord docs, but decided to leave it because the term
'hexadecimal' is used elsewhere on the same page notably in hex()
function description where it is quite appropriate.   No, we don't
have a standard.  I've also seen "base-16" used elsewhere which I
really don't like.

> +    '�abc'
>
> Three replacements (i with diaeresis, upside-down ?, 1/2) for one bad char looks wrong.

That must be UTF-8 misinterpreted as Latin-1.  Won't affect the commit.

> With IDLE I get '�abc' (? in hexagon, codepoint 65533). Perhaps something
> just went wrong to patch from your file to my browser window.

Yes.  I get the same on the terminal window and that's what it should look like.

>  built-in :func:`ord` function that takes a one-character Unicode string and
>  returns the code point value::
>
> You fixed chr/ord doc, need to fix references thereto in this doc.
>

I don't understand.  I think "one-character Unicode string" is fine
here because "Unicode string" means an abstract Unicode string, not
:class:`str`.

> -point.  The ``\U`` escape sequence is similar, but expects 8 hex digits, not 4::
> +point.  The ``\U`` escape sequence is similar, but expects eight base 16
> +digits, not four::
>
> I really think of them as hex or hexadecimal digits, just as 0-9 are decimal, not base 10 digits.
>

I am fine with "hexadecimal" here.  I did not like "hex".