D extensions to python, inline in an ipython/jupyter notebook

[Laeeth Isharc via Digitalmars-d-announce]

On Thursday, 2 July 2015 at 18:28:50 UTC, Russel Winder wrote:
> On Tue, 2015-06-30 at 18:20 +0000, John Colvin via Digitalmars-d
> -announce
>  […]
>> 
>> Ditched distutils in favour of dub. This is easier for me to 
>> maintain and fits much better with the rest of the D ecosystem
>
> I am not convinced by this, though cleary my feeling carry no 
> weight in decision making :-)
>
> For building C, and C++ extension (and indeed Chapel ones) it 
> is assumed distutils will be used, allowing for:
>
> 	python3 setup.py build
>
> 	python3 setup.py install
>
> SCons can do this but every one demands distutils. Can dub 
> really replace distutils for installing extensions as well as 
> building them? Will people installing extensions be prepared to 
> switch to a non -standard system? Whilst perhaps they should, 
> they won't. I fear that without a distutils installation, the 
> extension will never be installed outside the development team. 
> It's not the D community that must be convinced, it is the 
> Python one.

What is the benefit from using distutils for working with D in a 
notebook?  There are two standards - the Python one, and the D 
one.  The advantage of using dub is that it becomes wonderfully 
easy to pull in D projects from code.dlang.org and to compile 
your own work developed under dub.  (And dub itself continues to 
improve).  Linking to a D project of decent complexity via 
distutils is not my idea of fun.

I do agree that for pyd itself it would be nice to retain the 
option of distutils (although I would love to see dub added also),

One should look at this as an alpha, extremely promising project. 
  It is not any rough edges that are important at this stage, but 
that it has been done at all (in a form that is already very 
valuable).

The set of people that want to use computers to explore larger 
data sets than lately considered comfortable in an iterative 
manner is not small, even confining It just to finance.  It's of 
real value to be able to hook in to a proper back end that 
manages market and static data, with also any data processing and 
analytics also in D, and then to have a pretty and friendly front 
end that can just talk to this code on the back with minimal 
messing around to get there.  It's also very nice to have both 
Jupyter and an Excel spreadsheet at windows onto the data on your 
local machine or in the enterprise cloud.

The frictions to starting to play with D in a notebook are much 
lower than going via the command line, so I really am not sure if 
we should be worried about making it marketable at this stage 
rather than useful for doing real work.  It's potentially a nice 
debugging tool where you are trying to make sense of things that 
don't tidily fit in a debugging window, and where there is just 
too much stuff to do it via writefln or logging without putting 
lots of effort into the infrastructure to find events first.

I do like the simpler syntax (than PyD).  One question is whether 
you need to wrap every member of a struct.

But it's a very useful start as it stands.