Message9965

I have mixed feelings about this: it's nice to be able to do something like `eval(r'u"\uD800"')` to see if the Python being run on supports lone surrogates (and not having to hardcode a list of implementations that do/don't). Also seems a bit evil given in a fair few cases it'll suddenly fail much later on when dealing with the string (when toString is called, which isn't obvious from the Python level), and I'm not sure TypeError makes sense there, though I'm not sure what does.

To make a counter-proposal: allow them to parse, but doing *anything* with them throw the error. This allows for something like:

```
try:
    eval(r'u"\uD800"[0]')
except SyntaxError, TypeError:
    supportsSurrogates = False
else:
    supportsSurrogates = True

if supportsSurrogates:
    x = u"[\uD800-\uDFFF]"
else:
    x = u""
```

That said, that's quite a lot more work to do. Meh. Not sure what to suggest.

Also, just to point out: in principle, "\UFFFFFFFF" should still fail. Nothing else actually uses 32-bit code units, despite what the documentation suggests.

Speaking of PEP 939 and Python 3.3, note the definition of the Unicode type changed to be "a sequence of values that represent Unicode code points", which implicitly allows surrogates (both unpaired and paired), so the hypothetical Python 3 release of Jython will eventually have to deal with them properly somehow.