[BUG] change types to Py_ssize_t to fix #21905
May close #21905, will need to check with OP.

I've run the complete test suite on this. Everything passes beautifully. # [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/21923?src=pr&el=h1) Report
> Merging [#21923](https://codecov.io/gh/pandas-dev/pandas/pull/21923?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/b2305ea6d7ca1787bce8eb646a1791a0399353e7?src=pr&el=desc) will **not change** coverage.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/pandas-dev/pandas/pull/21923/graphs/tree.svg?height=150&width=650&token=eZ4WkYLtcO&src=pr)](https://codecov.io/gh/pandas-dev/pandas/pull/21923?src=pr&el=tree)

```diff
@@           Coverage Diff           @@
##           master   #21923   +/-   ##
=======================================
  Coverage   91.96%   91.96%           
=======================================
  Files         166      166           
  Lines       50323    50323           
=======================================
  Hits        46281    46281           
  Misses       4042     4042
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `90.36% <ø> (ø)` | :arrow_up: |
| #single | `42.23% <ø> (ø)` | :arrow_up: |


------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/21923?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/21923?src=pr&el=footer). Last update [b2305ea...320ec11](https://codecov.io/gh/pandas-dev/pandas/pull/21923?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
 @jbrockmendel : Can we add a `whatsnew` entry for this? > Can we add a `whatsnew` entry for this?

I don't think so, the relevant bug was only introduced a few days ago. Is it possible to add 32-bit tests to the testing systems, to guard against similar bugs in the future? @topper-123 : I don't see why not.  Feel free to propose some if you have ideas. @topper-123 might want to discuss in #13715.

@jreback this should be good to go. uh, I 've never set such things up before, so it will proabbly take more time than I'd like. 

It's very seldom that things like this happen, so maybe it's so rare, that building it into the testing systems will be overkill? > uh, I 've never set such things up before, so it will proabbly take more time than I'd like.
>
> It's very seldom that things like this happen, so maybe it's so rare, that building it into the testing systems will be overkill?

@topper-123 : Not overkill but not straightforward to do.  I tried once emulating what `numpy` did (the start of the fun can be found [here](https://github.com/numpy/numpy/blob/master/.travis.yml#L42)), but even that was surprisingly error-prone (see [here](https://github.com/pandas-dev/pandas/pull/13584#issuecomment-231291434)) 32 bit testing happens on another CI on a daily basis

it’s a PITA because it’s not easily testable (eg you can run your PR against it) - this is a limited of travis currently

but haven’t put much effort because we should just drop 32 bit anyways

OTOH datetime changes often force these 32 bugs to the surface Unless there’s an objection, let’s move the CI discussion to #13715 and push this bug fix through. ok I sorted the wheels CI, now its passing, except for 32-bit: https://travis-ci.org/MacPython/pandas-wheels/jobs/404670455

is this PR intended to fix these? Exactly. ok let's see. I just built the newest master release with this PR and tested it.

Everything built correctly and all tests passed.