On 11/15/2011 06:23 AM, Volker Blum wrote: > Hi Ben, > > thanks for the answer, ... umm, but did the person making the change > realize that such error messages are exposed to users who do not have > any idea what python is. > > I would plead(*) with anyone that functionality that is not harmful > please not be deprecated like this. Scripts based on matplotlib, as > software, will have a much longer life than that 1 year it took to > deprecate this harmless function. > > best wishes Volker > > (*) I know it's free software, and I have neither right nor desire to > demand anything like this. Hence the "plead". > > ... problem is, all we can do is evaluate whether matplotlib is safe > to base our own work on here for the long term. The simple fallout > from such a deprecation can be fixed in our own internal repository, > sure ... but this quite central script will remain broken from the > point of view of our users for a long time.
Volker, The simple answer to your question about safety is "no, if safety in the long term requires that the code you write now must work with any future version of mpl". This is true throughout the software ecosystem of interdependent libraries--even in non-free software. It is particularly applicable to organically evolving libraries like mpl. We want the evolution of mpl to be as comfortable for users as possible, balanced with the need to improve. This includes the need to remove functionality that is marginal, obsolete, or inappropriate. All code has a maintenance cost. In addition, marginal or redundant functionality has a cost to users: increased learning time and likely confusion for anyone working with the library. Eric > > On Nov 15, 2011, at 4:50 PM, Benjamin Root wrote: > >> Others are probably more suited for explaining the hows and whys of >> mlab.py, but I will give it a crack. mlab.py was originally made >> to help assist users transitioning from Matlab over to matplotlib. >> Some functions that were probably considered to be top-tier in >> Matlab had to be accessed in sub-modules in NumPy, or were only >> available in the scipy packages. mlab.py attempted to address >> that. >> >> There is also the issue where we were attempting to bridge >> compatibility with the old Numerix package which did not have many >> of these things at all. Support for Numerix has long been >> deprecated and so the need for many of the functions in mlab.py has >> gone away. This is why we now refer to the equivalent numpy >> function in the deprecation messages. >> >> In v1.1.0, the norm() function is completely removed and you will >> not even get a deprecation message at all. The easiest solution is >> to adapt your scripts to use the numpy equivalents as suggested in >> the messages. >> >> Cheers! Ben Root > > > > > > > ------------------------------------------------------------------------------ > > RSA(R) Conference 2012 > Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ Matplotlib-users > mailing list Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
