Re: [Python-Dev] Possible major bug with zipimport on Windows in Python 3.3.4
Am 15.02.2014 23:19, schrieb Paul Moore: On 13 February 2014 20:58, Paul Moore p.f.mo...@gmail.com wrote: On 13 February 2014 20:54, Donald Stufft don...@stufft.io wrote: On Feb 13, 2014, at 3:53 PM, Paul Moore p.f.mo...@gmail.com wrote: Can someone please take a look at http://bugs.python.org/issue20621 for me? It appears that there is a significant problem with zipimport in 3.3.4. It's causing breakage in virtualenv but I've isolated the issue to what I think is Python itself. Basically, until this bug is fixed, virtualenv won't work on Windows with Python 3.3.4, as far as I can tell. Does it affect 3.4? Just checked that. No, it's not an issue in 3.4rc0. Nor is it in 3.3.3, so it's a regression in the 3.3 series only. OK, this appears to be a serious regression that breaks virtualenv. Steve Dower suggested a workaround on the tracker, but I don't think that can be made to work in the case of virtualenv (for reasons not worth explaining now, ask me if you want the details though). Given where we are, what is the way forward here? I'm not entirely sure what I should be saying to the user who reported the bug in virtualenv. I think I'll recommend downgrading to 3.3.3 for now, but it would be good to be able to give an idea of what the longer term solution is likely to be. As soon as a patch has been provided and tested, I will make a schedule for 3.3.5 including the fix. Until then, using 3.3.3 is probably the best solution. 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] CLA link from bugs.python.org
Hi, On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, On Sun, May 5, 2013 at 4:23 AM, Tim Delaney timothy.c.dela...@gmail.com wrote: It appears there's no obvious link from bugs.python.org to the contributor agreement - you need to go via the unintuitive link Foundation - Contribution Forms (and from what I've read, you're prompted when you add a patch to the tracker). I'd suggest that if the Contributor Form Received field is No in user details, there be a link to http://www.python.org/psf/contrib/. See http://psf.upfronthosting.co.za/roundup/meta/issue461. This is now done: users who submit(ted) patches without having signed the contributor agreement will get a note in tracker with the link and a short explanation. (Sorry it took me so long to get this fixed.) Best Regards, Ezio Melotti Best Regards, Ezio Melotti Tim Delaney ___ 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] CLA link from bugs.python.org
Am 16.02.2014 09:40, schrieb Ezio Melotti: Hi, On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, On Sun, May 5, 2013 at 4:23 AM, Tim Delaney timothy.c.dela...@gmail.com wrote: It appears there's no obvious link from bugs.python.org to the contributor agreement - you need to go via the unintuitive link Foundation - Contribution Forms (and from what I've read, you're prompted when you add a patch to the tracker). I'd suggest that if the Contributor Form Received field is No in user details, there be a link to http://www.python.org/psf/contrib/. See http://psf.upfronthosting.co.za/roundup/meta/issue461. This is now done: users who submit(ted) patches without having signed the contributor agreement will get a note in tracker with the link and a short explanation. (Sorry it took me so long to get this fixed.) Thanks, that is a great improvement. (Although I don't think I like the red background color... ) 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] Using more specific methods in Python unit tests
On 16/02/2014 00:22, Nick Coghlan wrote: On 16 February 2014 09:20, Ned Deily n...@acm.org wrote: In article 1392492250.26338.83831085.39a5e...@webmail.messagingengine.com, Benjamin Peterson benja...@python.org wrote: On Sat, Feb 15, 2014, at 10:12 AM, Serhiy Storchaka wrote: Although Raymond approved a patch for test_bigmem [2], his expressed the insistent recommendation not to do this. So I stop committing new reviewed patches. Terry recommended to discuss this in Python-Dev. What are your thoughts? I tend to agree with Raymond. I think such changes are very welcome when the module or tests are otherwise being changed, but on their on constitute unnecessary churn. Right, there are a few key problems with large scale style changes to the test suite: 1. The worst case scenario is where we subtly change a test so that it is no longer testing what it is supposed to be testing, allowing the future introduction of an undetected regression. This isn't particularly *likely*, but a serious problem if it happens. 2. If there are pending patches for that module that include new tests, then the style change may cause the patches to no longer apply cleanly, require rework of bug fix and new feature patches to accommodate the style change. 3. Merges between branches may become more complicated (for reasons similar to 2), unless the style change is also applied to the maintenance branches (which is problematic due to 1). I spend a *lot* of time working with the Python test suite on behalf of Jython, so I appreciate the care CPython puts into its testing. To a large extent, tests written for CPython drive Jython development: I suspect I work with a lot more failing tests than anyone here. Where we have a custom test, I often update them from in the latest CPython tests. Often a test failure is not caused by code I just wrote, but by adding a CPython test or removing a skip if Jython, and not having written anything yet. While the irrefutable False is not true always raises a smile, I'd welcome something more informative. It's a more than a style issue. What Nick says above is also not false, as general guidance, but taken as an iron rule seem to argue against concurrent development at all. Don't we manage this change pretty well already? I see little risk of problems 1-3 in the actual proposal, as the changes themselves are 99% of the drop-in replacement type: -self.assertTrue(isinstance(x, int)) +self.assertIsInstance(x, int) I found few places, on a quick scan, that risked changing the meaning: they introduce an if-statement, or refactor the expression -- I don't mean they're actually wrong. The point about breaking Serhiy's patch into independent parts will help manage with merging and this risk. The tests are not library code, but their other use is as an example of good practice in unit testing. I pretty much get my idea of Python's test facilities from this work. It was a while before I realised more expressive methods were available. Jeff Jeff Allen ___ 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] Using more specific methods in Python unit tests
On Sat, 15 Feb 2014 20:12:33 +0200 Serhiy Storchaka storch...@gmail.com wrote: I wrote a large patch which modifies the tests to use more specific methods [1]. Because it is too large, it was divided into many smaller patches, and separate issues were opened for them. At the moment the major part of the original patch has already been committed. Many thanks to Ezio for making a review for the majority of the issues. Some changes have been made by other people in unrelated issues. Although Raymond approved a patch for test_bigmem [2], his expressed the insistent recommendation not to do this. So I stop committing new reviewed patches. Terry recommended to discuss this in Python-Dev. What are your thoughts? When it comes specifically to test_bigmem, it is important for error messages to be informative, because the failures may be hard (if not enough RAM) or very long to diagnose on a developer's machine. So +1 to changing test_bigmem. As for the rest of the test suite, I find the assertSpecific form more readable that assertTrue(... with some operator). But I may be in a minority here :-) As for the code churn argument, I find that a much less important concern for the test suite than for the rest of the code. 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] Possible major bug with zipimport on Windows in Python 3.3.4
On 16 February 2014 08:19, Georg Brandl g.bra...@gmx.net wrote: As soon as a patch has been provided and tested, I will make a schedule for 3.3.5 including the fix. Until then, using 3.3.3 is probably the best solution. Fantastic - thanks for that. Paul ___ 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] Using more specific methods in Python unit tests
On Sun, Feb 16, 2014 at 12:22 AM, Nick Coghlan ncogh...@gmail.com wrote: The practical benefits of this kind of change in the test suite are also highly dubious, because they *only help if the test fails at some point in the future*. At that point, whoever caused the test to fail will switch into debugging mode, and a couple of relevant points apply: One place where those points don't apply so cleanly is when the test failure is coming from continuous integration and can't easily be reproduced locally (e.g., because there's a problem on a platform you don't have access to, or because it's some kind of threading-related intermittent failure that's exacerbated by the timing conditions on a particular machine). In those situations, an informative error message can easily save significant debugging time. Count me as +1 on the test updates, provided they're done carefully. (And all those I've looked at from Serhiy do indeed look careful.) -- Mark ___ 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] Using more specific methods in Python unit tests
Jeff Allen, 16.02.2014 11:23: I spend a *lot* of time working with the Python test suite on behalf of Jython, so I appreciate the care CPython puts into its testing. To a large extent, tests written for CPython drive Jython development: I suspect I work with a lot more failing tests than anyone here. Careful with such a bold statement. ;) What Nick says above is also not false, as general guidance, but taken as an iron rule seem to argue against concurrent development at all. Don't we manage this change pretty well already? I see little risk of problems 1-3 in the actual proposal, as the changes themselves are 99% of the drop-in replacement type: -self.assertTrue(isinstance(x, int)) +self.assertIsInstance(x, int) While I generally second Nick's objections to this, I also agree that the kind of change above is such an obvious and straight forward improvement (since unittest doesn't have py.test's assert analysis) that I'm +1 on applying them. I've been annoyed more than once by a test failure in CPython's test suite (when compiled with Cython) that required me to look up and read the test source and rerun it locally in order to actually understand what was happening. Seeing a more informative error message right on our CI server would certainly help, if only to get a quicker idea if this failure is worth taking a closer look at. Stefan ___ 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] The desired behaviour for resolve() when the path doesn't exist
On Wed, Jan 8, 2014 at 4:45 AM, Serhiy Storchaka storch...@gmail.com wrote: --canonicalize is not strict. --canonicalize-existing is most strict and --canonicalize-missing is least strict. When you have a function which have non-strict behavior (--canonicalize), you can implement a wrapper with strict behavior (--canonicalize-existing), but not vice verse. Sorry, only now that I have time to look into this. So what we are going to do before implementing the behaviour for resolve(strict=False) is to change the behaviour of resolve(strict=True) from --canonicalize-existing to --canonicalize? Is there any time left because we are in RC1 already? Should we postpone it to 3.5? But then, we'll have backward compatibility problem. ___ 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] CLA link from bugs.python.org
On Sun, Feb 16, 2014 at 11:06 AM, Georg Brandl g.bra...@gmx.net wrote: Am 16.02.2014 09:40, schrieb Ezio Melotti: Hi, On Sun, May 5, 2013 at 7:45 AM, Ezio Melotti ezio.melo...@gmail.com wrote: Hi, On Sun, May 5, 2013 at 4:23 AM, Tim Delaney timothy.c.dela...@gmail.com wrote: It appears there's no obvious link from bugs.python.org to the contributor agreement - you need to go via the unintuitive link Foundation - Contribution Forms (and from what I've read, you're prompted when you add a patch to the tracker). I'd suggest that if the Contributor Form Received field is No in user details, there be a link to http://www.python.org/psf/contrib/. See http://psf.upfronthosting.co.za/roundup/meta/issue461. This is now done: users who submit(ted) patches without having signed the contributor agreement will get a note in tracker with the link and a short explanation. (Sorry it took me so long to get this fixed.) Thanks, that is a great improvement. (Although I don't think I like the red background color... ) Agreed, that's why I timemachined it gray: http://hg.python.org/tracker/python-dev/rev/4cdbeb1c74c6#l2.11 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/ezio.melotti%40gmail.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
[Python-Dev] pootle.python.org is down
I came across http://bugs.python.org/issue13663, which is about a pootle.python.org installation. http://pootle.python.org/ currently returns a 500. Are we still using Pootle, or should I just close #13663? (Maybe the installation got broken in the move to OSL and then forgotten?) --amk ___ 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] pootle.python.org is down
On Sun, Feb 16, 2014, at 06:52 AM, A.M. Kuchling wrote: I came across http://bugs.python.org/issue13663, which is about a pootle.python.org installation. http://pootle.python.org/ currently returns a 500. Are we still using Pootle, or should I just close #13663? (Maybe the installation got broken in the move to OSL and then forgotten?) Per the comments in that bug (esp from Martin), I think we should just remove pootle.python.org for good. ___ 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] pootle.python.org is down
Am 16.02.2014 16:32, schrieb Benjamin Peterson: On Sun, Feb 16, 2014, at 06:52 AM, A.M. Kuchling wrote: I came across http://bugs.python.org/issue13663, which is about a pootle.python.org installation. http://pootle.python.org/ currently returns a 500. Are we still using Pootle, or should I just close #13663? (Maybe the installation got broken in the move to OSL and then forgotten?) Per the comments in that bug (esp from Martin), I think we should just remove pootle.python.org for good. For now. 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
[Python-Dev] Python 3.4: What to do about the Derby patches
Let's begin with a status update of The Great Argument Clinic Conversion Derby. In retrospect, the Derby was way too ambitious. Once it started I was quickly overwhelmed. Even doing nothing but Derby work, all day every day for two straight weeks, I couldn't keep up with all the bug fixes, feature requests, correspondence, and documentation updates it demanded. There was no way I could simultaneously review patches too. As a result: there is, still, an enormous backlog of Derby patches that need reviewing. Few of the Derby patches got integrated before we reached rc1. The underlying theory of the Derby was that it would be a purely mechanical process. It would be a simple matter of converting the existing parsing code into its Argument Clinic equivalent, resulting solely in code churn. And, indeed, a significant portion of the Derby patches are exactly that. But the conversion process peered into a lot of dusty corners, and raised a lot of questions, and as a result it was a much more complicated and time-consuming process than I anticipated. So here we are in the release candidate period for 3.4, and we still have all these unmerged Derby patches. And it's simply too late in the release cycle to merge them for 3.4.0. Here's how I propose we move forward. 1) We merge the Derby patch for the builtins module into 3.4, simply because it will demo well. If someone wants to play with signatures on builtins, I think it's likely they'll try something like len. Obviously this wouldn't be permitted to change the semantics of argument parsing in any way--this would be a code churn patch only. (In case you're wondering, Nick did the conversion of the builtins module, and naturally I will be reviewing it.) 2) We change all Clinic conversions in 3.4 so they write the generated code to a separate file--in Clinic parlance, change them so they 'use the file destination'. Going forward this will be the preferred way to check in Argument Clinic changes into Python. These first two are the only changes resulting from the Derby that I will accept between now and 3.4.0 final, and I expect to have them in for 3.4.0rc2. Continuing from there: 3) We hold off on merging the rest of the Derby patches until after 3.4.0 final ships, then we merge them into the 3.4 maintenance branch so they go into 3.4.1. We use the time between now and then to get the patches totally, totally perfect. Again, these patches will not be permitted to change the parsing semantics of the functions so converted. I expect to do these checkins in a private branch, and land the bulk of it immediately upon the opening of the 3.4 maintenance branch. 4) We accelerate the schedule for 3.4.1 slightly, so we can get these new signatures into the hands of users sooner. Specifically, I propose we ship 3.4.1 two months after 3.4.0. I figure we would release 3.4.1 rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th. 5) Any proposed changes in Derby patches that change the semantics of a builtin may only be checked into default for 3.5, after 3.4.0 ships. I'm very sorry that many people contributed to the Derby expecting their patches to go in to 3.4. This is my fault, for severely miscalculating how the Derby would play out. And I feel awful about it. But I'm convinced the best thing for Python is to hold off on merging until after 3.4.0 ships. //arry/ ___ 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] Possible major bug with zipimport on Windows in Python 3.3.4
16.02.14 10:19, Georg Brandl написав(ла): As soon as a patch has been provided and tested, I will make a schedule for 3.3.5 including the fix. Until then, using 3.3.3 is probably the best solution. Then could you please include the fix for #20538 (this bug allows easily crash Python e.g. by special HTTP request or e-mail). And I think it is very important to port the fix for #19619. Simple patch for #17671 fixes other crash (less important, because can be triggered only by programming error). ___ 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] Add Py_REPLACE and Py_XREPLACE macros
16.02.14 02:05, Nick Coghlan написав(ла): It's also likely than many of these crashes could only be reproduced through incorrect usage of the C API. Rather through queer or malicious usage of Python classes with strange code in __del__. For example: Py_CLEAR_AND_SET Py_XCLEAR_AND_SET Such that Py_CLEAR and Py_XCLEAR are equivalent to: There is no Py_XCLEAR. Py_CLEAR itself checks its argument for NULL (as Py_XDECREF and Py_XINCREF). And these names looks too cumbersome to me. While the name does suggest the macro will expand to: Py_CLEAR(target); target = value; which isn't quite accurate, it's close enough that people should still be able to understand what the operation does. This is not just inaccurate, this is wrong. Py_REPLACE first assigns new value and then DECREF old value. So it rather can be named as Py_SET_AND_DECREF, but of course this name looks ugly and confusing. ___ 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] Possible major bug with zipimport on Windows in Python 3.3.4
On 2/16/2014 2:52 PM, Serhiy Storchaka wrote: 16.02.14 10:19, Georg Brandl написав(ла): As soon as a patch has been provided and tested, I will make a schedule for 3.3.5 including the fix. Until then, using 3.3.3 is probably the best solution. Then could you please include the fix for #20538 (this bug allows easily crash Python e.g. by special HTTP request or e-mail). And I think it is very important to port the fix for #19619. Simple patch for #17671 fixes other crash (less important, because can be triggered only by programming error). A 3.3.5 should have all the bugfixes committed before the candidate release. -- Terry Jan Reedy ___ 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 3.4: What to do about the Derby patches
16.02.14 20:31, Larry Hastings написав(ла): So here we are in the release candidate period for 3.4, and we still have all these unmerged Derby patches. And it's simply too late in the release cycle to merge them for 3.4.0. Here's how I propose we move forward. Your plan LGTM (except one question below). 4) We accelerate the schedule for 3.4.1 slightly, so we can get these new signatures into the hands of users sooner. Specifically, I propose we ship 3.4.1 two months after 3.4.0. I figure we would release 3.4.1 rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th. How this will affect the schedule for 3.3.x? Will it accelerately switched to security-only fix mode? ___ 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 3.4: What to do about the Derby patches
On 02/16/2014 12:36 PM, Serhiy Storchaka wrote: 16.02.14 20:31, Larry Hastings написав(ла): 4) We accelerate the schedule for 3.4.1 slightly, so we can get these new signatures into the hands of users sooner. Specifically, I propose we ship 3.4.1 two months after 3.4.0. I figure we would release 3.4.1 rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th. How this will affect the schedule for 3.3.x? Will it accelerately switched to security-only fix mode? That would really be a question for Georg Brandl, the 3.3 release manager. However I don't know why 3.4.1 would have any effect on 3.3, regardless of when it was released. //arry/ ___ 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 3.4: What to do about the Derby patches
On Sun, 16 Feb 2014 10:31:21 -0800 Larry Hastings la...@hastings.org wrote: Here's how I propose we move forward. 1) We merge the Derby patch for the builtins module into 3.4, simply because it will demo well. This still brings potential unstability during the rc phase, so I'd prefer this patch to wait for 3.4.1. Quoting Wikipedia: A release candidate (RC) is a beta version with potential to be a final product, which is ready to release unless significant bugs emerge. 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] Possible major bug with zipimport on Windows in Python 3.3.4
Am 16.02.2014 21:14, schrieb Terry Reedy: On 2/16/2014 2:52 PM, Serhiy Storchaka wrote: 16.02.14 10:19, Georg Brandl написав(ла): As soon as a patch has been provided and tested, I will make a schedule for 3.3.5 including the fix. Until then, using 3.3.3 is probably the best solution. Then could you please include the fix for #20538 (this bug allows easily crash Python e.g. by special HTTP request or e-mail). And I think it is very important to port the fix for #19619. Simple patch for #17671 fixes other crash (less important, because can be triggered only by programming error). A 3.3.5 should have all the bugfixes committed before the candidate release. Exactly. If these are all committed by the rc (only #19619 is missing AFAICT), they will go in. The 3.3.5 rc will be released next weekend, Feb 22th, and the final (if nothing else comes up) on Mar 1st. 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] Python 3.4: What to do about the Derby patches
Am 16.02.2014 22:27, schrieb Larry Hastings: On 02/16/2014 12:36 PM, Serhiy Storchaka wrote: 16.02.14 20:31, Larry Hastings написав(ла): 4) We accelerate the schedule for 3.4.1 slightly, so we can get these new signatures into the hands of users sooner. Specifically, I propose we ship 3.4.1 two months after 3.4.0. I figure we would release 3.4.1 rc1 on Sunday May 4th, and 3.4.1 final on Sunday May 18th. How this will affect the schedule for 3.3.x? Will it accelerately switched to security-only fix mode? That would really be a question for Georg Brandl, the 3.3 release manager. However I don't know why 3.4.1 would have any effect on 3.3, regardless of when it was released. There's no effect; the final 3.3.x point release (hopefully 3.3.6) will be released after 3.4.0 final, with the branch going into security maintenance mode afterwards. Currently I'd be fine with doing 3.3.6 in parallel with 3.4.1, but that is not a requirement and I don't want to finalize that schedule yet. 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] Python 3.4: What to do about the Derby patches
Larry Hastings wrote: 3) We hold off on merging the rest of the Derby patches until after 3.4.0 final ships, then we merge them into the 3.4 maintenance branch so they go into 3.4.1. But wouldn't that be introducing a new feature into a maintenance release? (I.e. some functions that didn't have introspectable signatures before would gain them.) -- Greg ___ 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] cpython: Doc: do not rely on checked-out Sphinx toolchain from svn.python.org anymore
In article 3frhkw2rdjz7...@mail.python.org, georg.brandl python-check...@python.org wrote: http://hg.python.org/cpython/rev/eef7899ea7ab changeset: 89212:eef7899ea7ab user:Georg Brandl ge...@python.org date:Sun Feb 16 09:46:36 2014 +0100 summary: Doc: do not rely on checked-out Sphinx toolchain from svn.python.org anymore Nowadays it is likely that people will have Sphinx installed, and if not, they will know how to install it. This also simplifies life a lot for distribution packagers, who typically do not want the doc build process to connect to external web resources. This checkin breaks the OS X installer builds, see for instance: http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/513 I've opened Issue20644 to address updating the OS X installer build process and buildbot to deal with this change. I imagine it also affects the Windows installer build. This change should not be cherry-picked into 3.4.x until these issues are addressed. -- 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] cpython: Doc: do not rely on checked-out Sphinx toolchain from svn.python.org anymore
Am 16.02.2014 23:46, schrieb Ned Deily: In article 3frhkw2rdjz7...@mail.python.org, georg.brandl python-check...@python.org wrote: http://hg.python.org/cpython/rev/eef7899ea7ab changeset: 89212:eef7899ea7ab user:Georg Brandl ge...@python.org date:Sun Feb 16 09:46:36 2014 +0100 summary: Doc: do not rely on checked-out Sphinx toolchain from svn.python.org anymore Nowadays it is likely that people will have Sphinx installed, and if not, they will know how to install it. This also simplifies life a lot for distribution packagers, who typically do not want the doc build process to connect to external web resources. This checkin breaks the OS X installer builds, see for instance: http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/513 I've opened Issue20644 to address updating the OS X installer build process and buildbot to deal with this change. I imagine it also affects the Windows installer build. This change should not be cherry-picked into 3.4.x until these issues are addressed. Thanks, I hope it will be easy to fix. 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] pootle.python.org is down
On 17 Feb 2014 02:20, Georg Brandl g.bra...@gmx.net wrote: Am 16.02.2014 16:32, schrieb Benjamin Peterson: On Sun, Feb 16, 2014, at 06:52 AM, A.M. Kuchling wrote: I came across http://bugs.python.org/issue13663, which is about a pootle.python.org installation. http://pootle.python.org/ currently returns a 500. Are we still using Pootle, or should I just close #13663? (Maybe the installation got broken in the move to OSL and then forgotten?) Per the comments in that bug (esp from Martin), I think we should just remove pootle.python.org for good. For now. We should ideally figure out another way to provide support for docs translations, though. I already have a slot at the language summit to talk about how we manage docs development in general, so if anyone has info on the current status of docs translation efforts, I'd be happy to bring that up as well. Cheers, Nick. 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/ncoghlan%40gmail.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
[Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2. You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes: The title should start with 3.4 cherry-pick: followed by the revision id and a short summary example: 3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix The version should be Python 3.4 The assignee should be larry The priority should be release blocker The comment should *also* contain the revision id (the tracker will turn it into a link) I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here: http://www.midwinter.com/~larry/3.4.merge.status.html The page is marked beta because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked merged on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning. (By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.) Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk. Cheers, //arry/ ___ 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] Add Py_REPLACE and Py_XREPLACE macros
On 17 Feb 2014 06:12, Serhiy Storchaka storch...@gmail.com wrote: 16.02.14 02:05, Nick Coghlan написав(ла): It's also likely than many of these crashes could only be reproduced through incorrect usage of the C API. Rather through queer or malicious usage of Python classes with strange code in __del__. This change doesn't fix any of the known crashers in Lib/test/crashers, though - I applied the patch locally and checked. For example: Py_CLEAR_AND_SET Py_XCLEAR_AND_SET Such that Py_CLEAR and Py_XCLEAR are equivalent to: There is no Py_XCLEAR. Py_CLEAR itself checks its argument for NULL (as Py_XDECREF and Py_XINCREF). And these names looks too cumbersome to me. While the name does suggest the macro will expand to: Py_CLEAR(target); target = value; which isn't quite accurate, it's close enough that people should still be able to understand what the operation does. This is not just inaccurate, this is wrong. Py_REPLACE first assigns new value and then DECREF old value. The point is that people already know what Py_CLEAR does. This operation is like Py_CLEAR (the old reference is only removed *after* the pointer has been updated), except that the value it is being replaced with can be something other than NULL. If the replacement value *is* NULL, then the new operation is *exactly* equivalent to Py_CLEAR. Operations that do related things should ideally have related names. The point of my deliberately erroneous expansion is that it's an error a reader can make while still correctly understanding the *logic* of the code, even though they're missing a subtlety of the mechanics. So it rather can be named as Py_SET_AND_DECREF, but of course this name looks ugly and confusing. An explicit name like Py_SET_AND_DECREF would also be reasonable. It's substantially less confusing than Py_REPLACE, as it is less ambiguous about whether or not the refcount on the new value is adjusted. Cheers, Nick. ___ 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/ncoghlan%40gmail.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] Python 3.4: What to do about the Derby patches
On 17 Feb 2014 08:36, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Larry Hastings wrote: 3) We hold off on merging the rest of the Derby patches until after 3.4.0 final ships, then we merge them into the 3.4 maintenance branch so they go into 3.4.1. But wouldn't that be introducing a new feature into a maintenance release? (I.e. some functions that didn't have introspectable signatures before would gain them.) From a compatibility point of view, 3.4.0 will already force introspection users and tool developers to cope with the fact that some, but not all, builtin and extension types provide valid signature data. Additional clinic conversions that don't alter semantics then just move additional callables into the supports programmatic introspection category. It's certainly in a grey area, but What's in the best interest of end users? pushes me in the direction of counting clinic conversions that don't change semantics as bug fixes - they get improved introspection support sooner, and it shouldn't make life any harder for tool developers because all of the adjustments for 3.4 will be to the associated functional changes in the inspect module. The key thing is to make sure to postpone any changes that impact *semantics* (like adding keyword argument support). Larry's plan sounds OK to me, although at this point I'd be happier leaving even the builtin conversion until 3.4.1 (especially if we decide to publish that not long after PyCon US). Cheers, Nick. -- Greg ___ 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/ncoghlan%40gmail.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] Python 3.4: Cherry-picking into rc2 and final
http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... Paul On 16 February 2014 23:25, Larry Hastings la...@hastings.org wrote: Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2. You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes: The title should start with 3.4 cherry-pick: followed by the revision id and a short summary example: 3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix The version should be Python 3.4 The assignee should be larry The priority should be release blocker The comment should *also* contain the revision id (the tracker will turn it into a link) I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here: http://www.midwinter.com/~larry/3.4.merge.status.html The page is marked beta because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked merged on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning. (By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.) Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk. Cheers, /arry ___ 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/p.f.moore%40gmail.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] Python 3.4: What to do about the Derby patches
Hi, The PEP 436 is still a draft and not mentionned in Python 3.4 changelog. The PEP proposes to add a DSL, not to modify all modules implemented in C. I think that it should be marked as Final and mentionned in the changelog. http://www.python.org/dev/peps/pep-0436/ 2014-02-16 19:31 GMT+01:00 Larry Hastings la...@hastings.org: Here's how I propose we move forward. 1) We merge the Derby patch for the builtins module into 3.4, simply because it will demo well. Where is the issue to implement this feature? Anyway, I expect a huge patch which is non-trivial and so very risky for such a very important module :-/ It's too late IMO. Victor ___ 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 3.4: What to do about the Derby patches
On 02/16/2014 10:31 AM, Larry Hastings wrote: I'm very sorry that many people contributed to the Derby expecting their patches to go in to 3.4. This is my fault, for severely miscalculating how the Derby would play out. And I feel awful about it. Don't worry too much. It was a great effort, and much got done that will be integrated soon. But I'm convinced the best thing for Python is to hold off on merging until after 3.4.0 ships. If 3.4.1 will be released so soon, just hold off on all the Derby changes until then. -- ~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] pootle.python.org is down
FYI, Japanese translation project is now uses Transifex to translate Py3k document. https://www.transifex.com/projects/p/python-33-ja/ http://docs.python.jp/3/ On Mon, Feb 17, 2014 at 8:13 AM, Nick Coghlan ncogh...@gmail.com wrote: On 17 Feb 2014 02:20, Georg Brandl g.bra...@gmx.net wrote: Am 16.02.2014 16:32, schrieb Benjamin Peterson: On Sun, Feb 16, 2014, at 06:52 AM, A.M. Kuchling wrote: I came across http://bugs.python.org/issue13663, which is about a pootle.python.org installation. http://pootle.python.org/ currently returns a 500. Are we still using Pootle, or should I just close #13663? (Maybe the installation got broken in the move to OSL and then forgotten?) Per the comments in that bug (esp from Martin), I think we should just remove pootle.python.org for good. For now. We should ideally figure out another way to provide support for docs translations, though. I already have a slot at the language summit to talk about how we manage docs development in general, so if anyone has info on the current status of docs translation efforts, I'd be happy to bring that up as well. Cheers, Nick. 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/ncoghlan%40gmail.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/songofacandy%40gmail.com -- INADA Naoki songofaca...@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] Python 3.4: Cherry-picking into rc2 and final
For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a. On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.mo...@gmail.com wrote: http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... Paul On 16 February 2014 23:25, Larry Hastings la...@hastings.org wrote: Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2. You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes: The title should start with 3.4 cherry-pick: followed by the revision id and a short summary example: 3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix The version should be Python 3.4 The assignee should be larry The priority should be release blocker The comment should *also* contain the revision id (the tracker will turn it into a link) I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here: http://www.midwinter.com/~larry/3.4.merge.status.html The page is marked beta because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked merged on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning. (By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.) Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk. Cheers, /arry ___ 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/p.f.moore%40gmail.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/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] Python 3.4: Cherry-picking into rc2 and final
http://bugs.python.org/issue20651 filed to track this as larry requested. On Sun, Feb 16, 2014 at 7:09 PM, Gregory P. Smith g...@krypto.org wrote: For 3.4.0rc2 the commit to merge from issue20621 is 52ab9e1ff46a. On Sun, Feb 16, 2014 at 3:45 PM, Paul Moore p.f.mo...@gmail.com wrote: http://bugs.python.org/issue20621 is significant enough to be resulting in a 3.3.5 release - can you make sure the 3.4 fix goes in? I'm not sure how to find the revision number that contains the fix to follow the process you outline above, so I'm just mentioning it here on the issue to make sure it's not missed... Paul On 16 February 2014 23:25, Larry Hastings la...@hastings.org wrote: Right now we're in the release candidate phase of 3.4. 3.4.0 rc1 has been released, and the next release will be rc2. You might think that anything you check in to the default branch in Python trunk will go into 3.4.0 rc2, and after that ships, checkins would go into 3.4.0 final. Ho ho ho! That's not true! Instead, anything checked in to default between my last revision for rc1 (e64ae8b82672) and 3.4.0 final will by default go into 3.4.1. Only fixes that I cherry-pick into my local branch will go into 3.4.0 rc2 and final. And my local branch will remain private until 3.4.0 final ships! If you have a Terribly Important Fix That Must Go Into 3.4.0 rc2 or final, please go to the issue tracker and create a new issue with the following attributes: The title should start with 3.4 cherry-pick: followed by the revision id and a short summary example: 3.4 cherry-pick: b328f8ccbccf __getnewargs__ fix The version should be Python 3.4 The assignee should be larry The priority should be release blocker The comment should *also* contain the revision id (the tracker will turn it into a link) I'm also working on automatically publishing the merged/unmerged revision status to a web page. You can see a mock-up here: http://www.midwinter.com/~larry/3.4.merge.status.html The page is marked beta because it doesn't have real data yet--I'm still experimenting with my automation, so I haven't created the real 3.4 local branch yet. Again, just to be crystal-clear: the revisions marked merged on that page are just experiments, they aren't actually merged for 3.4. Once I'm ready for real merging, I'll remove the beta warning. (By the way: on that page, clicking on a revision takes you to the revision web page. Clicking on the first line of the comment expands it to show the complete comment.) Please use your best judgment before asking that a revision be cherry-picked into 3.4.0. Our goal in the release candidate phase is to stabilize Python, and to do that we must stop changing it. Only important interface changes, new features, or bugfixes should be checked in now, and preferably they should be low-risk. Cheers, /arry ___ 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/p.f.moore%40gmail.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/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
