Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 rym...@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 jans...@parc.com wrote: 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, 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 ___ 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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] benchmark
Oops, I wanted to send the patch to myself, not to the python-dev mailing list, sorry :-) (It's a set of patch to try to optimize the tracemalloc module.) Victor 2013/9/18 Victor Stinner victor.stin...@gmail.com: ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 450 adding statistics module
Le Tue, 17 Sep 2013 14:40:21 -0700, Ethan Furman et...@stoneleaf.us a écrit : On 09/17/2013 02:21 PM, Guido van Rossum wrote: Congrats, I've accepted the PEP. Nice work! Please work with the reviewers on the issue on the code. Congratulations, Stephen! Or Steven even ;) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 428: Pathlib - stat caching
Le Tue, 17 Sep 2013 18:10:53 -0700, Philip Jenvey pjen...@underboss.org a écrit : On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote: On Mon, 16 Sep 2013 15:48:54 -0400 Brett Cannon br...@python.org wrote: So I would like to propose the following API change: - Path.stat() (and stat-accessing methods such as get_mtime()...) returns an uncached stat object by default - Path.cache_stat() can be called to return the stat() *and* cache it for future use, such that any future call to stat(), cache_stat() or a stat-accessing function reuses that cached stat In other words, only if you use cache_stat() at least once is the stat() value cached and reused by the Path object. (also, it's a per-Path decision) Any reason why stat() can't get a keyword-only cached=True argument instead? Or have stat() never cache() but stat_cache() always so that people can choose if they want fresh or cached based on API and not whether some library happened to make a decision for them? 1. Because you also want the helper functions (get_mtime(), etc.) to cache the value too. It's not only about stat(). With the proposed rich stat object the convenience methods living on Path wouldn't result in much added convenience: p.is_dir() vs p.stat().is_dir() One reason is that the proposed rich stat object doesn't exist yet :-) 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/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
On 09/17/2013 05:37 PM, Terry Reedy wrote: On 2.7, license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived YearOwner GPL- fromcompatible? (1) 0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRIyes 1.6 1.5.2 2000CNRIno 2.0 1.6 2000BeOpen.com no ... 2.6.5 2.6.4 2010PSF yes 2.7 2.6 2010PSF yes Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list? ... 2.6.4 2.6.3 2009PSF yes 2.6.5 2.6.4 2010PSF yes 3.0 2.6 2008PSF yes 3.0.1 3.0 2009PSF yes ... 3.2.4 3.2.3 2013PSF yes 3.3.0 3.2 2012PSF yes 3.3.1 3.3.0 2013PSF yes Since there are 3 versions of this table, it's unavoidable that one of them gets out of sync :) * LICENSE * Doc/license.rst * the versions for each release on the website So I wholeheartedly support truncating before 2.2 (which is the first release where all micro versions are PSF owned and GPL compatible) and just saying 2.2 onwards (or whatever is the best way to say it). cheers, Georg ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 450 adding statistics module
On 09/18/2013 01:26 AM, Antoine Pitrou wrote: Le Tue, 17 Sep 2013 14:40:21 -0700, Ethan Furman et...@stoneleaf.us a écrit : On 09/17/2013 02:21 PM, Guido van Rossum wrote: Congrats, I've accepted the PEP. Nice work! Please work with the reviewers on the issue on the code. Congratulations, Stephen! Or Steven even ;) *sigh* I used to be a good speller, too! -- ~Ethan~ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 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'dprefer 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___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 mar...@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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 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___ 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/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
OK. Let's do it. On Wed, Sep 18, 2013 at 1:54 AM, Georg Brandl g.bra...@gmx.net wrote: On 09/17/2013 05:37 PM, Terry Reedy wrote: On 2.7, license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived YearOwner GPL- fromcompatible? (1) 0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRIyes 1.6 1.5.2 2000CNRIno 2.0 1.6 2000BeOpen.com no ... 2.6.5 2.6.4 2010PSF yes 2.7 2.6 2010PSF yes Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list? ... 2.6.4 2.6.3 2009PSF yes 2.6.5 2.6.4 2010PSF yes 3.0 2.6 2008PSF yes 3.0.1 3.0 2009PSF yes ... 3.2.4 3.2.3 2013PSF yes 3.3.0 3.2 2012PSF yes 3.3.1 3.3.0 2013PSF yes Since there are 3 versions of this table, it's unavoidable that one of them gets out of sync :) * LICENSE * Doc/license.rst * the versions for each release on the website So I wholeheartedly support truncating before 2.2 (which is the first release where all micro versions are PSF owned and GPL compatible) and just saying 2.2 onwards (or whatever is the best way to say it). cheers, Georg ___ 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 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 mar...@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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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, n...@acm.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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] License() release list is imcomplete; intentional?
Now tracked at http://bugs.python.org/issue19043 Georg On 09/18/2013 04:57 PM, Guido van Rossum wrote: OK. Let's do it. On Wed, Sep 18, 2013 at 1:54 AM, Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: On 09/17/2013 05:37 PM, Terry Reedy wrote: On 2.7, license() return a text that includes a complete list of releases from 1.6 to 2.7 and stops there Release Derived YearOwner GPL- fromcompatible? (1) 0.9.0 thru 1.2 1991-1995 CWI yes 1.3 thru 1.5.2 1.2 1995-1999 CNRIyes 1.6 1.5.2 2000CNRIno 2.0 1.6 2000BeOpen.com no ... 2.6.5 2.6.4 2010PSF yes 2.7 2.6 2010PSF yes Was it intentional to stop with 2.7 and not continue with 2.7.1, etc? On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional? It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. Should 3.3.2 be included in the 3.3.2 list? ... 2.6.4 2.6.3 2009PSF yes 2.6.5 2.6.4 2010PSF yes 3.0 2.6 2008PSF yes 3.0.1 3.0 2009PSF yes ... 3.2.4 3.2.3 2013PSF yes 3.3.0 3.2 2012PSF yes 3.3.1 3.3.0 2013PSF yes Since there are 3 versions of this table, it's unavoidable that one of them gets out of sync :) * LICENSE * Doc/license.rst * the versions for each release on the website So I wholeheartedly support truncating before 2.2 (which is the first release where all micro versions are PSF owned and GPL compatible) and just saying 2.2 onwards (or whatever is the best way to say it). cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido http://python.org/~guido) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.6): #14984: only import pwd on POSIX.
On Sep 18, 2013, at 03:00 PM, r.david.murray wrote: http://hg.python.org/cpython/rev/fb3ad8a749c8 changeset: 85749:fb3ad8a749c8 branch: 2.6 parent: 85735:1b673e0fd8f3 user:R David Murray rdmur...@bitdance.com date:Wed Sep 18 08:49:25 2013 -0400 summary: #14984: only import pwd on POSIX. files: Lib/netrc.py | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/Lib/netrc.py b/Lib/netrc.py --- a/Lib/netrc.py +++ b/Lib/netrc.py @@ -2,7 +2,9 @@ # Module and documentation by Eric S. Raymond, 21 Dec 1998 -import os, stat, shlex, pwd +import os, stat, shlex +if os.name == 'posix': +import pwd Would it make more sense to do: try: import pwd except ImportError: pwd = None ? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.6): #14984: only import pwd on POSIX.
On Wed, 18 Sep 2013 21:38:48 -0400, Barry Warsaw ba...@python.org wrote: On Sep 18, 2013, at 03:00 PM, r.david.murray wrote: http://hg.python.org/cpython/rev/fb3ad8a749c8 changeset: 85749:fb3ad8a749c8 branch: 2.6 parent: 85735:1b673e0fd8f3 user:R David Murray rdmur...@bitdance.com date:Wed Sep 18 08:49:25 2013 -0400 summary: #14984: only import pwd on POSIX. files: Lib/netrc.py | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/Lib/netrc.py b/Lib/netrc.py --- a/Lib/netrc.py +++ b/Lib/netrc.py @@ -2,7 +2,9 @@ # Module and documentation by Eric S. Raymond, 21 Dec 1998 -import os, stat, shlex, pwd +import os, stat, shlex +if os.name == 'posix': +import pwd Would it make more sense to do: try: import pwd except ImportError: pwd = None I don't think so. The code that uses pwd is protected by an 'if os.name == 'posix' as well. I think that's clearer than setting pwd to none and guarding that section by 'if pwd'. And in 3.4 I just moved the import into the if block that uses it. --David ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
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 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 ___ 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/archive%40mail-archive.com
