[SciPy-Dev] merging optional Pythran support soon

[Serge Guelton]

On Sun, Dec 27, 2020 at 04:46:36PM -0700, Tyler Reddy wrote:
> Hi,

Hi, Pythran maintainer here. You're points make sense, let me second them with a
few more technical details.

> I'm probably a bit more cautious re: "maintenance burden" but don't see an
> issue with experimentation and gradual adoption if the team is in favor (I
> haven't seen any substantial objections). It is perhaps fair to note that "pure
> Python" is perhaps a little optimistic--I believe there are at least a few
> restrictions here and perhaps a few more if you take mixed Python/NumPy code
> and expect full Pythran benefits with no modifications. We did notice in an

That's correct. A goog example would be that it's sometime more efficient to
write the loop explicitly than doing the high-level equivalent Numpy operation.
That's fortunately not always the case but there are still room for improvement
there. Stated differently, even if it's pure Python, one may be tented to
optimize the code for transpiling.

> earlier iteration of that PR that producing identical behavior for algorithms
> that depend on the details of random number generation under the hood in NumPy
> also requires some caution beyond merely decorating the code for transpiling.

Pythran strives for 100% reproducibility of observable behavior. Until now we've
been using a different PRNG than Numpy's (for perfrmance reason, mostly). But we
could use the same, that would also solve a CI difficulty we have when testing
numpy.random and random package.