On Fri, Sep 20, 2019 at 6:09 AM Ralf Gommers <ralf.gomm...@gmail.com> wrote:
> > > On Fri, Sep 20, 2019 at 5:29 AM Robert Kern <robert.k...@gmail.com> wrote: > >> >> We might end up with more than 2 implementations if we need to change >> something about the function signature, for whatever reason, and we want to >> retain C/Cython API compatibility with older code. The C functions aren't >> necessarily going to be one-to-one to the Generator methods. They're just >> part of the implementation. So for example, if we wanted to, say, >> precompute some intermediate values from the given scalar parameters so we >> don't have to recompute them for each element of the `size`-large requested >> output, we might do that in one C function and pass those intermediate >> values as arguments to the C function that does the actual sampling. So >> we'd have two C functions for that one Generator method, and the sampling C >> function will not have the same signature as it did before the modification >> that refactored the work into two functions. In that case, I would not be >> so strict as to require that `Generator.foo` is one to one with >> `random_foo`. >> > > You're saying "be so strict" as if it were a bad thing, or a major effort. > I am. It's an unnecessary limitation on the C API without a corresponding benefit. Your original complaint is much more directly addressed by a "don't gratuitously name related C functions differently than the Python methods they implement" rule (e.g. "gauss" instead of "normal"). > I understand that in some cases a C API can not be evolved in the same way > as a Python API, but in the example you're giving here I'd say you want one > function to be public, and one private. Making both public just exposes > more implementation details for no good reason, and will give us more > maintenance issues long-term. > Not at all. In this example, neither one of those functions is useful without the other. If one is public, both must be. -- Robert Kern
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
