Can't reproduce on Linux.

$ python2.7 io.openBugEx.py
Local pref:  UTF-8
LANG env:  uk_UA.utf8
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Local pref:  ANSI_X3.4-1968
LANG env has key:  False
ANSI_X3.4-1968
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

What is your OS?

Mac OSX 10.8.5
Python 2.7.10 installed via macports

$ python2.7 io.openBugEx.py
Local pref:  UTF-8
LANG env:  en_US.UTF-8
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Local pref:
LANG env has key:  False

Traceback (most recent call last):
  File "io.openBugEx.py", line 21, in <module>
    print io.open(tmpfile).read()
LookupError: unknown encoding:

I cannot reproduce this on 10.10.3:

rdmurray@intel-vm-buildbot:~>sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.3
BuildVersion:   14D136

rdmurray@intel-vm-buildbot:~>LANG=en_us.UTF-8 python temp
Local pref:  UTF-8
LANG env:  en_us.UTF-8
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Local pref:  UTF-8
LANG env has key:  False
UTF-8
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL

This is using the installed Apple python, but I get the same result using a recent local 2.7 build.

The difference, and I believe the crux of the issue is that locale.getprefferedencoding() is still returning and encoding for you, mine returns and emtpy str.

Do you have any other envs set that getprefferedencoding my be using:
 'LANGUAGE', 'LC_ALL', 'LC_CTYPE', and 'LANG'
Perhaps if you wipe all of these?

I can reproduce the problem using the MacPorts python2.7 but not the Apple-supplied Python 2.7 or the python.org one.  The difference seems to be that the MacPorts Python is built with the MacPorts-supplied GNU gettext and its libintl, whereas the others aren't (since Apple does not ship libintl).  I don't have time at the moment to dig into why the libintl version of setlocale retunes '' instead of 'US-ASCII'.  Perhaps locale.py or io could handle that case better?

Should I submit elsewhere?

Well, it might be a bug in libintl, but it would be a good idea to investigate further before reporting it upstream to them.  And we may want to deal with the possibility of a blank return regardless.

Please don't change the type of the issue to "crash". This is different type of issues. See classification in https://docs.python.org/devguide/triaging.html#type.

Type changed from cash to behavior.

There are few issues here.

1. Missed "goto error" after setting an exception in TextIOWrapper constructor. This leads to raising wrong and less informative exception (and maybe worse in Python 3, but this is harder to reproduce).

2. getpreferredencoding() can return None in rare circumferences. But no code using it (except TextIOWrapper) expects this. What is better, fail or fallback to ASCII?

New changeset d6238a76c655e0feb13478505220dc9049f1682f by Serhiy Storchaka in branch 'master':
bpo-25359: Add missed "goto error" after setting an exception. (#3712)
https://github.com/python/cpython/commit/d6238a76c655e0feb13478505220dc9049f1682f

New changeset 7e32cee1a68a489c4f2e916ac7003004b51887de by Serhiy Storchaka (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-25359: Add missed "goto error" after setting an exception. (GH-3712) (#3714)
https://github.com/python/cpython/commit/7e32cee1a68a489c4f2e916ac7003004b51887de

New changeset 4954b8dc5305de72ce618522522a2910c3a34126 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-25359: Add missed "goto error" after setting an exception. (GH-3712) (#3779)
https://github.com/python/cpython/commit/4954b8dc5305de72ce618522522a2910c3a34126

Possible related issues: issue6393 and issue30409.