On Fri, Sep 28, 2012 at 3:11 PM, Charles R Harris <charlesr.har...@gmail.com> wrote: > If the behaviour is not specified and tested, there is no guarantee that it > will continue.
This is an open-source project - there is no guarantee of ANYTHING. But that being said, the specification and testing of numpy is quite weak -- we have no choice but to use unspecified and untested (and how do we even know what is tested?) features. So, be definition, the current code base IS the specification -- if it changes that is a change in the spec. Travis is right -- we users are the test cases -- which is better than most code, frankly. Perhaps more effort could be put into considering the impact that internal changes have, and announcing them more aggressively? So we in the user community have a better idea what to look for when adopting/testing a new release (candidate). Another thought -- perhaps we're being too incremental, and a py3k type change is in order -- do a while bunch at once. Though, as we've seen with py3k, that would mean maintaining two version for a good long while... Also -- last time I tried adding some tests, I found it to be very hard to figure out where and how to put them in. Granted, I only poked at it for an hour or two -- but if users could add tests in less than an hour, we'd get a lot more tests. Maybe it just need more documentation, or maybe I just didn't know nose at the time -- I don't remember, but I do know I was discouraged, and haven't tried since. Maybe a test change log of some sort would be helpful: easy access to know what tests had to be changed/added to accommodate change behavior (i.e any test that is passing with version i that would not have passed version i-1) - looking over that might be a good way to figure out if your own code is likely to be affected. -Chris > >> >> >> I think that this is a cultural issue: priority is not given to stability >> and backward compatibility. I think that this culture is very much >> ingrained in the Python world, that likes iteratively cleaning its >> software design. For instance, I have the feeling that in the >> scikit-learn, we probably fall in the same trap. That said, such a >> behavior cannot fare well for a base scientific environment. People tell >> me that if they take old matlab code, the odds that it will still works >> is much higher than with Python code. As a geek, I tend to reply that we >> get a lot out of this mobility, because we accumulate less cruft. >> However, in research settings, for reproducibility reasons, ones need to >> be able to pick up an old codebase and trust its results without knowing >> its intricacies. > > > Bitch, bitch, bitch. Look, I know you are pissed and venting a bit, but this > problem could have been detected and reported 6 months ago, that is, unless > it is new due to development on your end. > >> >> >> >From a practical standpoint, I believe that people implementing large >> changes to the numpy codebase, or any other core scipy package, should >> think really hard about their impact. I do realise that the changes are >> discussed on the mailing lists, but there is a lot of activity to follow >> and I don't believe that it is possible for many of us to monitor the >> discussions. Also, putting more emphasis on backward compatibility is >> possible. For instance, the 'order' parameter added to np.copy could have >> defaulted to the old behavior, 'K', for a year, with a >> DeprecationWarning, same thing for the casting rules. >> >> Thank you for reading this long email. I don't mean it to be a complaint >> about the past, but more a suggestion on something to keep in mind when >> making changes to core projects. >> > > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- 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.bar...@noaa.gov _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion