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 <[email protected]> wrote: > 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 > > [email protected] > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io
_______________________________________________ NumPy-Discussion mailing list [email protected] https://mail.scipy.org/mailman/listinfo/numpy-discussion
