Python 2.4 Support

2 views
Skip to first unread message

Christian Muise

unread,
Aug 16, 2010, 5:11:13 PM8/16/10
to sy...@googlegroups.com
Hello,
  I was curious what the roadmap is (if any) for dropping Python 2.4 support? Some features would break compatibility with 2.4, and as such they need to be delayed until support is dropped.

  Thanks. Cheers.

   Christian

Brian Granger

unread,
Aug 16, 2010, 6:37:37 PM8/16/10
to sy...@googlegroups.com
I am fine with dropping 2.4 support and even 2.5 support. This makes
moving to Python 3 much easier. For what it is worth, IPython is
dropping 2.4/2.5 support in its next release.

Cheers,

Brian

> --
> 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+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgra...@calpoly.edu
elli...@gmail.com

Aaron S. Meurer

unread,
Aug 16, 2010, 6:45:36 PM8/16/10
to sy...@googlegroups.com
I already expounded my position a while back at http://groups.google.com/group/sympy/browse_thread/thread/b0103e9ce1301440/ed74f8f8106ac490. So I will let you just read that if you are interested.

In a nutshell, I am tired of 2.4 and want to drop support already.

On Aug 16, 2010, at 4:37 PM, Brian Granger wrote:

> I am fine with dropping 2.4 support and even 2.5 support. This makes
> moving to Python 3 much easier. For what it is worth, IPython is
> dropping 2.4/2.5 support in its next release.

Wow. I can see why you would want to drop 2.4, because 2.5 added a lot of language features, but why do you want to drop 2.5 as well? As far as I can tell, 2.6 didn't really add that much to the language other than the −3 flag (though 2.7 did; that is a different story).

Aaron Meurer

Mateusz Paprocki

unread,
Aug 16, 2010, 6:49:14 PM8/16/10
to sy...@googlegroups.com
Hi,

On Mon, Aug 16, 2010 at 03:37:37PM -0700, Brian Granger wrote:
> I am fine with dropping 2.4 support and even 2.5 support. This makes
> moving to Python 3 much easier. For what it is worth, IPython is
> dropping 2.4/2.5 support in its next release.
>

Dropping 2.4 support at this point may make sense, but dropping 2.5
would be too much, because in this case we wouldn't be able to run
SymPy e.g. in Google App Engine.

--
Mateusz

signature.asc

Brian Granger

unread,
Aug 16, 2010, 8:34:48 PM8/16/10
to sy...@googlegroups.com
On Mon, Aug 16, 2010 at 3:45 PM, Aaron S. Meurer <asme...@gmail.com> wrote:
> I already expounded my position a while back at http://groups.google.com/group/sympy/browse_thread/thread/b0103e9ce1301440/ed74f8f8106ac490. So I will let you just read that if you are interested.
>
> In a nutshell, I am tired of 2.4 and want to drop support already.
>
> On Aug 16, 2010, at 4:37 PM, Brian Granger wrote:
>
>> I am fine with dropping 2.4 support and even 2.5 support.  This makes
>> moving to Python 3 much easier.  For what it is worth, IPython is
>> dropping 2.4/2.5 support in its next release.
>
> Wow.  I can see why you would want to drop 2.4, because 2.5 added a lot of language features, but why do you want to drop 2.5 as well?  As far as I can tell, 2.6 didn't really add that much to the language other than the -3 flag (though 2.7 did; that is a different story).

Here is our reasoning:

* The faster we drop everything but Python 2.7 (don't worry, we will
support 2.6 for a while), the easier it will be to move to Python 3.
IPython is a pretty complex code base that probes some of the more
difficult issues that arise in the move to Python 3 (like
unicode/str/bytes). We don't see a way to move to Python 3 and
maintain Python 2.5 without forking and we are not going to do that.
* Python 2.5 was released 4 years ago, which is a pretty long time.
We don't feel to bad about this.
* We will continue to maintain IPython 0.10 for a while, which does
have 2.5 support.
* There are things in the std library in 2.6 that we are already using
(abcs, better Popen, etc.).
* By adding lots of cool new features to IPython and requiring 2.6, it
is a way of pushing other
projects to move to Python 3 more quickly ;-)

Cheers,

Brian

smichr

unread,
Aug 17, 2010, 12:55:25 AM8/17/10
to sympy
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

Ondrej Certik

unread,
Aug 17, 2010, 1:43:32 AM8/17/10
to sy...@googlegroups.com
On Mon, Aug 16, 2010 at 2:11 PM, Christian Muise
<christi...@gmail.com> wrote:
> Hello,
>   I was curious what the roadmap is (if any) for dropping Python 2.4
> support? Some features would break compatibility with 2.4, and as such they
> need to be delayed until support is dropped.

I am ok with dropping 2.4 too. I would keep 2.5 for now.


Ondrej

Øyvind Jensen

unread,
Aug 17, 2010, 5:52:51 AM8/17/10
to sy...@googlegroups.com
I'd drop 2.4 any day. The biggest pain for me during the summer was the
doctest: +SKIP flag which requires 2.5. In the autowrap module I need
to +SKIP several doctests in case compilers and backends are not
installed.

Øyvind

Vinzent Steinberg

unread,
Aug 17, 2010, 9:39:05 AM8/17/10
to sympy
On 17 Aug., 07:43, Ondrej Certik <ond...@certik.cz> wrote:
> I am ok with dropping 2.4 too. I would keep 2.5 for now.

Is there actually anyone who wants to keep 2.4 compability?

I'm also +1 for dropping it. (Yay, conditional statements!)

Vinzent

Andy Ray Terrel

unread,
Aug 17, 2010, 10:17:41 AM8/17/10
to sy...@googlegroups.com
Just to reiterate the point.

+10

-- Andy

william ratcliff

unread,
Aug 17, 2010, 1:16:43 PM8/17/10
to sy...@googlegroups.com
Does anyone know what the time scale is for numpy/scipy transitioning to Python 3?  Also, one thing that bit us recently was that the recommended exception syntax in 2.6 is not compatible with 2.5--otherwise, it has functioned fairly well.

William

Aaron S. Meurer

unread,
Aug 18, 2010, 3:58:17 AM8/18/10
to sy...@googlegroups.com
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.

(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

Mateusz Paprocki

unread,
Aug 18, 2010, 8:08:11 AM8/18/10
to sy...@googlegroups.com
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+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>

--
Mateusz

signature.asc

Vinzent Steinberg

unread,
Aug 18, 2010, 8:35:01 AM8/18/10
to sympy
On 18 Aug., 09:58, "Aaron S. Meurer" <asmeu...@gmail.com> wrote:
> (p.s. we need to updatehttp://wiki.sympy.org/wiki/Plan_for_SymPy_1.0#sympy_0.7.0to make this more clear).

Please feel free to update it to your liking. Probably we won't get
cython for 0.7.

Vinzent
Reply all
Reply to author
Forward
0 new messages