On 10/25/20 5:23 AM, Matti Picus wrote: > > On 10/25/20 10:46 AM, Dustin Spicuzza wrote: >> I took a first stab at it, and... surprise, surprise, there were a few >> more warts than I had originally expected in my initial survey. The >> biggest unexpected result is that numpy.f2py would need to also be a >> toplevel package. I did get the refactor cross-compiled and started on >> scipy, but there's a few more issues that will have to be resolved on >> the scipy side. >> >> I posted a detailed set of notes on the issue (#17620) and made a draft >> PR with my initial results (#17632) if you want to get a sense for how >> invasive this is (or isn't depending on your point of view). >> >> Dustin >> > Is there a way to do this without modifying SciPy? That would reassure > me that this change will not break other peoples' workflow. It is hard > to believe that only SciPy uses numpy.distutils. If the changes break > backward compatibility, they need to be done like any other > deprecation: warn for 4 releases (two years) before actually breaking > workflows. > > > Matti
Sorry for not being clear, when I was discussing modifications to scipy I was referring to the specific use case of cross-compilation. The goal is that existing native builds would not break backwards compatibility. To that end, there's a package redirection stub in my PR for both numpy.distutils and numpy.f2py. Just tried a native build using my current PR branch and at the moment scipy doesn't work. However, it's a size mismatch during compilation as opposed to an ImportError, so I probably just missed a subtlety when I moved things. But I would definitely expect the finalized version of this set of changes should not break existing users. Dustin _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
