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<[email protected]> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
