With this fix, print(np.fromstring(", 1,2,3", sep= ",",dtype =np.int64)) will print [1 2 3]. Should it?

close/reopen

Looking at this, I'm not convinced the result should be []. Apparently white space (\n) is interpreted as -1. For instance

In [17]: fromstring(' , ',sep=',')                                              
Out[17]: array([-1., -1.])

That may be a problem, but it is a different problem. I'm not yet clear where that value comes from. @seberg Thoughts?

This raises a FutureWarning with other separators.

n [7]: fromstring(',',sep=',')                                                 
<ipython-input-7-5aea430bb5d9>:1: DeprecationWarning: string or file could not be read to its end due to unmatched data; this will raise a ValueError in the future.
  fromstring(',',sep=',')
Out[7]: array([], dtype=float64)

Uh, that is strange... It seems you are right and whitespace is parsed as a number and that number is -1.... That explains how the -1. can be so persistent.

It basically drops out of this:

Now, that should indicate that an error occurred, by resetting the end-pointer to the start position on error, which then should trigger the error return path here:

Which then has a negative return value indicating an error in the read.

All of that seems a bit strange and every single level of that code looks like it could be smoothened a bit more. Maybe we should try and see if we can do a proper deprecation of that -1 if the -1 works for reliably for everything that cannot be read.

The bug seems to be that call to string_is_fully_read which probably does the right thing for the skip function, but not for the parse function. Since it checks start >= end and equality holds here.

The easier fix should probably to properly propagate a -1 return value when not successfully reading from dtype->f->fromstr (or even lower). The only question is whether we want to try a deprecation there, I am not sure how easy it is.

Long story short, the -1. is definitely an accident (I wonder if it has always been there, or an artifact of fixing another bug). But if we want to gently "deprecate" it, I guess it might be a bit tricky. If we are happy to not be gentle about it, I expect the string_is_fully_read might just be unnecessary after an unsuccessfull value parsing attempt. (worst case, we have to check for a leading \0 maybe, in case the string is fully empty.