Hey Chris (limiting to NumPy only),
I've had some great conversations with Nathaniel in the past few days and
I'm glad he posted his thoughts so that there is no confusion about
governance or what I was implying.
With respect to governance, I'm very supportive of what everyone is doing
in organizing a governance document and approach and appreciate the effort
of Nathaniel and others to move this forward. Nothing I said was meant to
imply differently. I'm sorry if it made anyone nervous.
I'm a very enthusiastic person when I get an idea of what to do. I like
to see things implemented. In this case, it also turns out that in terms
of overall architecture, my ideas are actually very similar to Nathaniel's
ideas. That's a good sign. We have different tactical approaches as to
how to move forward, but I think it's a good thing to note that we see a
very similar path forward. Nothing will be done in NumPy itself except
via pull-request and review.
My approach for the ideas I'm pursuing will be to organize people around
two new prototype packages I'm calling memtype and gufunc. The purpose of
these is to allow playing with the design and ideas quickly before looking
at how to put them into NumPy itself --- there will also be some training
involved in getting people up to speed. There was a long discussion
today at this BIDS data-structures for data-science summit part of which
talked about how to improve NumPy's dtype system. I would love to these
independent objects evolve into independent packages that could even go
into Python standard library. Not everyone agrees that is the best
idea, but regardless of whether this happens or not, the intent is to do
work that could go into NumPy now.
I look forward to the activity.
-Travis
On Mon, Sep 14, 2015 at 10:46 AM, Chris Barker
Travis,
I'm sure you appreciate that this might all look a bit scary, given the recent discussion about numpy governance.
But it's an open-source project, and I, at least, fully understand that going through a big process is NOT the way to get a new idea tried out and implemented. So I think think this is a great development -- I know I want to see something like this dtype work done.
So, as someone who has been around this community for a long time, and dependent on Numeric, numarray, and numpy over the years, this looks like a great development.
And, in fact, with the new governance effort -- I think less scary -- people can go off and work on a branch or fork, do good stuff, and we, as a community, can be assured that API (or even ABI) changes won't be thrust upon us unawares :-)
As for the technical details -- I get a bit lost, not fully understanding the current dtype system either, but do your ideas take us in the direction of having dtypes independent of the container and ufunc machinery -- and thus easier to create new dtypes (even in Python?) 'cause that would be great.
I hope you find the partner you're looking for -- that's a challenge!
-Chris
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
-- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io