BUG: Strings with exponent but no decimal point parsed as integers in python csv engine

[evanpw]

Fixes GH #9565. I also made the handling of out-of-range integers consistent with the C engine: parse as a string rather than a double.

[jreback]

I believe this can still fail for an int > int64max (but less < than a uint64max)

[evanpw]

It produces a string in that case:

In [4]: pd.read_csv(StringIO(str(np.iinfo(np.int64).max + 1)), header=None, engine='python').values
Out[4]: array([['9223372036854775808']], dtype=object)

In [5]: pd.read_csv(StringIO(str(np.iinfo(np.int64).min - 1)), header=None, engine='python').values
Out[5]: array([['-9223372036854775809']], dtype=object)

Do you want it to infer the dtype uint64? The C parser doesn't do that either currently.

I don't see how that line ints[i] = int(val) could ever throw an exception, though. Maybe there was some case that's now been eliminated?

[jreback]

pls give this a perf run on the -r csv and see if anything is changed

[jreback]

@evanpw looks good. (FYI if you want to add a confirming case for the out-of-range int64 you have above would be good - not sure that is really tested atm).

and pls run perf and report if anything amiss.

[evanpw]

Integers near the boundary of int64 values were getting parsed as strings because the boundary comparison was performed using doubles. That's fixed in this last commit, and some tests added. Checked performance: no measurable difference with master. Rebased and moved whatsnew entry to 0.16.2.

[jreback]

fyi, you may have to rebase again as I just fixed a travis build error about 10 min ago.

[jreback]

this doesn't work on windows, just revert this section

[jreback]

couple of issues w.r.t. windows. I think some of the libraries are named differently. So just revert that part of the code. ping after travis is green.

[evanpw]

cython libc imports reverted, and tests are green

[jreback]

merged via 38876df

thanks!