I noticed today that the builtin reversed() requires an explicit sequence and won't work with an iterator instead it throws a TypeError like:

>>> reversed(x for x in [1, 2, 3])
TypeError: argument to reversed() must be a sequence

It would be really great if reversed() worked on iterators too. Currently it requires an explicit list() before you can sent it back into reversed() which seems like it hurts readability.

For what it's worth I discovered this when trying to reverse the output of itertools.dropwhile.

As an additional note this works how I would expect it to work if you're using sorted() instead of reversed() which I think is a stronger point in the favor of making reversed() work this way as well.

>>> sorted(x for x in [1, 2, 3])
[1, 2, 3]

Reversed doesn't make sense for all iterables.

>>> a = set([1, 2, 3])
>>> a = iter(a) # No error
>>> a = reversed(a) # Not typically desirable 

The point is that not all iterables are necessarily ordered.  And a reversed function shouldn't operate on unordered types.

Here's the relevant section of the docs for reversed():

reversed(seq)
    Return a reverse iterator. seq must be an object which has a 
    __reversed__() method or supports the sequence protocol (the 
    __len__() method and the __getitem__() method with integer 
    arguments starting at 0).  

Your point about the sorted()'s behavior seems like a fair one, though. Perhaps it does make sense to support implicit conversion to lists for generator objects passed to reversed().

The two cases are not parallel.
  a = sorted(b)
abbreviates
  a = list(b)
  a.sorted()
which occurred often enough to be a nuisance. With this proposal,
  a = reversed(b)
would abbreviate
  a = reversed(list(b))
which is probably less common and certainly less obnoxious than the two lines condensed by sorted.

A second problem: reversed already has a fallback default if (a presumably more efficient or effective) b.__reversed__ does not exit:

n = len(b)
a = [None]*n
for i,j in enumerate(range(n-1, -1, -1)): # reversed(range(n))
  a[i] = b[j]

(I believe this is more efficient, at least in C, than
  a = []
  for i in range(len(b)-1, -1, -1):
    a.append(b[i])
but it is hard to know.)

At what point, and under what conditions, would you introduce the second fallback?

Sorry, Guido rejected this idea a long time ago.  We do have the __reversed__ hook so you can add reverse iteration to your own classes where it makes sense.

Doing it in the general case is more problematic.  Some data sources such as generators can't be run backwards so they would have to be run to exhaustion and saved in memory to support reversed iteration.  If a user wants this behavior, it is trivial to achieve it by running reversed(list(it)).  The user is in for unhappiness though if the underlying iterator is infinite or huge ;-)