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
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
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
Le Wed, 18 Sep 2013 14:54:32 +0200,
Martin v. Löwis mar...@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
On Sep 18, 2013, at 03:36 PM, Antoine Pitrou solip...@pitrou.net wrote:Le Wed, 18 Sep 2013 14:54:32 +0200, "Martin v. Löwis" mar...@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
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
On Sep 18, 2013, at 03:03 PM, "Martin v. Löwis" mar...@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
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
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
Russell Owen ro...@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
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.
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
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
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
On Wed, Sep 18, 2013 at 6:38 AM, Ronald Oussoren ronaldousso...@mac.comwrote:
On Sep 18, 2013, at 03:03 PM, Martin v. Löwis mar...@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
Russell E. Owen ro...@uw.edu wrote:
In article b3293155-e4d5-4389-a555-c31bc49ce...@gmail.com,
Raymond Hettinger raymond.hettin...@gmail.com wrote:
On Sep 14, 2013, at 1:32 PM, Ned Deily n...@acm.org wrote:
The
most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x,
In article b3293155-e4d5-4389-a555-c31bc49ce...@gmail.com,
Raymond Hettinger raymond.hettin...@gmail.com wrote:
On Sep 14, 2013, at 1:32 PM, Ned Deily n...@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
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
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
In article 70c99f87-e9a5-4838-a1e9-4739fbf2e...@gmail.com,
Raymond Hettinger raymond.hettin...@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
On Sep 14, 2013, at 1:32 PM, Ned Deily n...@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
+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.hettin...@gmail.com wrote:
On Sep 14, 2013, at 1:32 PM, Ned Deily
22 matches
Mail list logo
