BUG: del df[k] with non-unique key

[ghost]

This touches some delicate functions to be messing with, so I've split off the
underlying logic into a function in common and added an exhaustive test.
Would welcome review none the less.

Also, I tried to test for nagative perf. There must something
wrong with the test since comparing the commit after just adding a test to the baseline,
shows 50% degredation in a bunch of things. As I said, I don't trust this, ideas?

timeseries_asof_nan                       23.4131    15.7471 1.4868
datetimeindex_normalize                 1153.1918   774.8010 1.4884
timeseries_asof                           22.3342    14.9964 1.4893
reshape_unstack_simple                     4.8106     3.2289 1.4899
read_table_multiple_date_baseline        980.0920   657.3641 1.4909
timeseries_1min_5min_mean                  0.8087     0.5422 1.4915
timeseries_timestamp_tzinfo_cons           0.0210     0.0141 1.4922
match_strings                              0.5718     0.3817 1.4982
timeseries_large_lookup_value              0.0301     0.0201 1.4998
reindex_fillna_pad                         0.1828     0.1217 1.5018
timeseries_to_datetime_iso8601             5.6048     3.7270 1.5038
read_table_multiple_date                2169.5440  1441.5460 1.5050
reindex_daterange_pad                      0.2608     0.1731 1.5066
timeseries_1min_5min_ohlc                  0.8046     0.5331 1.5092
reindex_daterange_backfill                 0.2466     0.1634 1.5094
period_setitem                          1166.9910   772.4509 1.5108
reindex_fillna_backfill                    0.1790     0.1183 1.5130
timeseries_asof_single                     0.0656     0.0434 1.5136
append_frame_single_mixed                  2.0747     1.3697 1.5147
timeseries_slice_minutely                  0.0762     0.0501 1.5208

Columns: test_name | target_duration [ms] | baseline_duration [ms] | ratio

(01bc3e0 against 81169f9)

- a Ratio of 1.30 means the target commit is 30% slower then the baseline.

closes #2347

[wesm]

I'll check on my machine when I get a chance if there's any perf difference.

I also need to figure out why Travis has become totally borked. most likely my fault

[ghost]

yeah, things are failing on py2 as well now, and I don't think that's a problem on the travis side.
they recently started preinstalling numpy on the vm to speed things up, perhaps related?

[ghost]

@wesm, reverting 4a200b8 seems to restore py2 builds on travis.

[wesm]

Oh definitely. I'll fix asap

[wesm]

Vbenchmarks looked fine on my end so I went ahead and merged this one

[wesm]

On Python 3 it looks like some issue with NumPy using sys.__stdout__. But I don't know what could have changed (must be something in the travis environment)

[ghost]

it's in the final stages of resolution, should be fixed once travis upgrade to venv 1.8.4 within a couple days
https://github.com/numpy/numpy/issues/ 2761

[wesm]

Great. looks like venv 1.8.4 was cut today