> The only way to do that now is t=frexp(x) and y=ldexp(t[0],t[1]+2).

What's wrong with the more direct ldexp(x, 2)?

N.B.  There *are* edge cases where Martin's suggested alternative won't work.  E.g., to compute 1e-300 * 2**1500:

>>> ldexp(1e-300, 1500)
3.507466211043404e+151

But:

>>> 1e-300 * (1 << 1500)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to float

I'm -1 on the proposal:  I recognise the need for these operations, but I think 'ldexp(x, n)' gives an adequate solution.  Fitting the functionality to the << and >> operators is awkward, because that's not what those operators do for integers (>> produces the *floor* of the quotient, and << doesn't currently accept negative arguments on the right, so there's no neat way for integers to divide by a power of 2).

See also the rejected issue 1205239.