On Apr 21, 9:19 pm, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Mon, 22 Apr 2013 10:56:11 +1000, Chris Angelico wrote:
> > You're running this under Windows. The convention on Windows is for
> > end-of-line to be signalled with \r\n, but the convention inside Python
> > is to use just \n. With the normal use of buffered and parsed input,
> > this is all handled for you; with unbuffered input, that translation
> > also seems to be disabled, so your string actually contains '120\r', as
> > will be revealed by its repr().
>
> If that's actually the case, then I would call that a bug in raw_input.
>
> Actually, raw_input doesn't seem to cope well with embedded newlines even
> without the -u option. On Linux, I can embed a control character by
> typing Ctrl-V followed by Ctrl-<char>. E.g. Ctrl-V Ctrl-M to embed a
> carriage return, Ctrl-V Ctrl-J to embed a newline. So watch:
>
> [steve@ando ~]$ python2.7 -c "x = raw_input('Hello? '); print repr(x)"
> Hello? 120^M^Jabc
> '120\r'
>
> Everything after the newline is lost.
>
> --
> StevenMaybe it is related to this bug? http://bugs.python.org/issue11272 -- http://mail.python.org/mailman/listinfo/python-list
