What's the status of the py3k branch?

[clip]

Yes. The minimum version for this Python 3.x compatibility work is
Python 2.6. Anything earlier is just insane :wink:

Out of curiosity: did you consider using a single source tree for Python
2.x and 3.x, rather than a separate branch; providing Python 3 support by
running 2to3 on build stage and #ifdef's + compatibility headers in C
code?

This approach allowed Numpy to support Pythons down to 2.4 with little
extra work, and requires manual Python 3 specific fixes only when
something breaks (which does not seem to occur often in practice).

路路路

On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:

--
Pauli Virtanen

At some point, it will make sense to discontinue support for
<=python-2.5 (maybe even 2.6). I have used numpy's 2to3 for my
quantities project (admittedly a *much* smaller project with *much*
smaller exposure), but recently dropped backwards compatibility and
now 2.6-3.2 are supported in a single branch without use of 2to3. I
prefer this approach, it seems to be working out without too much
trouble so far.

Darren

路路路

On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen <pav@...278...> wrote:

On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
[clip]

Yes. The minimum version for this Python 3.x compatibility work is
Python 2.6. Anything earlier is just insane :wink:

Out of curiosity: did you consider using a single source tree for Python
2.x and 3.x, rather than a separate branch; providing Python 3 support by
running 2to3 on build stage and #ifdef's + compatibility headers in C
code?

This approach allowed Numpy to support Pythons down to 2.4 with little
extra work, and requires manual Python 3 specific fixes only when
something breaks (which does not seem to occur often in practice).

My personal rule-of-thumb for what to support for scientific packages is whichever version of python is in the latest RHEL. Python 2.6 is in RHEL6, so I feel that is a reasonable minimum. Supporting python 2.4 (from RHEL5) is probably too onerous at this point.

Ben Root

路路路

On Sat, Feb 26, 2011 at 8:51 AM, Darren Dale <dsdale24@鈥55鈥149鈥> wrote:

On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen <pav@鈥278鈥> wrote:

On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:

[clip]

Yes. The minimum version for this Python 3.x compatibility work is

Python 2.6. Anything earlier is just insane :wink:

Out of curiosity: did you consider using a single source tree for Python

2.x and 3.x, rather than a separate branch; providing Python 3 support by

running 2to3 on build stage and #ifdef鈥檚 + compatibility headers in C

code?

This approach allowed Numpy to support Pythons down to 2.4 with little

extra work, and requires manual Python 3 specific fixes only when

something breaks (which does not seem to occur often in practice).

At some point, it will make sense to discontinue support for

<=python-2.5 (maybe even 2.6). I have used numpy鈥檚 2to3 for my

quantities project (admittedly a much smaller project with much

smaller exposure), but recently dropped backwards compatibility and

now 2.6-3.2 are supported in a single branch without use of 2to3. I

prefer this approach, it seems to be working out without too much

trouble so far.

Darren

Supporting earlier versions is nice--I work with many machines running 2.5, and keep mpl up to date on several of them, but thankfully I have nothing still stuck on 2.4--but for mpl, now that we have a pretty good 1.x version, I don't think it would be too hard on users if we made a last release supporting earlier pythons and then dropped support for them in subsequent releases. It would not mean people with earlier pythons couldn't run mpl, it would just mean they would get no new improvements, and no new bug fixes unless someone stepped forward to maintain the old branch.

Dropping 2.6 any time soon would be too drastic for my liking, though. It would require that any development work done on recent ubuntu systems, for example, would require first installing a non-default version of python. So, I hope the py3k work can result in a 2.6-and-up codebase--is that the present goal? Those of us developing on 2.6 will need to learn exactly how to avoid breaking 3.1 compatibility.

Eric

路路路

On 02/26/2011 04:51 AM, Darren Dale wrote:

On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen<pav@...278...> wrote:

On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
[clip]

Yes. The minimum version for this Python 3.x compatibility work is
Python 2.6. Anything earlier is just insane :wink:

Out of curiosity: did you consider using a single source tree for Python
2.x and 3.x, rather than a separate branch; providing Python 3 support by
running 2to3 on build stage and #ifdef's + compatibility headers in C
code?

This approach allowed Numpy to support Pythons down to 2.4 with little
extra work, and requires manual Python 3 specific fixes only when
something breaks (which does not seem to occur often in practice).

At some point, it will make sense to discontinue support for
<=python-2.5 (maybe even 2.6). I have used numpy's 2to3 for my
quantities project (admittedly a *much* smaller project with *much*
smaller exposure), but recently dropped backwards compatibility and
now 2.6-3.2 are supported in a single branch without use of 2to3. I
prefer this approach, it seems to be working out without too much
trouble so far.

Darren

Hi,

[clip]

Yes. The minimum version for this Python 3.x compatibility work is
Python 2.6. Anything earlier is just insane :wink:

Out of curiosity: did you consider using a single source tree for Python
2.x and 3.x, rather than a separate branch; providing Python 3 support by
running 2to3 on build stage and #ifdef's + compatibility headers in C
code?

This approach allowed Numpy to support Pythons down to 2.4 with little
extra work, and requires manual Python 3 specific fixes only when
something breaks (which does not seem to occur often in practice).

I haven't done any Py3k porting.

I saw you (Pauli) doing the numpy and scipy ports using the same
codebase / 2to3 strategy, and that you were pleased with the results
(and it worked...).

IIRC the nose testing framework had a py3k branch that got very stale,
and they finally got there by dumping the py3k branch and using 2to3
on the same source tree.

See you,

Matthew

路路路

On Sat, Feb 26, 2011 at 6:23 AM, Pauli Virtanen <pav@...278...> wrote:

On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:

Yes, it is.

路路路

On Sat, Feb 26, 2011 at 1:22 PM, Eric Firing <efiring@...229...> wrote:

Dropping 2.6 any time soon would be too drastic for my liking, though.
It would require that any development work done on recent ubuntu
systems, for example, would require first installing a non-default
version of python. So, I hope the py3k work can result in a 2.6-and-up
codebase--is that the present goal?

[clip]

Yes. The minimum version for this Python 3.x compatibility work is

Python 2.6. Anything earlier is just insane :wink:

Out of curiosity: did you consider using a single source tree for Python

2.x and 3.x, rather than a separate branch; providing Python 3 support by

running 2to3 on build stage and #ifdef鈥檚 + compatibility headers in C

code?

This approach allowed Numpy to support Pythons down to 2.4 with little

extra work, and requires manual Python 3 specific fixes only when

something breaks (which does not seem to occur often in practice).

At some point, it will make sense to discontinue support for

<=python-2.5 (maybe even 2.6). I have used numpy鈥檚 2to3 for my

quantities project (admittedly a much smaller project with much

smaller exposure), but recently dropped backwards compatibility and

now 2.6-3.2 are supported in a single branch without use of 2to3. I

prefer this approach, it seems to be working out without too much

trouble so far.

Darren

Supporting earlier versions is nice鈥揑 work with many machines running

2.5, and keep mpl up to date on several of them, but thankfully I have

nothing still stuck on 2.4鈥揵ut for mpl, now that we have a pretty good

1.x version, I don鈥檛 think it would be too hard on users if we made a

last release supporting earlier pythons and then dropped support for

them in subsequent releases. It would not mean people with earlier

pythons couldn鈥檛 run mpl, it would just mean they would get no new

improvements, and no new bug fixes unless someone stepped forward to

maintain the old branch.

Dropping 2.6 any time soon would be too drastic for my liking, though.

It would require that any development work done on recent ubuntu

systems, for example, would require first installing a non-default

version of python. So, I hope the py3k work can result in a 2.6-and-up

codebase鈥搃s that the present goal? Those of us developing on 2.6 will

need to learn exactly how to avoid breaking 3.1 compatibility.

Eric

I was just looking through some code and I realized that if we are now willing (able?) to drop support for 2.4-2.5, then maybe we could benefit from some updates to our coding practices? For example, I would personally love to see more use of conditional expressions (new in 2.5).

In addition, I wonder if we could possibly consider updating our policy regarding function parameter handling? In particular, I am referring to this section of our coding guide:

In some cases, you may want to consume some keys in the local
function, and let others pass through. You can pop the ones to be
used locally and pass on the rest. For example, in
plot(), scalex and scaley are
local arguments and the rest are passed on as
Line2D() keyword arguments:

# in axes.py
def plot(self, *args, **kwargs):


    scalex = kwargs.pop('scalex', True)


    scaley = kwargs.pop('scaley', True)


    if not self._hold: self.cla()


    lines = []
    for line in self._get_lines(*args, **kwargs):


        self.add_line(line)
        lines.append(line)

Note: there is a use case when kwargs are meant to be used locally
in the function (not passed on), but you still need the **kwargs
idiom. That is when you want to use *args to allow variable
numbers of non-keyword args. In this case, python will not allow you
to use named keyword args after the *args usage, so you will be
forced to use **kwargs. An example is
matplotlib.contour.ContourLabeler.clabel():

in contour.py

def clabel(self, *args, **kwargs):

fontsize = kwargs.get('fontsize', None)


inline = kwargs.get('inline', 1)


self.fmt = kwargs.get('fmt', '%1.3f')


colors = kwargs.get('colors', None)


if len(args) == 0:
    levels = self.levels


    indices = range(len(self.levels))


elif len(args) == 1:
   ...etc...

I know that this restriction is no longer the case in later versions of python, but I can鈥檛 seem to find out which version this restriction was changed.

Are there other practices that we can now allow?

Ben Root

路路路

On Sat, Feb 26, 2011 at 12:22 PM, Eric Firing <efiring@鈥229鈥> wrote:

On 02/26/2011 04:51 AM, Darren Dale wrote:

On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen<pav@鈥278鈥> wrote:

On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:

We are only talking about the python 3 branch here. The master branch
should remain 2.4 compliant until we merge the 3.x into master.
Before we do that, we'll probably want to do a 1.1 or 1.2 or
1.whatever release and maintenance branch so we have a python 2.4
which is as current as possible.

JDH

路路路

On Sun, Feb 27, 2011 at 1:13 PM, Benjamin Root <ben.root@...553...> wrote:

I was just looking through some code and I realized that if we are now
willing (able?) to drop support for 2.4-2.5, then maybe we could benefit
from some updates to our coding practices? For example, I would personally
love to see more use of conditional expressions (new in 2.5).

Ah, that wasn鈥檛 entirely clear. Good to know before I started messing things up.

Ben Root

路路路

On Sun, Feb 27, 2011 at 1:21 PM, John Hunter <jdh2358@鈥552鈥149鈥> wrote:

On Sun, Feb 27, 2011 at 1:13 PM, Benjamin Root <ben.root@鈥553鈥> wrote:

I was just looking through some code and I realized that if we are now

willing (able?) to drop support for 2.4-2.5, then maybe we could benefit

from some updates to our coding practices? For example, I would personally

love to see more use of conditional expressions (new in 2.5).

We are only talking about the python 3 branch here. The master branch

should remain 2.4 compliant until we merge the 3.x into master.

Before we do that, we鈥檒l probably want to do a 1.1 or 1.2 or

1.whatever release and maintenance branch so we have a python 2.4

which is as current as possible.

JDH