Hi, On Wed, Aug 18, 2010 at 01:58:17AM -0600, Aaron S. Meurer wrote: > I am inclined to agree with this. Depending on where we are by the time we > are ready to release 0.7.0, we could make it the last version that supports > Python 2.4. Now, if supporting it becomes a real pain before the release, > say because of with statement context managers, then we should just drop it > and too bad: that's the future. > > But if we were to release in a state similar to where we are right now, I > think we should just keep the support and add a warning to sympy/__init__.py > when used with Python 2.4 saying that it is deprecated and won't be supported > in future versions. Then, immediately after the release, we can remove all > the any(), all(), iff(), etc. nonsense from the code and start moving forward. > > Then again, the way things are looking now, it could be quite a while before > we release 0.7.0. I am assuming we are waiting until we have completely > replaced the old assumptions system at least, and we probably also want to > get Mateusz's latest polys branch in, and my Risch integration in if I have > that ready to go by then, and also all the other outstanding branches/patches > for review. Considering how fast these things tend to happen, it could be > another six months to a year before we actually release, after which Python > 2.4 will only become older and more deprecated than it already is. >
Waiting half a year or more for next release is too much. I think we should have "SymPy patches review and merge day(s)" and release what we have already in some reasonable time horizon (one or two months). > (p.s. we need to update > http://wiki.sympy.org/wiki/Plan_for_SymPy_1.0#sympy_0.7.0 to make this more > clear). > > Aaron Meurer > > On Aug 16, 2010, at 10:55 PM, smichr wrote: > > > I guess I wouldn't mind seeing all the goodness of GSoC and polys11 > > being added before dropping support for 2.4. That way, anyone still > > using it will have a pretty complete sympy. And then after introducing > > that version 0.x immediately introduce a new version 0.x+1 that is 2.4 > > incompatible. On the other hand, those new routines may introduce > > their own set of bugs that we wouldn't want to support, perhaps. At > > least the way it is now is that we only support 1 version, right? So > > which is better...a potentially more powerful sympy with bugs whose > > squashing is no longer supported by sympy (but could be handled by > > others) or a less powerful less buggy version (that is also not > > supported)? > > > > /c > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sy...@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- Mateusz
signature.asc
Description: This is a digitally signed message part
