Yes, I think we would do that. We went to a lot of trouble to release 0.6.7 with Python 2.4 support before we dropped it, and it worked out, so I think it's a good plan for future Python version support drops (which shouldn't be nearly as hard, until we drop Python 2 support).
Aaron Meurer On Thu, May 24, 2012 at 6:26 PM, Kjetil brinchmann Halvorsen <kjetil1...@gmail.com> wrote: > People should be warned in good time, to have time to switch. ¿What > about announcing that next released version will have 2.5 support, but > after that it will be dropped? > > Kjetil > > On Thu, May 24, 2012 at 8:06 PM, Joachim Durchholz <j...@durchholz.org> wrote: >> Executive summary: >> >> From my perspective, I think that >> - the language and stdlib changes of 2.6 would be Nice To Have (TM) >> - the security issues are relevant enough to warrant dropping 2.5 >> - the case for keeping 2.5 is user base. >> Do we have data that allows us to judge its relevance? >> >> Am 25.05.2012 00:13, schrieb Vladimir Perić: >> >>> On Thu, May 24, 2012 at 10:35 PM, Joachim Durchholz<j...@durchholz.org> >>> wrote: >>>> >>>> Am 24.05.2012 21:26, schrieb Aaron Meurer: >>>> >>>>> Note that the main reason to keep Python 2.5 support would be for >>>>> people who don't have enough control over their system to install or >>>>> compile Python 2.6 or 2.7. >>>> >>>> >>>> >>>> Now I'm curious: What difference between 2.4 and 2.5 is making 2.4 >>>> support-unworthy and 2.5 support-worthy? >>> >>> >>> Quite a bit, see the relevant issue[1] and the mailing list thread it >>> references[2] for a list of reasons to switch. It was also quite >>> helpful with Python 3 support (I remember there were issues, but I >>> can't think of any in particular right now). >>> >>> In comparison, is there such a number of new feature we could use from >>> 2.6? The with statement is available in 2.5, as Aaron noted; I'm not >>> sure about the wrapper support you mention, though. >> >> >> I meant functools. They have several new functions that make it easier to >> work with parameter lists. >> >> >>> What 2.6 does >>> >>> provide, though, is a ton of methods which emulate py3k functionality, >>> so it would be easier to support Python 2 and 3 with a unified >>> code-base (as opposed to running 2to3). On the other hand, I'm not >>> sure a) how feasible this actually is, >> >> >> 100%. It's just another option to be 3-compatible. >> Might help in those cases where 2to3 gives us grief (this tends to crop up >> in the mailing list occasionally). >> >> >>> and b) if we actually want >>> >>> this? As we already have a Python 3 solution with the use of 2to3, >>> pouring effort in the other direction could be considered kind of a >>> waste. >> >> >> My understanding is that the compatibility stuff in 2.6 is supposed to look >> just like Python 3. If that's correct, any effort poured into using these >> functions is effort spared when migrating to Python 3. >> >> BTW keeping support for 2.5 is some wasted effort as well. >> More testing effort for those who wish to test all configurations that SymPy >> is supposed to run in. >> Wasted coding effort time for those who find that their 2.7-compatible code >> doesn't work in 2.5 because some standard library function got added only in >> 2.6 (this happened to me once). >> >> What makes me really want to drop 2.5 is that there are no security fixes >> for it anymore. >> Here's the status of the various relevant Python versions: >> 2.5 - no security fixes anymore >> 2.6 - last security fixes will be in October 2013 >> 2.7 - current production release, no end date set >> 3.1 - last security fixes will be in June 2014 >> 3.2 - current production release, no end date set >> Security is not an issue if SymPy gets to see only input from trusted >> sources. >> However, this is easier said than asserted. Anybody running SymPy over the >> web might expose security problems of Python 2.5 to an arbitrary attacker. >> So to the very least our instructions for setting up a SymPy console on the >> WWW should carry a warning that 2.5 is a no-no for that usage. (If we don't >> add that warning, we'll risk a mention of SymPy in a CVE report. That's not >> the kind of publicity we want.) >> >> I also see little reason to keep 2.5. >> I see Python installed on Unix-style system as a system scripting language. >> The makers of these systems can't have security problems in that, so I'm >> assuming most if not all of them threw 2.5 out when the Pythonistas stopped >> doing security fixes for 2.5. (The Android market could be an exception. >> Android phones tend to have a shoddy-to-nonexistent security update policy.) >> Windows users are not an issue. If they could install 2.5, they can install >> 2.6. >> So... do we have any solid numbers about the size of our 2.5 user base? Just >> guessing usage counts isn't going to help us decide on this. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to sympy@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. >> > > > > -- > "If you want a picture of the future - imagine a boot stamping on the > human face - forever." > > George Orwell (1984) > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@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. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@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.
