On 15 October 2012 01:35, MRAB <span dir="ltr"><<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.plus.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>On 2012-10-15 01:12, Joshua Landau wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On 15 October 2012 00:46, MRAB <<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.plus.com</a><br></div><div>
<mailto:<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.<u></u>plus.com</a>>> wrote:<br>
<br>
    OK, but what about raw string literals? Currently, "\\u0190" ==<br>
    r"\u0190", but "\\u0190" != r"Ɛ".<br>
<br>
<br>
The “r"” prefix escapes all escapes, so will escape this escape too.<br>
Hence, this behaviour is un...escaped ;).<br>
<br>
</div></blockquote>
If "\u0190" becomes "Ɛ", what happens to "\u000A"? Currently it's<br>
legal. :-)</blockquote><div><br></div><div>The python interpreter could distinguish between its morphed Unicode escapes and the originals - the escapes would never match against already-syntactically-relevant constructs*. Hence "a \u0069s b" is equivalent to "a i\u0073 b" but <i>not</i> "a is b": the first two are defined by __op_is__ and the last is just the "is" keyword.</div>



<div><br></div><div>Hence, \u000A would just act like a character, and be definable as an operator, and have little to do with the newline character.</div><div><br></div><div>Nice try, but the proposal stands firm.</div>



</div><br>
<div>* Except, of course, the old operators which will be phased into the new mechanism.</div>