Why remove the file? I'd just leave it in indefinitely.

Its use is managed by NPY_API_VERSION.

Are you sure it is managed by NPY_API_VERSION? It can be included manually (as per the comment at the top of the file) or by defining NPY_NO_PREFIX and including arrayobject.h. I could find no uses of either of those mechanisms in the rest of the codebase.

I would like to clean up dead code in the codebase.

• A cleaner codebase makes it easier for new developers to join the team
• We should encourage only one set of names for functions, macros, and variables. Having many ways to do things is confusing and leads to unested code paths.

Some of the macros in this 10 year old file look dangerous in 2018, like assuming MAX is a macro not a function, and redefining byte and uint without thought to if they are already defined.

Yeah, you are right about NPY_API_VERSION. But I still think it is a bad idea to remove it, in retrospect I think it was also a bad idea to remove the numeric compatibility module, which I did for the same reasons as you put forth. The numarray removal went OK, but I suspect that was because STSci was one of the few users, the numeric removal actually had to be delayed a year on account on one user, and we still caught Konrad Hinsen by surprise.

Maybe we can start with a warning on import? https://stackoverflow.com/questions/3826832/is-there-a-portable-way-to-print-a-message-from-the-c-preprocessor.

Or we could even make it an error for 1.16 and see if there are any complaints, we can always fix it in a microversion down the line.

Unfortunately, I think few would notice a warning in a C compilation...

• noprefix.h itself says You can directly include noprefix.h as a backward compatibility measure at the top.
• The removal of noprefix.h in SciPy may still make it into 1.2.0, but will break at least builds up to 1.1.0.
• Still a use in matplotlib: https://github.com/matplotlib/matplotlib/blob/master/src/qhull_wrap.c#L9
• A code search turns up more.
• There doesn't seem to be significant use of NPY_NO_PREFIX.

We definitely cannot remove this for 1.17.0, it will break too much. The rationale for this in #12402 (comment) is fair, but I'm afraid we need a longer time scale as well as warnings and actively removing this stuff from at least high-profile code bases like SciPy (already done, thanks @mattip) and Matplotlib. And opening issues on other usage we find with codesearch.com.

A deprecation warning in 1.16, and removal in 1.18 seems to be the minimum - 2 releases and 1 year of heads up at least.

Sounds like we might want to leave this in indefinitely with a warning. We should mention the sed script tools/replace_old_macros.sed that should fix most uses.

I think the removal in SciPy is breaking wheel builds -- I'm inclined to revert the removal for 1.2.0

Thinking about this some more, I've come around to being -1 on removing noprefix.h. True, there is an advantage to downstream projects in using type names that identify themselves as belonging to numpy, but I don't think that justifies our forcing that transition on them. The decision should be theirs, not ours. We might remind them to fix things up, even offer help, but I don't think it should be a numpy project, the change isn't necessary.

A code search turns up more.

All but two of the hist were false-positives: people who had forked or copied numpy, scipy, or matplotlib into their repos.

In any case I will close this for now, maybe we can bring it up again in some future cleanup.