Will this have any impact on the difficulty of finding "where is np.foo or ndarray.bar implemented"?
On Thu, Oct 7, 2021 at 3:02 PM Sebastian Berg <sebast...@sipsolutions.net> wrote: > On Wed, 2021-08-25 at 17:50 -0500, Sebastian Berg wrote: > > On Wed, 2021-08-25 at 17:48 +0200, Serge Guelton wrote: > > > Hi folks, > > > > > > https://github.com/numpy/numpy/pull/19713 showcases what *could* be > > > a > > > first step > > > toward getting rid of generated C code within numpy, in favor of > > > some > > > C++ code, > > > coupled with a single macro trick. > > > A brief update on this: The current plan would be to include this in > the next release. Largely as a trial balloon, so we see if there are > any issues, e.g. with deployment, and can revert the changes if there > are. > > That would mean that some time within the next release cycle using C++ > for more things could be on the table and less difficult to discuss. > > Not knowing the C++ much myself, I assume that the current approach is > fine and the only remaining thing is a brief review of the new code to > ensure correct translation from C. (Which does not preclude refining > the C++ code later.) > > Cheers, > > Sebastian > > > > > > > > Basically, templated code is an easy and robust way to replace > > > generated code > > > (the C++ compiler becomes the code generator when instantiating > > > code), and a > > > single X-macro takes care of the glue with the C world. > > > > I am not a C++ export, and really have to get to used to this code. > > So > > I would prefer if some C++ experts can look at it and give feedback. > > > > This will be a bit harder to read for me than our `.c.src` code for a > > while. But on the up-side, I am frustrated by my IDE not being able > > to > > deal with the `c.src` templating. > > > > One reaction reading the X-macro trick is that I would be more > > comfortable with a positive list rather than block-listing. It just > > felt a bit like too much magic and I am not sure how good it is to > > assume we usually want to export everything (for one, datetimes are > > pretty special). > > > > Even if it is verbose, I would not mind if we just list everything, > > so > > long we have short-hands for all-integers, all-float, all-inexact, > > etc. > > > > > > > > > > Some changes in distutils were needed to cope with C++-specific > > > flags, and > > > extensions that consist in mixed C and C++ code. > > > > <snip> > > > > > Potential follow-ups : > > > > > > - do we want to use -nostdlib, to be sure we don't bring any C++ > > > runtime dep? > > > > What does this mean for compatibility? It sounds reasonable to me > > for > > now if it increases systems we can run on, but I really don't know. > > > > > - what about -fno-exception, -fno-rtti? > > > > How do C++ exceptions work at run-time? What if I store a C++ > > function > > pointer that raises an exception and use it from a C program? Does > > it > > add run-time overhead, do we need that `no-exception` to define that > > our functions are actually C "calling convention" in this regard?! > > > > Run-time calling convention changes worry me, because I am not sure > > C++ > > exception have a place in the current or even future ABI. All our > > current API use a `-1` return value for exceptions. > > > > This is just like Python's type slots, so there must be "off the > > shelve" approaches for this? > > > > Embracing C++ exceptions seems a bit steep to me right now, unless I > > am > > missing something awesome? > > > > I will note that a lot of the functions that we want to template like > > this, are – and should be – accessible as public API (i.e. you can > > ask > > NumPy to give you the function pointer). > > > > Cheers, > > > > Sebastian > > > > > > > - coding style? > > > - (I'm-not-a-farseer-I-don-t-know-all-topics) > > > > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion@python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: jbrockmen...@gmail.com >
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
