Good catch! Looks good, modulo possible issue with the updated tests (let's wait for @Michael0x2a to comment on it.)

This is probably fine, I think?

I think there's some sort of weird inconsistency going on here due to how we basically always parse pyi files with the Python 3 parser.

For example, here's what happens if we create a dummy.pyi file and run mypy --py2 dummy.pyi:

from typing_extensions import Literal

alias1 = Literal['foo']
alias2 = Literal[b'foo']
alias3 = Literal[u'foo']

a1: alias1
a2: alias2
a3: alias3

reveal_type(a1)  # Revealed type is Literal['foo']
reveal_type(a2)  # Revealed type is Literal['foo']
reveal_type(a3)  # Revealed type is Literal['foo']

b1: Literal['foo']
b2: Literal[b'foo']
b3: Literal[u'foo']

reveal_type(b1)  # Revealed type is Literal[u'foo']
reveal_type(b2)  # Revealed type is Literal['foo']
reveal_type(b3)  # Revealed type is Literal[u'foo']

c1 = ...  # type: Literal['foo']
c2 = ...  # type: Literal[b'foo']
c3 = ...  # type: Literal[u'foo']

reveal_type(c1)  # Revealed type is Literal[u'foo']
reveal_type(c2)  # Revealed type is Literal['foo']
reveal_type(c3)  # Revealed type is Literal[u'foo']

Notice that something wonky happens when we try creating a Literal alias inside the stub files: they seemingly somehow always get converted into bytes. This is obviously surprising: you'd expect the revealed types for a1/a2/a3 to be identical to the other two sets -- or at the very least, for a3 to be unicode.

This is a bug -- but one that's always existed before and is now being properly exposed by this diff, I think?