Compiler for the Mac OS X version of Python 3.4
I was exercising the alpha two release of 3.4 and noticed that it is still being built under GCC 4.2.1. Is there any reason we have to use an old compiler? I would like to see it built under the latest version of Clang (like the other tools on the Mac) or under GCC 4.8.1. I've better using the latter for many months. It works great and produces *much* better code (in terms of readability for those of us who look at assembly output and in terms of speed (approx 20-25% better for cpu bound code)). I'm wondering whether is some issue that forces us to use GCC 4.2.1 or whether that is just an artifact of continuing to do what we've always been doing. Raymond
In article <70C99F87-E9A5-4838-A1E9-4739FBF2E6A5@gmail.com>, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
I was exercising the alpha two release of 3.4 and noticed that it is still being built under GCC 4.2.1.
Is there any reason we have to use an old compiler?
Yes, kinda. It's because the 64-bit/32-bit installer we supply is designed to run on multiple versions of OS X: 10.6 (Snow Leopard), 10.7, 10.8, and the upcoming 10.9. The safest way to ensure that the bits produced (executables, shared libs, and .so bundles) are linked with compatible versions of system shared libraries and frameworks is to build on the lowest supported system, 10.6, or - carefully - with a 10.6 SDK on a newer system. The standard compiler in the Apple Developer Tools for 10.6 is gcc 4.2. Clang was very immature at that point. The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the past.
I would like to see it built under the latest version of Clang (like the other tools on the Mac) or under GCC 4.8.1. I've better using the latter for many months. It works great and produces *much* better code (in terms of readability for those of us who look at assembly output and in terms of speed (approx 20-25% better for cpu bound code)).
I'm wondering whether is some issue that forces us to use GCC 4.2.1 or whether that is just an artifact of continuing to do what we've always been doing.
I'd like to move to Apple's latest clang, as well. (Apple is dropping gcc totally from the next release of Xcode.) There are a couple of approaches that may work and still reliably support multiple versions of OS X. Investigating this is on my list of things to do prior to the next alpha. I've opened a bug tracker issue for this (Issue19019). -- Ned Deily, nad@acm.org
On Sep 14, 2013, at 1:32 PM, Ned Deily <nad@acm.org> wrote:
The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the past.
I think we should offer a separate Mac build just for 10.6 (much like we do for the 32-bit PPC option for 10.5). Otherwise, were trapped in an old world and using the same reasoning as companies that still mandate Internet Explorer 6; forgoing the benefits of newer browsers just to make sure a few pieces of legacy code can be supported.
I'd like to move to Apple's latest clang, as well. (Apple is dropping gcc totally from the next release of Xcode.)
That is an excellent reason for us to move as well. Otherwise, we risk getting out of sync with the rest of the ecosystem.
I've opened a bug tracker issue for this (Issue19019).
Thank you. One thing that can be done is to take advantage of the 3.4 alphas and betas to experiment with having both a legacy version and fresh build with better tools. That would let us find out early whether the worries and fears are real and will manifest themselves in practice. I've been building under GCC 4.8.1 for months and have encountered no problems at all with the popular third-party modules or with linking to existing SO files. Raymond
+1. A 10.6-only build makes sense. If you aren't having problems with GCC 4.8, then Clang shouldn't give any trouble. Honestly, I still think Clang should be a compiler option in Windows distutils... Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the
On Sep 14, 2013, at 1:32 PM, Ned Deily <nad@acm.org> wrote: past.
I think we should offer a separate Mac build just for 10.6 (much like we do for the 32-bit PPC option for 10.5).
Otherwise, were trapped in an old world and using the same reasoning as companies that still mandate Internet Explorer 6; forgoing the benefits of newer browsers just to make sure a few pieces of legacy code can be supported.
I'd like to move to Apple's latest clang, as well. (Apple is
dropping
gcc totally from the next release of Xcode.)
That is an excellent reason for us to move as well. Otherwise, we risk getting out of sync with the rest of the ecosystem.
I've opened a bug tracker issue for this (Issue19019).
Thank you.
One thing that can be done is to take advantage of the 3.4 alphas and betas to experiment with having both a legacy version and fresh build with better tools. That would let us find out early whether the worries and fears are real and will manifest themselves in practice.
I've been building under GCC 4.8.1 for months and have encountered no problems at all with the popular third-party modules or with linking to existing SO files.
Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Am 15.09.13 00:56, schrieb Ryan:
+1. A 10.6-only build makes sense.
I'd like to support Russell's point: this could put a burden on everyone releasing extension modules to also provide two binary releases, which e.g. would then mess up downloads from PyPI. So -1. +0 on dropping 10.6 support from the binary installers as proposed by Greg. Regards, Martin
On Sep 18, 2013, at 03:03 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote: Am 15.09.13 00:56, schrieb Ryan: +1. A 10.6-only build makes sense. I'd like to support Russell's point: this could put a burden on everyone releasing extension modules to also provide two binary releases, which e.g. would then mess up downloads from PyPI. So -1. +0 on dropping 10.6 support from the binary installers as proposed by Greg. Dropping support for 10.6 isn't really necessary, just build (carefully) on a later release of OSX (preferably the last one to pick up the most recent developer tools). I'll try to provide a more detailed response tonight, but the basic idea is to use OSX 10.8, the current Xcode release and the OSX 10.8 SDK to do the build. This is a supported configuration for building binaries that target older OSX releases, but some care is needed with the configure script for 3th-party libraries: those might pick up features that aren't available in 10.6. Ronald Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
As a MacBook Pro user running Snow Leopard/10.6.8, I would find the lack of a binary release problematic, were it not for the fact that I routinely build from source (and don't do anything Mac-specific with Python). For those not familiar with the platform, it's perhaps worth noting that upgrade is out of my hands. Apple dropped support for my "ancient" MBP (2006?), so 10.6.8 is as up-to-date as I can get. I guess that's what you expect from a company whose main revenues these days come from cell phones and tablets, and addition of pastels to their color pallet warrants announcement in a TV commercial. I suspect other Mac users stuck on Snow Leopard who are not Python developers would rue the lack of binary installers more than me. Skip
Skip Montanaro writes:
I suspect other Mac users stuck on Snow Leopard who are not Python developers would rue the lack of binary installers more than me.
Perhaps, but if Python current as of now isn't good enough for someone for the foreseeable future, aren't they going to want up-to-date libraries to backup the Python modules that use them, not to mention security fixes and the like? That's why I get my Python (for Snow Leopard) from MacPorts. I wouldn't hesitate to build it myself, but I get timely upgrades from MacPorts so there's no need to bother. I'd be far less likely to upgrade quickly (for bugfix releases) if I had to make a special trip to python.org for installers. The MacPorts build could break at any time, I suppose, but at least for the moment there are alternatives to building it yourself.
That's why I get my Python (for Snow Leopard) from MacPorts.
Unless things have changed, that probably doesn't support Mac-specific stuff, does it? I was thinking more of non-developer users who are likely to need/want Mac-specific interfaces for tools which are written in Python. That might just shift the burden to the developers of such tools. My guess is that there is a domino effect. Apple stops supporting Snow Leopard, which, all other things considered, forces third-party developers who use Python in their products to stop supporting it, which then pressures their users to buy new hardware so they can run newer versions of those developers' tools. This is good for Apple, but creates headaches and monetary costs for developers and users downstream. S
Skip Montanaro writes:
That's why I get my Python (for Snow Leopard) from MacPorts.
Unless things have changed, that probably doesn't support Mac-specific stuff, does it?
You mean in the Python port or in general? MacPorts supports Mac-specific APIs in a number of ports where upstream does. In Python, I don't know. I would assume that anything python.org supports is supported by MacPorts, though.
In article <87wqme3v3m.fsf@uwakimon.sk.tsukuba.ac.jp>, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Skip Montanaro writes:
That's why I get my Python (for Snow Leopard) from MacPorts. Unless things have changed, that probably doesn't support Mac-specific stuff, does it? You mean in the Python port or in general? MacPorts supports Mac-specific APIs in a number of ports where upstream does.
In Python, I don't know. I would assume that anything python.org supports is supported by MacPorts, though.
Yes, there are no significant differences in feature support between a python.org Python and a MacPorts-supplied Python or a Homebrew-supplied Python or a Fink-supplied Python. If you are doing any sort of a hard-core Python development work that requires the use of third-party C libraries et al, you are probably better off using a complete solution, including Python, from one of the above big-three package managers for OS X. If you need to support multiple versions of OS X, IME, MacPorts does the best job of supporting older versions (I have up-to-date MacPorts installations on OS X 10.4 through 10.9). But the primary mission for python.org installers is somewhat different: provide up-to-date, easy-to-install, batteries-included Pythons for users who are not necessarily experienced with Python itself. People who need development environments with significant third-party libraries not included with Python or OS X itself are often better served by either investing in the time to set up and become familiar with using one of the general open source distributors (MacPorts, Homebrew, et al) or by using a specialized Python distribution (e.g. for scientific users). -- Ned Deily, nad@acm.org
On Sep 18, 2013, at 10:04 AM, Skip Montanaro wrote:
As a MacBook Pro user running Snow Leopard/10.6.8, I would find the lack of a binary release problematic, were it not for the fact that I routinely build from source (and don't do anything Mac-specific with Python). For those not familiar with the platform, it's perhaps worth noting that upgrade is out of my hands. Apple dropped support for my "ancient" MBP (2006?), so 10.6.8 is as up-to-date as I can get. I guess that's what you expect from a company whose main revenues these days come from cell phones and tablets, and addition of pastels to their color pallet warrants announcement in a TV commercial.
I'm in a similar boat with my old MBP, and I am not upgrading my somewhat newer one because of compatibility with other software. But OTOH, I have never installed the binary releases, I just build them from MacPorts, so as long as that still works, I'm happy. (I have a 8mo Air running the latest Lion and will likely update that when Mavericks is out.) -Barry
On Wed, Sep 18, 2013 at 6:38 AM, Ronald Oussoren <ronaldoussoren@mac.com>wrote:
On Sep 18, 2013, at 03:03 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Am 15.09.13 00:56, schrieb Ryan:
+1. A 10.6-only build makes sense.
I'd like to support Russell's point: this could put a burden on everyone releasing extension modules to also provide two binary releases, which e.g. would then mess up downloads from PyPI. So -1.
+0 on dropping 10.6 support from the binary installers as proposed by Greg.
Dropping support for 10.6 isn't really necessary, just build (carefully) on a later release of OSX (preferably the last one to pick up the most recent developer tools).
I'll try to provide a more detailed response tonight, but the basic idea is to use OSX 10.8, the current Xcode release and the OSX 10.8 SDK to do the build. This is a supported configuration for building binaries that target older OSX releases, but some care is needed with the configure script for 3th-party libraries: those might pick up features that aren't available in 10.6.
Cool, that sounds like we should _really_ be doing. Best of both worlds and it'll give a much faster to build to everyone. Good luck! -gps
In article <B3293155-E4D5-4389-A555-C31BC49CE539@gmail.com>, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Sep 14, 2013, at 1:32 PM, Ned Deily <nad@acm.org> wrote:
The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the past.
I think we should offer a separate Mac build just for 10.6 (much like we do for the 32-bit PPC option for 10.5).
If Apple drops support for gcc in 10.9 I guess we have to go this route, but please be careful. Every time you add a new version of python for MacOS X it means that folks providing binary installers (e.g. for numpy) have to provide another binary, and folks using those installers have another chance of picking the wrong one. If you do make a 10.6-only installer, what is the minimum version of MacOS X the modern compiler would support? 10.7 gives a more measured upgrade path, but 10.8 gives a better compiler. -- Russell
Russell E. Owen <rowen@uw.edu> wrote:
In article <B3293155-E4D5-4389-A555-C31BC49CE539@gmail.com>, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
On Sep 14, 2013, at 1:32 PM, Ned Deily <nad@acm.org> wrote:
The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the past.
I think we should offer a separate Mac build just for 10.6 (much like we do for the 32-bit PPC option for 10.5).
If Apple drops support for gcc in 10.9 I guess we have to go this route,
Could go the Sage route -- Sage first checks for an up-to-date version of gcc, and downloads it and builds it for its own use if necessary. Bill
but please be careful. Every time you add a new version of python for MacOS X it means that folks providing binary installers (e.g. for numpy) have to provide another binary, and folks using those installers have another chance of picking the wrong one.
If you do make a 10.6-only installer, what is the minimum version of MacOS X the modern compiler would support? 10.7 gives a more measured upgrade path, but 10.8 gives a better compiler.
-- Russell
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/bill%40janssen.org
Meh...I hate it when tools download stuff without me noticing. Honestly, a separate 10.6 build would work well. Plus, if a new Clang versions includes some awesome feature that could make Python builds better, you'd be able to take advantage of it better. On Mon, Sep 16, 2013 at 2:56 PM, Bill Janssen <janssen@parc.com> wrote:
Russell E. Owen <rowen@uw.edu> wrote:
In article <B3293155-E4D5-4389-A555-C31BC49CE539@gmail.com>, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the
On Sep 14, 2013, at 1:32 PM, Ned Deily <nad@acm.org> wrote: past.
I think we should offer a separate Mac build just for 10.6 (much like we do for the 32-bit PPC option for 10.5).
If Apple drops support for gcc in 10.9 I guess we have to go this route,
Could go the Sage route -- Sage first checks for an up-to-date version of gcc, and downloads it and builds it for its own use if necessary.
Bill
but please be careful. Every time you add a new version of python for MacOS X it means that folks providing binary installers (e.g. for numpy) have to provide another binary, and folks using those installers have another chance of picking the wrong one.
If you do make a 10.6-only installer, what is the minimum version of MacOS X the modern compiler would support? 10.7 gives a more measured upgrade path, but 10.8 gives a better compiler.
-- Russell
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/bill%40janssen.org
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
-- Ryan
Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux. This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to maintain such a long legacy support tail there ourselves. -gps On Mon, Sep 16, 2013 at 1:28 PM, Ryan Gonzalez <rymg19@gmail.com> wrote:
Meh...I hate it when tools download stuff without me noticing.
Honestly, a separate 10.6 build would work well. Plus, if a new Clang versions includes some awesome feature that could make Python builds better, you'd be able to take advantage of it better.
On Mon, Sep 16, 2013 at 2:56 PM, Bill Janssen <janssen@parc.com> wrote:
Russell E. Owen <rowen@uw.edu> wrote:
In article <B3293155-E4D5-4389-A555-C31BC49CE539@gmail.com>, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the
On Sep 14, 2013, at 1:32 PM, Ned Deily <nad@acm.org> wrote: past.
I think we should offer a separate Mac build just for 10.6 (much like we do for the 32-bit PPC option for 10.5).
If Apple drops support for gcc in 10.9 I guess we have to go this route,
Could go the Sage route -- Sage first checks for an up-to-date version of gcc, and downloads it and builds it for its own use if necessary.
Bill
but please be careful. Every time you add a new version of python for MacOS X it means that folks providing binary installers (e.g. for numpy) have to provide another binary, and folks using those installers have another chance of picking the wrong one.
If you do make a 10.6-only installer, what is the minimum version of MacOS X the modern compiler would support? 10.7 gives a more measured upgrade path, but 10.8 gives a better compiler.
-- Russell
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/bill%40janssen.org
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
-- Ryan
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
Am 18.09.13 08:43, schrieb Gregory P. Smith:
Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux.
This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to maintain such a long legacy support tail there ourselves.
I don't mind such a decision in principle, but also in principle, I'd prefer if there was a pre-set policy to decide this question, documented in PEP 11. Here a piece of OSX release history: - 10.5: October 2007 * 10.5.8: August 2009 - 10.6: August 2009 * 10.6.8: July 2011 - 10.7: July 2011 * 10.7.5: July 2012 - 10.8: July 2012 So possible policy that would now exclude 10.6 for binary installers would be: - only the two latest feature releases are supported - only feature releases younger than 3 years are supported Note that a separate policy should be added to decide whether support for older versions is actively removed from source code (or equally bug fixes for old versions are not accepted anymore). Regards, Martin
Le Wed, 18 Sep 2013 14:54:32 +0200, "Martin v. Löwis" <martin@v.loewis.de> a écrit :
Am 18.09.13 08:43, schrieb Gregory P. Smith:
Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux.
This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to maintain such a long legacy support tail there ourselves.
I don't mind such a decision in principle, but also in principle, I'd prefer if there was a pre-set policy to decide this question, documented in PEP 11.
Here a piece of OSX release history: - 10.5: October 2007 * 10.5.8: August 2009 - 10.6: August 2009 * 10.6.8: July 2011 - 10.7: July 2011 * 10.7.5: July 2012 - 10.8: July 2012
This means that any Mac shipped pre-July 2011 has 10.6 or lower? I know Mac users are fashion victims, but 2011 doesn't sound that old to me ;-) (it's even younger than Barry!) Regards Antoine.
Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux.
This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to maintain such a long legacy support tail there ourselves. I don't mind such a decision in principle, but also in principle, I'd
On Sep 18, 2013, at 03:36 PM, Antoine Pitrou <solipsis@pitrou.net> wrote: Le Wed, 18 Sep 2013 14:54:32 +0200, "Martin v. Löwis" <martin@v.loewis.de> a écrit : Am 18.09.13 08:43, schrieb Gregory P. Smith: prefer if there was a pre-set policy to decide this question, documented in PEP 11. Here a piece of OSX release history: - 10.5: October 2007 * 10.5.8: August 2009 - 10.6: August 2009 * 10.6.8: July 2011 - 10.7: July 2011 * 10.7.5: July 2012 - 10.8: July 2012 This means that any Mac shipped pre-July 2011 has 10.6 or lower? I know Mac users are fashion victims, but 2011 doesn't sound that old to me ;-) (it's even younger than Barry!) That's correct, and IMHO it is too early to drop support for 10.6 and doubly so when it is only done to use a newer compiler for the binary build. Still-using-10.5-in-production-ly yours, Ronald Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
Thank you all for your comments so far on this subject. I have noted two separate issues raised here: one, how to build the Pythons provided by binary installers to get optimum performance (i.e. use more recent compilers); and, two, what OS X releases should we support with binary installers. As I noted earlier, I've opened Issue19019 and I will update it with concrete proposals when we've complete the necessary testing and fixing of various build configurations, including of the sort Ronald and I outlined. If you are interested in the details of this, please move that discussion to the bug tracker. As to point two, I will put a stake in the ground here and declare that we will continue to support 10.6 with 3.4 batteries-included installers. For various reasons, 10.6 remains surprisingly popular (at a recent Python hackathon meetup in San Francisco, every person I helped who had a Mac was running 10.6) and it is not that old even by Apple standards. There are tradeoffs in how best to provide that support. Among those tradeoffs are the impacts to those who provide binary packages for extension modules and third-party libraries, as Russell notes. Again, after investigating and testing the nitty-gritty details, if it seems that a change in how we provide installers is warranted, we can discuss that on Issue19019 and report back here prior to any final decision. Also, at that time, it would be appropriate to consider a policy for long-term support of OS X releases; it's a bit premature to do so now. -- Ned Deily, nad@acm.org
I agree that a policy is a good idea, and I suggest it be primarily based on age, since we cannot assume Apple will release new versions of the OS on a given timeline. I personally think too early to drop support for MacOS X 10.6 and am on the edge about 10.5. -- Russell On Sep 18, 2013, at 5:54 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Am 18.09.13 08:43, schrieb Gregory P. Smith:
Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux.
This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to maintain such a long legacy support tail there ourselves.
I don't mind such a decision in principle, but also in principle, I'd prefer if there was a pre-set policy to decide this question, documented in PEP 11.
Here a piece of OSX release history: - 10.5: October 2007 * 10.5.8: August 2009 - 10.6: August 2009 * 10.6.8: July 2011 - 10.7: July 2011 * 10.7.5: July 2012 - 10.8: July 2012
So possible policy that would now exclude 10.6 for binary installers would be:
- only the two latest feature releases are supported - only feature releases younger than 3 years are supported
Note that a separate policy should be added to decide whether support for older versions is actively removed from source code (or equally bug fixes for old versions are not accepted anymore).
Regards, Martin
Russell Owen <rowen@uw.edu> wrote:
I agree that a policy is a good idea, and I suggest it be primarily based on age, since we cannot assume Apple will release new versions of the OS on a given timeline.
I personally think too early to drop support for MacOS X 10.6 and am on the edge about 10.5.
I run one 10.5 machine, three 10.6 machines, and 5+ 10.7+ machines right now. I have a perfectly fine and fast Mac Pro which can't even be upgraded past 10.7. So using Apple's OS release numbers as the gating factor might be a problem. I'd be happy to drop pre-built binary installers for 10.6, but that's different from dropping all support for it. Bill
-- Russell
On Sep 18, 2013, at 5:54 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Am 18.09.13 08:43, schrieb Gregory P. Smith:
Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux.
This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to maintain such a long legacy support tail there ourselves.
I don't mind such a decision in principle, but also in principle, I'd prefer if there was a pre-set policy to decide this question, documented in PEP 11.
Here a piece of OSX release history: - 10.5: October 2007 * 10.5.8: August 2009 - 10.6: August 2009 * 10.6.8: July 2011 - 10.7: July 2011 * 10.7.5: July 2012 - 10.8: July 2012
So possible policy that would now exclude 10.6 for binary installers would be:
- only the two latest feature releases are supported - only feature releases younger than 3 years are supported
Note that a separate policy should be added to decide whether support for older versions is actively removed from source code (or equally bug fixes for old versions are not accepted anymore).
Regards, Martin
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/bill%40janssen.org
participants (14)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Bill Janssen -
Gregory P. Smith -
Ned Deily -
Raymond Hettinger -
Ronald Oussoren -
Russell E. Owen -
Russell Owen
-
Ryan -
Ryan Gonzalez
-
Skip Montanaro -
Stephen J. Turnbull