Python 3 compatibility
No doubt there are ways this could be improved, but this gets it installing, importing, and _almost_ passing the test suite.

There's one test failure left, and I think that's something odd with numpy, specifically the `ndarray.searchsorted()` method. It returns seemingly random results when it's called in `panel.get_axis_dummies()` - but I can't replicate those results calling searchsorted on identical arrays interactively.

It doesn't add any failures to the Python 2 test suite (one test is failing for me in master), but I've only checked this with Python 2.7.

This is really great-- thanks for doing this. It's also impetus for me to get Python3+NumPy+SciPy installed on my machine for testing purposes. I will do that, run the test suiteu, and merge this in as soon as I can.
 You're welcome!
 Rebased this and merged it in. There are some test failures in what appear to be corner cases in NumPy trunk, I will have to investigate those some other time
 Thanks Wes. For the record, I was testing with Numpy 1.6.1.
 Thomas, can you help me figure out why the cython command stopped working once setuptools is introduced (for the purpose of running 2to3)? I'm talking about:

```
python setup.py cython
```
 in the meantime, I kludged things so setuptools only gets imported in py3k, so no urgency

https://github.com/wesm/pandas/commit/5a330385479edbe715daedaceb59c3a222a84e0f
 I'll have a look - I'd just been doing `python setup.py install`.
 It appears to work for me with setuptools 0.6 from Ubuntu repos, or with distribute 0.6.19 as installed by virtualenv.

<pre>
abc
running cython
cythoning pandas/src/tseries.pyx to pandas/src/tseries.c
cythoning pandas/src/sparse.pyx to pandas/src/sparse.c
</pre>


(the `abc` is from a print statement I added just below the setuptools import)
 that's prior to my kludge, right? i was running it on win32 to see if I can distribute 3.x binaries for the imminent next release. sigh, windows, the source of so much dev unhappiness 
 Here's another not so awesome thing: on 3.1/3.2 on Win32 (haven't tested Win64 yet), the default csv writer writes not 1, but 2 line breaks per line. Specifying explicitly lineterminator='\n' for now which solves the problem (I think csv.reader interprets CRLF as \n\n which seems really bad)
 I tweaked your kludge so it imported setuptools on both platforms (the `abc` is to check that it's getting imported).

With Windows, I think it writes `\r\n` by default. Unix-y programs might interpret that as two line breaks, but it's the platform default for Windows. Explicitly specifying the lineseparator is probably sensible.

I don't have Windows to hand, but I can test in Wine if you like.
