On Sat, Feb 26, 2011 at 12:22 PM, Eric Firing <efir...@hawaii.edu> wrote:
> On 02/26/2011 04:51 AM, Darren Dale wrote: > > On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen<p...@iki.fi> 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 ;) > >> > >> 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()<http://matplotlib.github.com/api/axes_api.html#matplotlib.axes.Axes.plot>, > scalex and scaley are local arguments and the rest are passed on as > Line2D()<http://matplotlib.github.com/api/artist_api.html#matplotlib.lines.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
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
