FIX: hdfstore queries of the form where=[('date', '>=', datetime(2013,1,...
```
FIX: hdfstore queries of the form where=[('date', '>=', datetime(2013,1,1)), ('date', '<=', datetime(2014,1,1))] were broken
- modified Expr.parse_back_compat to check for tuples, in w, and unpack into w, op, value
- modified Expr.__init__ to modify the where list/tuple with the parsed result
```

hmm

did u check master with this; I thought I had fixed this already
 would also need some tests for this 
 It broke for me in master, I'll add some tests though.  But first - is this the right way to fix it?  I don't know the pandas codebase that well
 where u made the change is fine
their are already a bunch of tests for the back compat formats
so just add them their (u can add as another test function)
need to make sure that fix doesn't break anything 
 this is fine...can you add a release note (in bug section of 0.14; reference this PR number)
 @hhuuggoo can you add a release note, otherwise looks ready to go
 can you rebase...

and add a test that does an `assert_produces_warning`...that validates that you are in fact showing the warning int he correct place

thanks
 I did it - however something wierd happens.  The test is fine if ran with others, however if I run it on it's own using the following:

`nosetests  -s pandas/io/tests/test_pytables.py:TestHDFStore.test_backwards_compat_without_term_object`

`AssertionError: Caused unexpected warning(s): ['PendingDeprecationWarning'].`

I see some comments about this in the test as well, so it seems like it's a persistent problem?
 @jreback btw, do you know why the query syntax changed?  Is there some discussion of this online I can read?
 that deprecation warning is a weird thing...I have seen it using `assert_produces_warning` - and I can't narrow down why it actually happens

what do you mean why the query syntax changed? The original 'syntax' was just a hack...you could do anything beyond anding and too much verbiage to do anything...

is their a problem?
 there was a whole very long discussion on this...search for 'eval' in the issues....
 @jreback, no problem for me, but personally I prefer the old syntax, because it's easier to programatically build up queries using lists and tuples, rather than doing string operations.  Not a problem, I can always pull out the backwards compat code in my application if I really need to.

anyways I think this PR is done?
 @hhuuggoo thanks!

its not that difficult to put in a combiner to handle built up queries (of say list of sub-queries)...
you may need a wrapper class (which basically does what the older code did, but ends up stringifying)

I think that is done now (but maybe only if you pass Terms...can't remember)

interested?
