[clip]
Yes. The minimum version for this Python 3.x compatibility work is
Python 2.6. Anything earlier is just insane 
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
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
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’t 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: