In article <cap7+vjlzb5xl8cxbmibunnig9y4+49f17vmfb9lznf0asnx...@mail.gmail.com>, Guido van Rossum <gu...@python.org> wrote: [...] > But perhaps we could change the focus for 2.7 development a bit: > instead of fixing bugs (or bickering about whether something is a bug > fix or a new feature) we could limit changes to ensuring that it works > on newer platforms. Martin mentioned that building 2.7 for Windows > with the same toolchain that was used for the 2.7.0 release is getting > more and more problematic. I'm not sure, but I could imagine similar > problems for future versions of OS X and even Linux (though the Linux > distributions typically take care of issues themselves).
That's an excellent point. In the OS X world, my sense is that OS and build tool updates are adopted more quickly by users than in less homogenous platform environments so we've tried to be be pragmatic about supporting new releases of Xcode built tools in Python maintenance branches like 2.7. For example, in 2.7.4 there were some significant changes to building Python and to Distutils to support extension module building with the latest Xcode releases. (That's not to say we are always as timely as we should be.) I don't think there has been any major disagreements that doing those kinds of limited changes for platform support are in scope. There have also been some changes to better support cross-building for platforms that have become more strategically important, like ARM. These have been more controversial but a good case can be made for considering such changes as pragmatic long-term investments. It might be a good idea to have a more formal policy in place going forward for 2.7.x. Beyond build tools is the issue of the components that Python depends on at runtime, primarily third-party libraries. Many of these are also under active development, with schedules and compatibility criteria that differ from those we use. In some cases, security issues will force the rapid adoption of new versions, in other cases, widespread adoption on the platforms we support will force this. Again, pragmatically, we'll need to continue to track these components and support newer versions as necessary in order for maintained versions of Python to remain viable. (And we need to step up the activity in some areas. Tcl/Tk 8.6 is now official and starting to be adopted. Tkinter and IDLE are intimately dependent on Tk and, AFAIK, we don't really have anyone closely following the changes there and their implications for Python. Thankfully, Serhiy has been doing some work with 8.6 already.) -- Ned Deily, n...@acm.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
