CLN: Refactor series datetime arithmetic

[jtratner]

This is a prelude to the larger refactoring of arithmetic into core/ops,
etc. It doesn't change any external behavior (and I'm relatively confident that
the test suite covers all the branches).

The complexity of the time arithmetic code was making it hard to tweak,
so I decided to change it up. It's not that complicated, but wanted to
run it by you all in an easy-to-read diff before I change its files.

Specifically it:

1. Moves Series time arithmetic out of _arith_method into a encapsulated _TimeOp class.
2. Consolidates the previously repeated type conversions into one.
3. Separates validations from type conversions, which makes the function
   easier to follow and write.
4. Changes all obscure character codes to clear ones.
5. Removes the unnecessary set() calls in convert_to_array.

[jtratner]

@cpcloud it probably should be a style convention going forward to avoid using character codes in favor of the clearer, more verbose names.

For example, this previously had two separate conditional branches that did:

if cond1:
    lvalues.astype('i8')
    rvalues.astype('i8')
elif cond2:
    lvalues.astype(np.int64)
    rvalues.astype(np.int64)

Written like the above, it's harder to see they do the same thing and can be combined.

I'd also argue that dtypes like m8[ns] and M8[ns] should be written as timedelta64[ns]and datetime64[ns] respectively. Much clearer that way.

[jreback]

would it make sense to have a class hold the self and other then have the functions as methods of the class? (maybe in core/ops)

something like

t = _TimeOps(self, other)
t.get_result()

this patter is pretty common
eg concat, groupby etc

makes things into nice packages
rther than just collectives of functions

[jreback]

agree about dtype codes (though i8 is very common)

[cpcloud]

i really don't like that m8[unit] business so +1 on the type code stuff

[jtratner]

@jreback that's a good idea - it was definitely getting awkward to pass everything around like that.

on type codes, it's not that it's wrong, it's just confusing for those who aren't in the know (or are skimming) 😄

[cpcloud]

OTOH it's extremely cumbersome to type out datetime64[ns] all the time (esp. in ipython)....hopefully pandas takes a lot of the pain away of having to manually cast things like that 😄 however a simple td64[ns] or dt64[ns] would have sufficed. Wonder where the m comes from...

[cpcloud]

let me not derail. i'm also +1 on the _TimeOps encapsulation.

god forbid we started using the ? type code (bool). kind of weird. i guess it's a tip of the hat to its C roots a la a == b ? a : b

[jtratner]

I'm slightly mystified by the test failure here - I assume that it's a real failure, because it's failing on the same test (and no output should change from current master). Maybe I introduced a type mismatch? I also don't get why 2.7 and 3.3 would pass but not 2.6 or 3.2.

[cpcloud]

sounds like a numpy 1.6 issue...2.6 and 3.2 both have np 1.6.1 and 1.6.2 respectively while 2.7 and 3.3 have 1.7.1

[jtratner]

whelp I'll figure it out...

[jtratner]

@jreback @cpcloud finally got this all cleaned up, working and refactored into a class. I'll squash the commits down into 1 big commit after any comments on this are addressed. (much easier to tweak with the split out commits). Plus, the Series arithmetic method is now much cleaner.

After this is finished, will be much easier to do the ops refactor.

[jtratner]

okay, I squashed this such that it's ready to go - obviously this will later be moved into core/ops, but, as I said, I wanted to do this separately because it's more complicated than the other refactoring.

[jreback]

@jtratner looks good to me....your first merge (that you do yourself)!

[jreback]

maye should create a core/types.py where
all type stuff is consolidated ? (pretty much in common.py now)

[jtratner]

Yeah, that might make sense - I'll keep that in mind. Now on to finishing up the arithmetic refactoring!