On Tue, Feb 2, 2010 at 10:45 PM, Travis Oliphant <oliph...@enthought.com>wrote:
> > On Feb 2, 2010, at 8:53 PM, David Cournapeau wrote: > > > Travis Oliphant wrote: > > > >> I think we just signal the breakage in 1.4.1 and move forward. The > >> datetime is useful as a place-holder for data. Math on date-time > >> arrays > >> just doesn't work yet. I don't think removing it is the right > >> approach. It would be better to spend the time on fleshing out the > >> ufuncs and conversion functions for date-time support. > > > > Just so that there is no confusion: it is only about removing it for > > 1.4.x, not about removing datetime altogether. It seems that > > datetime in > > 1.4.x has few users, whereas breaking ABI is a nuisance for many more > > people. In particular, people who update NumPy 1.4.0 cannot use > > scipy or > > matplotlib unless they build it by themselves as well - we are talking > > about thousand of people at least assuming sourceforge numbers are > > accurate. > > > > More fundamentally though, what is your opinion about ABI ? Am I right > > to understand you don't consider is as significant ? > > I consider ABI a very significant think. We should be very accurate > about when a re-compile is required. I just don't believe that we > should be promising ABI compatibility at .X releases. I never had > that intention. I don't remember when it crept in to the ethos. > > About 1.2 after the discussion at SciPy. The general consensus was that breaking the ABI was a very bad thing, not to be taken lightly. We are currently bumping the .X number about twice a year, which is too frequent to allow changes at each iteration. IMHO. I would think changes to the ABI would be more a two/three year sort of thing and only under the pressure of necessity. At some point we need to do a major refactoring to hide the structures and make it easier to add types, but I don't see that in the near future. I don't think we should add any more types to the current code after datetime goes in, it's just too big a hassle the way things are now. I'm thinking numpy types should basically interface to the c-types, and new types should subclass or build new classes on top of that. That keeps things simple. <snip> Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion