BUG: nested construction with timedelta #11129

[chris-b1]

Closes #11129

Per discussion in issue this adds similar hash equality to _Timedelta / datetime.timedelta
that exists for _Timestamp / datetime.datime.

I tried inlining _Timedelta._ensure_components and it actually hurt performance a bit, so I left it
as a plain def but did build a seperate _has_ns check for hashing.

Adds a little overhead to hashing:

In [1]: tds = pd.timedelta_range('1 day', periods=100000)

# PR
In [2]: %timeit [hash(td) for td in tds]
1 loops, best of 3: 810 ms per loop

# Master
In [2]: %timeit [hash(td) for td in tds]
1 loops, best of 3: 765 ms per loop

[jreback]

try making it a cpdef

[jreback]

hmm, no reason ever to do hash like that in a loop though..

[jreback]

make this a method of _Timedelta.

self.value % 1000 != 0 (might be same speed)

[chris-b1]

changing to a cpdef didn't seem to matter, assuming I'm profiling the right thing (I think component access would take a call to _ensure_components())?

In [2]: %timeit tds.microseconds
#cpdef
1 loops, best of 3: 776 ms per loop
#def
1 loops, best of 3: 775 ms per loop

[jreback]

lgtm. pls change _has_ns to be a method of _Timedelta

[chris-b1]

@jreback made that change, Travis green.

[jreback]

thank u sir!