@mhvk - thanks, I'll have a look!

It would certainly help if you could put in a doc string for parser_loop similar to the previous one. Also, comments which define in words all of the variables defined up top would help out a lot. Like the first time I see tm_ptr = args[1], I'd rather not have to guess what's happening or read further in the code to know what that is supposed to be.

@taldcroft - ok, uploaded a version with a lot more comments. Used skip ci to avoid running everything again (tests passed before). I suggest looking at the full parse_times.c rather than the diff...

@mhvk - Thanks for bearing with me. This looks basically good to me now, with just a question about testing. Does this need a test of inputing a strided array? Beyond that, are there features now enabled by doing this via gufunc that didn't work previously?

Since this code appears to managing Python references, what assurance do you have that there are no leaks for the various cases (including different kinds of failures).

One other thing is that I did build this on my Windows 10 VM using Python 3.7 and confirmed that tests passed. I know that those compiler flags were put in there in response to things failing otherwise, but nice to see that they appear to be no longer needed!

@taldcroft - oops, the mistake you pointed out before came back in with the reversion... I'll fix that tomorrow.

On the reference counting: I think I got it right, but note that it is strictly for the ufunc and its associated data with information on start/stop, etc., so this is allocated once and not touched again. The actual call to the parser all goes through numpy's ufunc machinery.

On strided arrays, good point, might as well put in some tests with specifically odd strides.

p.s. And happy to hear windows worked. I was hopeful since the tests passed. I remain unsure how numpy avoids the problems the ctypes implementation had.

OK, addressed the inline comments and added a test with a transposed array to check ordering is as expected.

This might break pytest collection.

I'm getting a pytest error when doing >>> pytest astropy/.

This is the error:
ImportError: dynamic module does not define module export function (PyInit__parse_times)

On further examination, this is only appears when astropy is installed with python setup.py develop.

@nstarman - what platform was this on? I do all my testing with pytest like that and didn't run into a problem on Mac and Windows, though I use pip install -e . (which I think is basically the same as setup.py develop but not 100% sure).

I'm actually having trouble reproducing this. I reinstalled astropy from source and it's gone. I'm hazarding a guess that the problem is related to installing astropy in develop mode and then switching to a branch where there's new compiled code.

Yes, that seems likely - the same would have happened with an update to libwcs or so.