Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
Ben Finney ben+pyt...@benfinney.id.au writes: Georg Brandl g.bra...@gmx.net writes: list of possible features for 3.3 as specified by PEP 398: Candidate PEPs: […] * PEP 3143: Standard daemon process library Our porting work will not be done in time for Python 3.3. I will update this to target Python 3.4. The PEP document currently says it targets “3.x”. I'll leave it in that state until we're more confident that the current work will be on track for a particular Python release. Do I need to do anything in particular to be explicit that PEP 3143 is not coming in Python 3.3? -- \“Human reason is snatching everything to itself, leaving | `\ nothing for faith.” —Bernard of Clairvaux, 1090–1153 CE | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On Jun 06, 2012, at 05:55 PM, Ben Finney wrote: The PEP document currently says it targets “3.x”. I'll leave it in that state until we're more confident that the current work will be on track for a particular Python release. Do I need to do anything in particular to be explicit that PEP 3143 is not coming in Python 3.3? Nope, I think that's fine. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 05/02/2012 02:24 AM, Ben Finney wrote: Georg Brandl g.bra...@gmx.net writes: list of possible features for 3.3 as specified by PEP 398: Candidate PEPs: […] * PEP 3143: Standard daemon process library I think that http://0pointer.de/public/systemd-man/daemon.html would a good addition to the 'see also' section. It contains a detailed listing of steps to be taked during daemonization. Zbyszek ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 05/01/2012 01:12 PM, Brett Cannon wrote: That would be great! First thing is addressing Guido's concerns from http://mail.python.org/pipermail/python-dev/2012-March/117515.html and then handling any issues you found. Not sure if Larry was asking about this out of curiosity or because he too wanted to help. Asking, that is, off-list. So your observation was kinda out of left field for the casual observer ;-) I was asking because I was interested in helping, but I haven't looked into it too much, and I'm not sure how much of a priority it is. It's clear that Yury has spent way more time with the issue. If he'd* like my help I'll try to lend it but I bet he's got it under control. /arry * Assuming Yury is a he; apologies if my shot in the dark was a miss. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 2012-05-01, at 4:12 PM, Brett Cannon wrote: That would be great! First thing is addressing Guido's concerns from http://mail.python.org/pipermail/python-dev/2012-March/117515.html and then handling any issues you found. Not sure if Larry was asking about this out of curiosity or because he too wanted to help. Great! I'll start looking into this on the weekend. - Yury ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 2012-05-02, at 2:46 AM, Larry Hastings wrote: On 05/01/2012 01:12 PM, Brett Cannon wrote: That would be great! First thing is addressing Guido's concerns from http://mail.python.org/pipermail/python-dev/2012-March/117515.html and then handling any issues you found. Not sure if Larry was asking about this out of curiosity or because he too wanted to help. Asking, that is, off-list. So your observation was kinda out of left field for the casual observer ;-) I was asking because I was interested in helping, but I haven't looked into it too much, and I'm not sure how much of a priority it is. It's clear that Yury has spent way more time with the issue. If he'd* like my help I'll try to lend it but I bet he's got it under control. Let's work on this together. I'll revisit the PEP and Guido's comments, and will get back to you and Brett with my ideas. - Yury ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Open PEPs and large-scale changes for 3.3
With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: Candidate PEPs: * PEP 362: Function Signature Object * PEP 395: Qualified Names for Modules * PEP 397: Python launcher for Windows * PEP 402: Simplified Package Layout (likely a new PEP derived from it) -- I assume PEP 420 is a candidate for that? * PEP 405: Python Virtual Environments * PEP 421: Adding sys.implementation * PEP 3143: Standard daemon process library * PEP 3144: IP Address manipulation library * PEP 3154: Pickle protocol version 4 Other planned large-scale changes: * Addition of the regex module * Email version 6 * A standard event-loop interface (PEP by Jim Fulton pending) * Breaking out standard library and docs in separate repos? Benjamin: I'd also like to know what will become of PEP 415. If anyone feels strongly about one of these items, please get ready to finalize and implement it well before June 23 (beta 1), or we have to discuss about adding another alpha. Also, if I missed any obvious candidate PEP or change, please let me know. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 5/1/2012 7:57 AM, Georg Brandl wrote: With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: ... Also, if I missed any obvious candidate PEP or change, please let me know. I'd like to include PEP 420, Implicit Namespace Packages. We discussed it at PyCon, and a sample implementation is available at features/pep-420. Barry Warsaw, Jason Coombs, and I are sprinting this Thursday to hopefully finish up tests and other loose ends. Then we'll ask that it be accepted. If accepted, we should be able to get it in before alpha 4. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 5/1/2012 8:11 AM, Eric V. Smith wrote: On 5/1/2012 7:57 AM, Georg Brandl wrote: With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: ... Also, if I missed any obvious candidate PEP or change, please let me know. I'd like to include PEP 420, Implicit Namespace Packages. Oops, I missed your reference to PEP 402 and PEP 420. Sorry about that. It is indeed 420 that would replace 402. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On Tue, May 1, 2012 at 9:57 PM, Georg Brandl g.bra...@gmx.net wrote: With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: A few of those are on my plate, soo... * PEP 395: Qualified Names for Modules I'm currently thinking I'll defer this to 3.4. With the importlib change and PEP 420, there's already going to be an awful lot of churn in that space for 3.3, plus I have other things that I consider more important that I want to get done first. * PEP 405: Python Virtual Environments I pinged Carl and Vinay about the remaining open issues yesterday, and indicated I'd really like to have something I can pronounce on soon so we can get it into the fourth alpha on May 26. I'm hoping we'll see the next draft of the PEP soon, but the ball is back in their court for the moment. * PEP 3144: IP Address manipulation library This is pretty close to approval. Peter's addressed all the substantive comments that were made regarding the draft API, and he's going to provide an update to the PEP shortly that should get it into a state where I can mark it as Approved. Integration of the library and tests shouldn't be too hard, but it would really help if a sphinx expert could take a look at my Stack Overflow question [1] about generating an initial version of the API reference docs. (I've been meaning to figure out the right mailing list to send sphinx questions to, but haven't got around to it yet). [1] http://stackoverflow.com/questions/10377576/emit-restructuredtext-from-sphinx-autodoc * Breaking out standard library and docs in separate repos? Our current development infrastructure simply isn't set up to cope with this. With both 407 and 413 still open (and not likely to go anywhere any time soon), this simply isn't going to happen for 3.3. Benjamin: I'd also like to know what will become of PEP 415. I emailed Guido and Benjamin about that one the other day. I'll be PEP czar, and the most likely outcome is that I'll approve the PEP as is and we'll create a separate tracker issue to discuss the exact behaviour of the traceback display functions when they're handed exceptions with __suppress_context__ set to False and __cause__ and __context__ are both non-None (Benjamin's patch preserves the status quo of only displaying __cause__ in that case, which I don't think is ideal, but also don't think is worth holding up PEP 415 over). I'm still waiting to hear back from Benjamin though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
* PEP 3144: IP Address manipulation library This is pretty close to approval. Peter's addressed all the substantive comments that were made regarding the draft API, and he's going to provide an update to the PEP shortly that should get it into a state where I can mark it as Approved. Integration of the library and tests shouldn't be too hard, but it would really help if a sphinx expert could take a look at my Stack Overflow question [1] about generating an initial version of the API reference docs. (I've been meaning to figure out the right mailing list to send sphinx questions to, but haven't got around to it yet). [1] http://stackoverflow.com/questions/10377576/emit-restructuredtext-from-sphinx-autodoc Will this package go through the provisional state mandated by PEP 411 ? Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On Tue, May 1, 2012 at 11:34 PM, Eli Bendersky eli...@gmail.com wrote: * PEP 3144: IP Address manipulation library This is pretty close to approval. Peter's addressed all the substantive comments that were made regarding the draft API, and he's going to provide an update to the PEP shortly that should get it into a state where I can mark it as Approved. Integration of the library and tests shouldn't be too hard, but it would really help if a sphinx expert could take a look at my Stack Overflow question [1] about generating an initial version of the API reference docs. (I've been meaning to figure out the right mailing list to send sphinx questions to, but haven't got around to it yet). [1] http://stackoverflow.com/questions/10377576/emit-restructuredtext-from-sphinx-autodoc Will this package go through the provisional state mandated by PEP 411 ? Yeah, it will. While the ipaddr heritage means we can be confident the underlying implementation is solid, there's no need to be hasty in locking down the cleaned up API. Clarifying that is one of the updates I've asked Peter to make to the PEP before I can accept it. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
2012/5/1 Eli Bendersky eli...@gmail.com: Will this package go through the provisional state mandated by PEP 411 ? I don't see PEP 411 requiring any module to go through its process. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On Tue, May 1, 2012 at 11:43 PM, Benjamin Peterson benja...@python.org wrote: 2012/5/1 Eli Bendersky eli...@gmail.com: Will this package go through the provisional state mandated by PEP 411 ? I don't see PEP 411 requiring any module to go through its process. Indeed, it's a decision to be made on a case-by-case basis when a module is up for inclusion. For example, the unittest.mock API isn't provisional, since it's already been well tested on PyPI. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 2012-05-01, at 7:57 AM, Georg Brandl wrote: With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: Candidate PEPs: * PEP 362: Function Signature Object Regarding PEP 362: there are some outstanding issues with the PEP, that should be resolved. I've outlined some in this email: http://mail.python.org/pipermail/python-dev/2012-March/117540.html If Brett is tied up with the importlib integration, I'd be glad to offer my help with adjustment of the PEP and reference implementation update. - Yury ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On Tue, May 1, 2012 at 07:57, Georg Brandl g.bra...@gmx.net wrote: With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: Candidate PEPs: * PEP 362: Function Signature Object This is mine and I can say that the chance of me getting to this in time is near zero. If someone wants to pick it up and try to finish up the work (which involves addressing Guido's comments on the PEP and seeing if the patch someone submitted is worth looking at) then I'm fine with that. Else this PEP will become a 3.4 addition. -Brett * PEP 395: Qualified Names for Modules * PEP 397: Python launcher for Windows * PEP 402: Simplified Package Layout (likely a new PEP derived from it) -- I assume PEP 420 is a candidate for that? * PEP 405: Python Virtual Environments * PEP 421: Adding sys.implementation * PEP 3143: Standard daemon process library * PEP 3144: IP Address manipulation library * PEP 3154: Pickle protocol version 4 Other planned large-scale changes: * Addition of the regex module * Email version 6 * A standard event-loop interface (PEP by Jim Fulton pending) * Breaking out standard library and docs in separate repos? Benjamin: I'd also like to know what will become of PEP 415. If anyone feels strongly about one of these items, please get ready to finalize and implement it well before June 23 (beta 1), or we have to discuss about adding another alpha. Also, if I missed any obvious candidate PEP or change, please let me know. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On May 01, 2012, at 11:30 PM, Nick Coghlan wrote: * Breaking out standard library and docs in separate repos? Our current development infrastructure simply isn't set up to cope with this. With both 407 and 413 still open (and not likely to go anywhere any time soon), this simply isn't going to happen for 3.3. I concur. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On May 01, 2012, at 08:24 AM, Eric V. Smith wrote: Oops, I missed your reference to PEP 402 and PEP 420. Sorry about that. It is indeed 420 that would replace 402. And the older PEP 382. Once 420 is accepted, we should simply reject 382 and 402. At that point, I'll update them to point to 420. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On Tue, May 1, 2012 at 16:43, Benjamin Peterson benja...@python.org wrote: 2012/5/1 Eli Bendersky eli...@gmail.com: Will this package go through the provisional state mandated by PEP 411 ? I don't see PEP 411 requiring any module to go through its process. You're right, it doesn't require it. However, since Nick's summary above mentioned a draft API, I thought this package can be a good candidate for a PEP-411-process. Without PEP 411, once a module gets into stdlib, its API is pretty much locked. If we are wary of such lock-in with the current state ipaddr's API is in, PEP 411 seems like a reasonable way to go. Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
* PEP 397: Python launcher for Windows I hope to submit a rewrite of this PEP RSN. Also, if I missed any obvious candidate PEP or change, please let me know. A big pending change is the switch to a new Visual Studio release. The challenge here is that we need to stop using the outdated VS 2008, but then, VS 2010 will soon be outdated as well, so it would be sad (IMO) if we switch from one outdated tool to the next. Therefore, I would really like to see Python 3.3 use VS 2012, except that this won't be released for a few more months (the release is likely along with the release for Windows 8, which likely happens this summer). So what specific VS release we use may depend on whether there will be another alpha release or not (but it may also be that another alpha release still won't buy enough time, so that we use VS 2008 for 2.7, VS 2010 for 3.3, and VS 2012 for 3.4). Regards, Martin P.S. There is (as of yet unconfirmed) rumor that VS 2012 won't support XP, which would clearly rule it out for Python 3.3, and likely also for 3.4. It also appears that VS 2012 might include the VS 2010 tool chain, which means that this tool chain won't be that outdated. P.P.S. this affects primarily the build files and the packaging, but then also affects distutils etc., and the buildbots - for the latter, switching the VS version likely means that all Windows buildbots will break, likely requiring several months for them to come back. P.P.P.S. People, please don't propose to drop VS in favor of gcc. That won't happen. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 01.05.2012 16:26, Yury Selivanov wrote: On 2012-05-01, at 7:57 AM, Georg Brandl wrote: With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: Candidate PEPs: * PEP 362: Function Signature Object Regarding PEP 362: there are some outstanding issues with the PEP, that should be resolved. I've outlined some in this email: http://mail.python.org/pipermail/python-dev/2012-March/117540.html If Brett is tied up with the importlib integration, I'd be glad to offer my help with adjustment of the PEP and reference implementation update. If you volunteer, and if Brett agrees to coordinate with you, that would be great. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 01.05.2012 17:48, Martin v. Löwis wrote: * PEP 397: Python launcher for Windows I hope to submit a rewrite of this PEP RSN. Good to hear. Also, if I missed any obvious candidate PEP or change, please let me know. A big pending change is the switch to a new Visual Studio release. The challenge here is that we need to stop using the outdated VS 2008, but then, VS 2010 will soon be outdated as well, so it would be sad (IMO) if we switch from one outdated tool to the next. Therefore, I would really like to see Python 3.3 use VS 2012, except that this won't be released for a few more months (the release is likely along with the release for Windows 8, which likely happens this summer). So what specific VS release we use may depend on whether there will be another alpha release or not (but it may also be that another alpha release still won't buy enough time, so that we use VS 2008 for 2.7, VS 2010 for 3.3, and VS 2012 for 3.4). Do you know when a more detailed schedule for VS 2012 will be available (and confirmation regarding XP support)? While I agree that it would be best to use the most up-to-date toolchain, we shouldn't defer the beta stage indefinitely if there is no concrete date set. P.S. There is (as of yet unconfirmed) rumor that VS 2012 won't support XP, which would clearly rule it out for Python 3.3, and likely also for 3.4. It also appears that VS 2012 might include the VS 2010 tool chain, which means that this tool chain won't be that outdated. P.P.S. this affects primarily the build files and the packaging, but then also affects distutils etc., and the buildbots - for the latter, switching the VS version likely means that all Windows buildbots will break, likely requiring several months for them to come back. Which is definitely not something we want to do during beta stage. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On 01.05.2012 15:30, Nick Coghlan wrote: On Tue, May 1, 2012 at 9:57 PM, Georg Brandl g.bra...@gmx.net wrote: With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: A few of those are on my plate, soo... * PEP 395: Qualified Names for Modules I'm currently thinking I'll defer this to 3.4. With the importlib change and PEP 420, there's already going to be an awful lot of churn in that space for 3.3, plus I have other things that I consider more important that I want to get done first. OK, I've moved this one to the deferred section for now. * PEP 405: Python Virtual Environments I pinged Carl and Vinay about the remaining open issues yesterday, and indicated I'd really like to have something I can pronounce on soon so we can get it into the fourth alpha on May 26. I'm hoping we'll see the next draft of the PEP soon, but the ball is back in their court for the moment. Yes, there also was an RFC on the distutils-sig. * PEP 3144: IP Address manipulation library This is pretty close to approval. Peter's addressed all the substantive comments that were made regarding the draft API, and he's going to provide an update to the PEP shortly that should get it into a state where I can mark it as Approved. Integration of the library and tests shouldn't be too hard, but it would really help if a sphinx expert could take a look at my Stack Overflow question [1] about generating an initial version of the API reference docs. (I've been meaning to figure out the right mailing list to send sphinx questions to, but haven't got around to it yet). [1] http://stackoverflow.com/questions/10377576/emit-restructuredtext-from-sphinx-autodoc I can create that initial .rst for you. It is quite trivial, but not supported by Sphinx without hacking the autodoc code a little. * Breaking out standard library and docs in separate repos? Our current development infrastructure simply isn't set up to cope with this. With both 407 and 413 still open (and not likely to go anywhere any time soon), this simply isn't going to happen for 3.3. Agreed, and moved to deferred. Benjamin: I'd also like to know what will become of PEP 415. I emailed Guido and Benjamin about that one the other day. I'll be PEP czar, and the most likely outcome is that I'll approve the PEP as is and we'll create a separate tracker issue to discuss the exact behaviour of the traceback display functions when they're handed exceptions with __suppress_context__ set to False and __cause__ and __context__ are both non-None (Benjamin's patch preserves the status quo of only displaying __cause__ in that case, which I don't think is ideal, but also don't think is worth holding up PEP 415 over). I'm still waiting to hear back from Benjamin though. I've added 420 to the pending list in any case. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
Do you know when a more detailed schedule for VS 2012 will be available (and confirmation regarding XP support)? Unfortunately, Microsoft doesn't publish any release dates. It's ready when it's ready :-( I just search again, and it appears that some roadmap has leaked: http://www.zdnet.com/blog/microsoft/microsoft-roadmap-leaks-for-office-15-ie-10-and-more-key-products/12417 That says that a release is scheduled for late 2012, which would put it after the Python 3.3 release (contrary to rumors I heard elsewhere). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
Hi, Le 01/05/2012 09:30, Nick Coghlan a écrit : * PEP 3144: IP Address manipulation library This is pretty close to approval. Peter's addressed all the substantive comments that were made regarding the draft API, and he's going to provide an update to the PEP shortly that should get it into a state where I can mark it as Approved. Integration of the library and tests shouldn't be too hard, but it would really help if a sphinx expert could take a look at my Stack Overflow question [1] about generating an initial version of the API reference docs. (I've been meaning to figure out the right mailing list to send sphinx questions to, but haven't got around to it yet). IIUC sphinx-autogen (shipped with Sphinx) does that. Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On Tue, May 1, 2012 at 10:26, Yury Selivanov yselivanov...@gmail.comwrote: On 2012-05-01, at 7:57 AM, Georg Brandl wrote: With 3.3a3 tagged and the beta stage currently 2 months away, I would like to draw your attention to the following list of possible features for 3.3 as specified by PEP 398: Candidate PEPs: * PEP 362: Function Signature Object Regarding PEP 362: there are some outstanding issues with the PEP, that should be resolved. I've outlined some in this email: http://mail.python.org/pipermail/python-dev/2012-March/117540.html If Brett is tied up with the importlib integration, Yes I am. =) I'd be glad to offer my help with adjustment of the PEP and reference implementation update. That would be great! First thing is addressing Guido's concerns from http://mail.python.org/pipermail/python-dev/2012-March/117515.html and then handling any issues you found. Not sure if Larry was asking about this out of curiosity or because he too wanted to help. I think the overall trick is keeping the API simple so it's easy to use but exposes what one could reasonably need (e.g. I wouldn't try to keep the order of keyword-only arguments). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
Georg Brandl g.bra...@gmx.net writes: list of possible features for 3.3 as specified by PEP 398: Candidate PEPs: […] * PEP 3143: Standard daemon process library Our porting work will not be done in time for Python 3.3. I will update this to target Python 3.4. -- \ “The best mind-altering drug is truth.” —Jane Wagner, via Lily | `\Tomlin | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open PEPs and large-scale changes for 3.3
On Wed, May 2, 2012 at 2:58 AM, Éric Araujo mer...@netwok.org wrote: Hi, Le 01/05/2012 09:30, Nick Coghlan a écrit : * PEP 3144: IP Address manipulation library This is pretty close to approval. Peter's addressed all the substantive comments that were made regarding the draft API, and he's going to provide an update to the PEP shortly that should get it into a state where I can mark it as Approved. Integration of the library and tests shouldn't be too hard, but it would really help if a sphinx expert could take a look at my Stack Overflow question [1] about generating an initial version of the API reference docs. (I've been meaning to figure out the right mailing list to send sphinx questions to, but haven't got around to it yet). IIUC sphinx-autogen (shipped with Sphinx) does that. As near as I can tell, autogen does the same thing apidoc does - inserts autodoc directives in the generated .rst files that loads the docstrings at build time. I don't want that - I want to load the docstrings at generation time in order to use them as a basis for the hand written docs. Instead, I'll just take Georg up on his offer to generate the initial file for us. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
