rot13 as I/O encoding (was Re: Python-list Digest, Vol 171, Issue 7)

[Chris Angelico]

On Thu, Dec 7, 2017 at 5:11 AM, Peter Otten <__peter__ at web.de> wrote:
> Chris Angelico wrote:
>
>> On Thu, Dec 7, 2017 at 3:56 AM, Dennis Lee Bieber <wlfraed at ix.netcom.com>
>> wrote:
>>>         Granted, the statistics module in newer Python releases makes the
>>> entire assignment trivial...
>>>
>>> ClgubaJva 3.5.3 (qrsnhyg, Wha 26 2017, 16:17:54) [ZFP i.1900 64 ovg
>>> (NZQ64)] ba jva32.
>>
>> Is this from the Function Call of Cthulu?
>>
>> ChrisA
>
> Perhaps. It is also rot13.

I know, but it looked hilarious. :)

> Fun fact: in Python 2 you could run an actual session using rot13:
>
> $ PYTHONIOENCODING=rot13 python
> Python 2.7.6 (default, Nov 23 2017, 15:49:48)
> [GCC 4.8.4] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> vzcbeg fgngvfgvpf
>>>> vzcbeg enaqbz
>>>> aEbyyf = 50
>>>> ebyyf = [enaqbz.enaqvag(1, 6) sbe wax va enatr(aEbyyf)]
>>>> fgngvfgvpf.zrna(ebyyf)
> 3.5
>

Curiously, that doesn't seem to affect everything.

>>> znc(beq, "abcd")
[97, 98, 99, 100]

According to "python --help", that env var should be setting the
encoding for all three standard streams. So I would expect that the
actual string would contain "nopq", which - when mapped through ord()
- should be [110, 111, 112, 113]. Oh. I'm an idiot. Or rather, I've
gotten so used to Python 3 that I forget how Python 2 works...

>>> znc(beq, h"abcd")
[110, 111, 112, 113]

And that's what I was expecting to see. Except that... variable names
get decoded. And error messages don't.

>>> abcd
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'nopq' is not defined

Curiouser and curiouser!

>>> cevag("abcd")
abcd
>>> cevag(h"abcd")
abcd
>>> "abcd"
'abcd'
>>> h"abcd"
u'nopq'

All tested using Python 2.7.13 on Debian GNU/Linux, if that makes any
difference (I doubt that it will, but you never know).

ChrisA