> Don't you think people ever referred to the type file directly? As in help(file)

Yes, certainly. There is no immediate replacement for that; read the io
documentation.

> dir(file)

Likewise

> file.somemethod(receiver, arg)?

No. Why would anybody want to do that?

> Or even storing a file method in a dictionary for dispatch?

Likewise: what's the use case? Are you sure people store unbound methods
in a dictionary? Why not bound methods?

> I claim they were quite ingrained in Python 2 user's minds.

Partially, perhaps. It's an unfortunate mistake that file ever became
a builtin - that should have been avoided (and py3k corrects it).

> In reviewing the "What's New" for the purpose of this reponse I noticed an
> earlier mention of sys.stdin, sys.stdout, and sys.stderr, where it says they
> are now instances of TextIOBase. (They are actually instances of TextIOWrapper,
> just like the result of open().) 

Notice that sys.stdin/stdout/stderr are indeed instances of TextIOBase:

py> import sys,io
py> isinstance(sys.stdout, io.TextIOBase)
True

> So why can't the documentation of open() say
> that it returns an instance of TextIOBase too?

Because it would be incorrect to say so:

py> isinstance(open("/etc/passwd","rb"), io.TextIOBase)
False

> It just seems like a very wide trap to never mention that the whole file type is gone.

Well, Raymond promised to address this issue in his rewrite.

> OK, I didn't follow the technical details through and, as I said above, I hadn't
> noticed the earlier mention of TextIOBase for sys.stdout, etc. So just say
> something like "The type file is gone, replaced by classes in the IO module.
> Use open() to open a file." 

That would be correct to say. We'll see what Raymond comes up with.

> And maybe add that it returns an instance of
> TextIOBase or TextIOWrapper, whichever is deemed more appropriate.

Neither. It would be correct to say that it returns an instance of
io.IOBase (which isn't really a class, but an ABC).