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 at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150914/34c7696c/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4