Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
Terry Reedy wrote: On 2/3/2012 6:18 PM, Steven D'Aprano wrote: Now we're talking about having to add __preview__ into that mix too? As I understand it, Guido nixed that idea. (Or did I imagine that?) No, you are right, discussion should cease. It is already marked 'rejected' and listed under Abandoned, Withdrawn, and Rejected PEPs. Preview modules will be just added to the std lib as normal, and you have to read the docs to find out they're preview. What's New should say so too. A thought comes to mind... It strikes me that it would be helpful sometimes to programmatically recognise "preview" modules in the std lib. Could we have a recommendation in PEP 8 that such modules should have a global variable called PREVIEW, and non-preview modules should not, so that the recommended way of telling them apart is with hasattr(module, "PREVIEW")? -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
On 4 February 2012 11:25, Steven D'Aprano wrote: > It strikes me that it would be helpful sometimes to programmatically > recognise "preview" modules in the std lib. Could we have a recommendation > in PEP 8 that such modules should have a global variable called PREVIEW, and > non-preview modules should not, so that the recommended way of telling them > apart is with hasattr(module, "PREVIEW")? In what situation would you want that when you weren't referring to a specific module? If you're referring to a specific module and you really care, just check sys.version. (That's annoying and ugly enough that it'd probably make you thing about why you are doing it - I cannot honestly think of a case where I'd actually want to check in code if a module is a preview - hence my question as to what your use case is). Feels like YAGNI to me. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OS X build break
In article , Meador Inge wrote: > On Sat, Dec 31, 2011 at 5:56 PM, Guido van Rossum wrote: > > > PS. I would propose a specific fix but I can't seem to build a working > > CPython from the trunk on my laptop (OS X 10.6, Xcode 4.1). I get this error > > late in the build: > > > > ./python.exe -SE -m sysconfig --generate-posix-vars > > Fatal Python error: Py_Initialize: can't initialize sys standard streams > > Traceback (most recent call last): > > File "/Users/guido/cpython/Lib/io.py", line 60, in > > make: *** [Lib/_sysconfigdata.py] Abort trap > > I am having this problem now too. I am running OS X 10.7.2. > 3.2 still builds for me, but I can't build default. > > Did you ever get past it? Anyone else seeing this? Chances are you are using llvm-gcc-4.2, the default CC for Xcode 4.2. There is a critical compile error with it (Issue13241) when building default (3.3). My current recommendations (despite some test failures): - for OS X 10.7.x, use the latest released Xcode, currently Xcode 4.2.1, and build with clang and debug: ./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7 - for OS X 10.6.x, if possible, continue to use the last released Xcode 3.2 (3.2.6), which includes Apple gcc-4.2 (/usr/bin/gcc-4.2 not llvm-gcc-4.2) /usr/bin/gcc-4.2 --version ./configure MACOSX_DEPLOYMENT_TARGET=10.6 or ./configure --with-pydebug MACOSX_DEPLOYMENT_TARGET=10.6 - for OS X 10.6.x with Xcode 4 installed (which does not include Apple gcc-4.2), use the latest Xcode 4.2 for 10.6 and use clang and debug: ./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.6 Unfortunately, testing and sorting out the issues with the current OS X compilers has taken much much longer than anticipated, primarily because it's a big task and, until several days ago, I have had no time to devote to it. But I'm making progress now with installer builds completed for all of default, 3.2-tip, 3.2.2, 2.7-tip, and 2.7.2, each with all of the major compiler combinations on 10.5, 10.6 (Xcode 3.2 and 4.2), and 10.7 (4.1 and 4.2); the tests are running now on each of the applicable environments (that will take about another week to complete). Realistically, we should be able to have everything tested, fixed, and documented by the end of the PyCon sprints next month. We will also have some recommendations for buildbot changes. BTW, the current test failures with clang without pydebug include a number of ctypes test failures (in ctypes.test.test_cfuncs.CFunctions). If anyone has time to further investigate those, it would be very helpful (Issue13370). -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
+1 On Feb 4, 2012 8:37 PM, "Paul Moore" wrote: > > On 4 February 2012 11:25, Steven D'Aprano wrote: > > It strikes me that it would be helpful sometimes to programmatically > > recognise "preview" modules in the std lib. Could we have a recommendation > > in PEP 8 that such modules should have a global variable called PREVIEW, and > > non-preview modules should not, so that the recommended way of telling them > > apart is with hasattr(module, "PREVIEW")? > > In what situation would you want that when you weren't referring to a > specific module? If you're referring to a specific module and you > really care, just check sys.version. (That's annoying and ugly enough > that it'd probably make you thing about why you are doing it - I > cannot honestly think of a case where I'd actually want to check in > code if a module is a preview - hence my question as to what your use > case is). > > Feels like YAGNI to me. > Paul. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OS X build break
On Sat, Feb 4, 2012 at 7:35 AM, Ned Deily wrote: > Chances are you are using llvm-gcc-4.2, the default CC for Xcode 4.2. Yup: motherbrain:python meadori$ sw_vers ProductName:Mac OS X ProductVersion: 10.7.2 BuildVersion: 11C74 motherbrain:python meadori$ gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. motherbrain:python meadori$ clang --version Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.2.0 Thread model: posix > There is a critical compile error with it (Issue13241) when building > default (3.3). My current recommendations (despite some test failures): > > - for OS X 10.7.x, use the latest released Xcode, currently Xcode 4.2.1, > and build with clang and debug: > > ./configure --with-pydebug CC=clang MACOSX_DEPLOYMENT_TARGET=10.7 That worked. Thanks! > Unfortunately, testing and sorting out the issues with the current OS X > compilers has taken much much longer than anticipated, primarily because > it's a big task and, until several days ago, I have had no time to > devote to it. But I'm making progress now with installer builds > completed for all of default, 3.2-tip, 3.2.2, 2.7-tip, and 2.7.2, each > with all of the major compiler combinations on 10.5, 10.6 (Xcode 3.2 and > 4.2), and 10.7 (4.1 and 4.2); the tests are running now on each of the > applicable environments (that will take about another week to complete). > Realistically, we should be able to have everything tested, fixed, and > documented by the end of the PyCon sprints next month. We will also > have some recommendations for buildbot changes. I volunteer to help out if there is anything I can do. > BTW, the current test failures with clang without pydebug include a > number of ctypes test failures (in ctypes.test.test_cfuncs.CFunctions). > If anyone has time to further investigate those, it would be very > helpful (Issue13370). I will look into those. -- # Meador ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
