Re: [Python-Dev] Distutils2 next steps
On Mon, Feb 21, 2011 at 8:48 AM, Georg Brandl wrote: > On 21.02.2011 08:41, Tarek Ziadé wrote: >> Hello >> >> Now that Python 3.2 is out, I am planning to do the following with >> Distutils2: >> >> 1 - release a new alpha before Pycon for community feedback >> 2 - add distutils2 back in the trunk, along with the changes in >> pkgutil and sysconfig >> 3 - continue the ongoing work in Distutils2 to prepare the first >> Python 3.3 release >> >> If you want me to give more details here on what is going to be done >> precisely in the various stdlib parts, let me know. > > I think I'm also speaking for the prospective release manager of 3.3 > by saying yes, please, details would be nice, but not necessarily > *right* now. :) It's easy enough to give right now: - pkgutil will gain all the API that are implementing PEP 376 -- a py2 version of this module that has them can be seen at http://hg.python.org/distutils2/file/tip/distutils2/_backport/pkgutil.py for the moment - sysconfig will need to have two things: - create via the Makefile a "_sysconfig" module, so the API stop to read data dynamically in pyconfig.h and Makefile at runtime - [to be validated-discussed] an easier way to configure the installation paths. the current plan is to use a sysconfig.cfg file that may be changed. This file will be global to Python, but also possibly local to a user or a project -- http://hg.python.org/distutils2/file/tip/distutils2/_backport/sysconfig.cfg - distutils2 will be converted to Py3 using 2to3, then included in Lib/ -- the code base is ready for this, besides a few spots. - distutils2 will continue to be released as a standalone project from 2.4 to 3.2. Probably by using 3to2, but I have not tried the tool yet. Cheers Tarek > > Georg > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com > -- Tarek Ziadé | http://ziade.org ___ 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
[Python-Dev] Are these PEP complete?: 389, 391, 3108, 3135
As the subject line asks, is there anything preventing the following PEPs from being marked Final? SA 389 argparse - New Command Line Parsing Module Bethard SA 391 Dictionary-Based Configuration For Logging Sajip SA 3108 Standard Library Reorganization Cannon SA 3121 Extension Module Initialization and Finalizationvon Löwis SA 3135 New Super Spealman, Delaney, Ryan (I deliberately left 3118 off the list, since there are some discrepancies between the PEP and the implementation that need to be clarified for 3.3 and the 3 distutils related PEPs won't be done until Tarek merges distutils2 back into the main line of development) It would be good to clear the decks before new PEPs start to be accepted for inclusion in 3.3. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Are these PEP complete?: 389, 391, 3108, 3135
On Mon, Feb 21, 2011 at 4:52 AM, Nick Coghlan wrote: > As the subject line asks, is there anything preventing the following > PEPs from being marked Final? > > SA 389 argparse - New Command Line Parsing Module Bethard > SA 391 Dictionary-Based Configuration For Logging Sajip > SA 3108 Standard Library Reorganization Cannon > SA 3121 Extension Module Initialization and Finalization von Löwis > SA 3135 New Super > Spealman, Delaney, Ryan Somebody (not me, not necessarily the same person for each PEP) needs to check each of these PEPs for how well they match the implemented reality and report back here. (Unless you already did this and are basically giving them a certificate of correctness with your post?) > (I deliberately left 3118 off the list, since there are some > discrepancies between the PEP and the implementation that need to be > clarified for 3.3 and the 3 distutils related PEPs won't be done until > Tarek merges distutils2 back into the main line of development) > > It would be good to clear the decks before new PEPs start to be > accepted for inclusion in 3.3. Why? -- --Guido van Rossum (python.org/~guido) ___ 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] Bug in linking to gomp with python; causes crash in matplotlib.
> An associated bug report would be appreciated (mailing list > discussions are useful for raising awareness, but are more likely to > be forgotten over time than bug reports): http://bugs.python.org Just did that; thanks! -- Hoyt + Hoyt Koepke + University of Washington Department of Statistics + http://www.stat.washington.edu/~hoytak/ + [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] Distutils2 next steps
On Mon, Feb 21, 2011 at 00:02, Tarek Ziadé wrote: > On Mon, Feb 21, 2011 at 8:48 AM, Georg Brandl wrote: >> On 21.02.2011 08:41, Tarek Ziadé wrote: >>> Hello >>> >>> Now that Python 3.2 is out, I am planning to do the following with >>> Distutils2: >>> >>> 1 - release a new alpha before Pycon for community feedback >>> 2 - add distutils2 back in the trunk, along with the changes in >>> pkgutil and sysconfig >>> 3 - continue the ongoing work in Distutils2 to prepare the first >>> Python 3.3 release >>> >>> If you want me to give more details here on what is going to be done >>> precisely in the various stdlib parts, let me know. >> >> I think I'm also speaking for the prospective release manager of 3.3 >> by saying yes, please, details would be nice, but not necessarily >> *right* now. :) > > It's easy enough to give right now: > > - pkgutil will gain all the API that are implementing PEP 376 -- a py2 > version of this module that has them can be seen at > http://hg.python.org/distutils2/file/tip/distutils2/_backport/pkgutil.py > for the moment > > - sysconfig will need to have two things: > > - create via the Makefile a "_sysconfig" module, so the API stop to > read data dynamically in pyconfig.h and Makefile at runtime > - [to be validated-discussed] an easier way to configure the > installation paths. the current plan is to use a sysconfig.cfg file > that may be changed. This file will be global to Python, but also > possibly local to a user or a project -- > http://hg.python.org/distutils2/file/tip/distutils2/_backport/sysconfig.cfg > > - distutils2 will be converted to Py3 using 2to3, then included in > Lib/ -- the code base is ready for this, besides a few spots. > > - distutils2 will continue to be released as a standalone project from > 2.4 to 3.2. Probably by using 3to2, but I have not tried the tool yet. So does this mean that primary development will move to py3k and then you will simply push changes downstream to the distutils2 project for separate releases? Or are you going to go the reverse route? -Brett > > > Cheers > Tarek > >> >> Georg >> >> >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com >> > > > > -- > Tarek Ziadé | http://ziade.org > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ 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] Are these PEP complete?: 389, 391, 3108, 3135
On Mon, Feb 21, 2011 at 04:52, Nick Coghlan wrote: > As the subject line asks, is there anything preventing the following > PEPs from being marked Final? > > SA 389 argparse - New Command Line Parsing Module Bethard > SA 391 Dictionary-Based Configuration For Logging Sajip > SA 3108 Standard Library Reorganization Cannon PEP 3108 (http://bugs.python.org/issue2775) will be considered done once cProfile and profile are merged. -Brett > SA 3121 Extension Module Initialization and Finalization von Löwis > SA 3135 New Super > Spealman, Delaney, Ryan > > (I deliberately left 3118 off the list, since there are some > discrepancies between the PEP and the implementation that need to be > clarified for 3.3 and the 3 distutils related PEPs won't be done until > Tarek merges distutils2 back into the main line of development) > > It would be good to clear the decks before new PEPs start to be > accepted for inclusion in 3.3. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ 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] Distutils2 next steps
On Mon, Feb 21, 2011 at 7:22 PM, Brett Cannon wrote: ... >> - distutils2 will continue to be released as a standalone project from >> 2.4 to 3.2. Probably by using 3to2, but I have not tried the tool yet. > > So does this mean that primary development will move to py3k and then > you will simply push changes downstream to the distutils2 project for > separate releases? Or are you going to go the reverse route? I will backport from py3k to the standalone version, yes. I think it will be better because the changes will be exposed to more people in the Python trunk, and maybe get more feedback before pushing downstream Cheers Tarek > > -Brett > >> >> >> Cheers >> Tarek >> >>> >>> Georg >>> >>> >>> ___ >>> Python-Dev mailing list >>> [email protected] >>> http://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com >>> >> >> >> >> -- >> Tarek Ziadé | http://ziade.org >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/brett%40python.org >> > -- Tarek Ziadé | http://ziade.org ___ 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] Are these PEP complete?: 389, 391, 3108, 3135
On Tue, Feb 22, 2011 at 3:20 AM, Guido van Rossum wrote: > On Mon, Feb 21, 2011 at 4:52 AM, Nick Coghlan wrote: >> As the subject line asks, is there anything preventing the following >> PEPs from being marked Final? >> >> SA 389 argparse - New Command Line Parsing Module Bethard >> SA 391 Dictionary-Based Configuration For Logging Sajip >> SA 3108 Standard Library Reorganization Cannon >> SA 3121 Extension Module Initialization and Finalization von Löwis >> SA 3135 New Super >> Spealman, Delaney, Ryan > > Somebody (not me, not necessarily the same person for each PEP) needs > to check each of these PEPs for how well they match the implemented > reality and report back here. (Unless you already did this and are > basically giving them a certificate of correctness with your post?) I did have a look and those listed are the ones that seemed to be finished. Before moving them to Final, I figured I would ask for additional opinions in case I had missed something and they still had some elements that needed to be implemented for 3.3. As it turns out, I had missed the incomplete profile/cProfile merge for PEP 3108. >> It would be good to clear the decks before new PEPs start to be >> accepted for inclusion in 3.3. > > Why? It's mainly just a continuation of the PEP 0 cleanup I started a while back, trying to make it clearer which major items are still on the to-do list for 3.3 and which were completed for 3.2. I have an associated PEP 1 update I'd like to propose as well (giving the API/metadata standardisation PEPs a dedicated "Consensus" state to better separate them from Accepted language and standard library feature PEPs), but I need to actually write it first. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
[Python-Dev] Const-correctness in C-API Object Protocol
Hi,
I was wondering if there is some reason why C API functions like
PyObject_CallMethod[1] and PySys_GetObject[2] take char* arguments
rather than const char*s? If there is some reason these methods will
modify their string arguments, it would be nice if it was documented,
because at the moment it's unclear whether it is safe to cast a string
literal to char* in these cases. For instance it seems reasonable that
I should be able to call PySys_GetObject("path") without having to
deal with a 'deprecated conversion from string constant to ‘char*’'
error.
Thanks,
--
David Claridge
http://daave.com
[1] http://docs.python.org/c-api/object.html
[2] http://docs.python.org/c-api/sys.html
___
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] [Python-checkins] r88484 - in python/branches/py3k: Lib/test/subprocessdata/fd_status.py Lib/test/test_subprocess.py Misc/NEWS
Le 21/02/2011 22:55, antoine.pitrou a écrit :
Author: antoine.pitrou
Date: Mon Feb 21 22:55:48 2011
New Revision: 88484
Log:
Issue #10826: Prevent sporadic failure in test_subprocess on Solaris due
to open door files.
if __name__ == "__main__":
-print(','.join(str(fd) for fd in range(0, _MAXFD) if isopen(fd)))
+fds = []
+for fd in range(0, _MAXFD):
+try:
+st = os.fstat(fd)
+except OSError as e:
+if e.errno == errno.EBADF:
+continue
+raise
+# Ignore Solaris door files
+if st.st_mode& 0xF000 != 0xd000:
+fds.append(fd)
Are 0xF000 and 0xD000 constants specific to Solaris? If yes, you may
only skip these files on Solaris, not on other OSes.
Victor
___
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
[Python-Dev] Mail System Error - Returned Mail
The original message was received at Tue, 22 Feb 2011 08:29:51 +0700 from pancaprima.com [196.86.11.104] - The following addresses had permanent fatal errors - ___ 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
[Python-Dev] Is Demo directory removed from python3.2 ?
Hi, I found 2 changes in python-3.2 compared to previous python version: i) Demo directory removed ii) lib/libpython3.2.so.1 changed to lib/libpython3.2mu.so.1 Would someone tell me why ? Thanks at advance. wen ___ 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] Is Demo directory removed from python3.2 ?
On Mon, Feb 21, 2011 at 21:02, wen heping wrote: > Hi, > > I found 2 changes in python-3.2 compared to previous python version: > i) Demo directory removed >From the "What's new in 3.2" document: The unmaintained Demo directory has been removed. Some demos were integrated into the documentation, some were moved to the Tools/demo directory, and others were removed altogether. See http://bugs.python.org/issue7962 ___ 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] Is Demo directory removed from python3.2 ?
On Mon, Feb 21, 2011 at 10:02 PM, wen heping wrote: > Hi, > > I found 2 changes in python-3.2 compared to previous python version: > i) Demo directory removed > ii) lib/libpython3.2.so.1 changed to lib/libpython3.2mu.so.1 > > Would someone tell me why ? The demo directory was largely out of date (some of it by a decade). Most of what was in it plain didn't work or was an outdated example of how you should do things. The good stuff was moved into the documentation or the standard library. -Jack ___ 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] Is Demo directory removed from python3.2 ?
On Tue, Feb 22, 2011 at 1:02 PM, wen heping wrote: > Hi, > > I found 2 changes in python-3.2 compared to previous python version: > i) Demo directory removed > ii) lib/libpython3.2.so.1 changed to lib/libpython3.2mu.so.1 Others have answered your first question, but the latter is part of PEP 3149: http://docs.python.org/py3k/whatsnew/3.2.html#pep-3149-abi-version-tagged-so-files In addition to allowing multiple builds of extension modules to exist in parallel, PEP 3149 allows multiple builds of Python itself (with different build options) to coexist. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
