[Numpy-discussion] Removing datetime support for 1.4.x series ?

David Cournapeau david@silveregg.co...
Wed Feb 3 01:42:57 CST 2010


Travis Oliphant 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.  

Ok, thanks for clearing that up.

> I don't remember when it crept in to the ethos.

I don't know when it crept into the NumPy developers, but my own ethos 
is that that's a very fundamental feature of good libraries.

> Yes, it means distributors of packages that depend on NumPy will have  
> to recompile against the new version, and I can see why some might  
> want to avoid that.  Pushing what is really a distribution problem  
> back to the NumPy package to manage separately is not the approach I  
> would take.

I don't think it is accurate to see ABI compatibility as a distribution 
issue. It is mostly an orthogonal issue: it is true that ABI 
incompatibility complicates distributions, but that's not the main issue.

A more important scenario is as follows: let's assume we do allow 
breaking the ABI every 1.X release, meaning that an ABI incompatible 
change happens every ~ 6 months at the current pace (using the last 2-3 
years as history). Now, let's say I have a package foo which depends on 
NumPy, and N other packages which also depend on NumPy. If any new 
version of one of those package needs a new Numpy, you need to rebuild 
everything. If those other packages depends on other libraries as well 
which regularly break ABI, you get exponential breakage, the problem is 
intractable. It is especially hard for packages which may not be easily 
buildable - I think this is the case of many scientific experiments.

I believe this is very detrimental for the whole scipy ecosystem: it is 
only bearable because only NumPy is doing it. If everybody did the same, 
it would be impossible to get anything stable.

David


More information about the NumPy-Discussion mailing list