Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 01:07, schrieb Larry Hastings: On 02/18/2014 03:54 PM, Victor Stinner wrote: 2014-02-19 0:46 GMT+01:00 Larry Hastings la...@hastings.org: Is there *any* reason to make this branch public before 3.4.0 final? I'm a little bit worried by the fact that buildbots will not test it. fact? http://docs.python.org/devguide/buildbots.html#custom-builders And this works without a public repo on hg.python.org how? 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: Cherry-picking into rc2 and final
Am 19.02.2014 03:46, schrieb Guido van Rossum: I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...) Pushes to hg.python.org repos are fully reversible. If that is Larry's concern he can even put it on bitbucket, where only he can push by default. 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: Cherry-picking into rc2 and final
Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. 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] Preview of 3.4 rc2 (so far) is up
On 19 Feb 2014 14:05, Larry Hastings la...@hastings.org wrote: The URL has changed slightly. Please go here: http://midwinter.com/~larry/3.4.status/ You'll notice two things: a merge.status.html file, which shows you the list of revisions that I've cherry-picked after rc1. a tarball containing the resulting source tree. As I cherry-pick more revisions, I'll add new tarballs and update the merge status. For the record, I've passed over only two requested cherry-pick revisions so far: http://bugs.python.org/issue20646 select and kqueue round the timeout aways from zero http://bugs.python.org/issue20679 improve Enum subclass behavior I haven't rejected them, I just want more review. If you'd like to see these changes get cherry-picked for 3.4.0 rc2 (and final) please review them or convince someone else to contribute a review. Only thirty cherry-picked revisions so far. Gosh, you're making my life easy, guys, Larry, you announced your preferred release candidate management process too late to rely on it entirely - you should still audit all the deferred blockers and release blockers flagged for 3.4, and ask for an update on their status, with a pointer to the archived python-dev post describing how to request that the change be included in 3.4.0 rather than being left to 3.4.1. I know at least I have been setting those on the assumption things would work the same as they have in previous releases, since you hadn't said anything prior to rc1 about doing things differently. Regards, Nick. /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/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] Preview of 3.4 rc2 (so far) is up
Am 19.02.2014 11:04, schrieb Nick Coghlan: On 19 Feb 2014 14:05, Larry Hastings la...@hastings.org mailto:la...@hastings.org wrote: The URL has changed slightly. Please go here: http://midwinter.com/~larry/3.4.status/ You'll notice two things: a merge.status.html file, which shows you the list of revisions that I've cherry-picked after rc1. a tarball containing the resulting source tree. As I cherry-pick more revisions, I'll add new tarballs and update the merge status. For the record, I've passed over only two requested cherry-pick revisions so far: http://bugs.python.org/issue20646 select and kqueue round the timeout aways from zero http://bugs.python.org/issue20679 improve Enum subclass behavior I haven't rejected them, I just want more review. If you'd like to see these changes get cherry-picked for 3.4.0 rc2 (and final) please review them or convince someone else to contribute a review. Only thirty cherry-picked revisions so far. Gosh, you're making my life easy, guys, Larry, you announced your preferred release candidate management process too late to rely on it entirely - you should still audit all the deferred blockers and release blockers flagged for 3.4, and ask for an update on their status, with a pointer to the archived python-dev post describing how to request that the change be included in 3.4.0 rather than being left to 3.4.1. I know at least I have been setting those on the assumption things would work the same as they have in previous releases, since you hadn't said anything prior to rc1 about doing things differently. To be fair this isn't really different from 3.3.0, just that I didn't require a specific format for issues and went through all changes manually. 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 niggle: None 1 raises TypeError
On Tue, Feb 18, 2014 at 5:10 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Sorry if this has already been suggested, but why not introduce a new singleton to make the database people happier if not happy? To avoid confusion call it dbnull? A reasonable compromise or complete cobblers? :) I think this is possible already, for the database people. The problem is that it will not pass the is None test, which at the very least is not backwards compatible with how they have used it before. ___ 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] Preview of 3.4 rc2 (so far) is up
On 19 February 2014 20:09, Georg Brandl g.bra...@gmx.net wrote: Am 19.02.2014 11:04, schrieb Nick Coghlan: On 19 Feb 2014 14:05, Larry Hastings la...@hastings.org mailto:la...@hastings.org wrote: The URL has changed slightly. Please go here: http://midwinter.com/~larry/3.4.status/ You'll notice two things: a merge.status.html file, which shows you the list of revisions that I've cherry-picked after rc1. a tarball containing the resulting source tree. As I cherry-pick more revisions, I'll add new tarballs and update the merge status. For the record, I've passed over only two requested cherry-pick revisions so far: http://bugs.python.org/issue20646 select and kqueue round the timeout aways from zero http://bugs.python.org/issue20679 improve Enum subclass behavior I haven't rejected them, I just want more review. If you'd like to see these changes get cherry-picked for 3.4.0 rc2 (and final) please review them or convince someone else to contribute a review. Only thirty cherry-picked revisions so far. Gosh, you're making my life easy, guys, Larry, you announced your preferred release candidate management process too late to rely on it entirely - you should still audit all the deferred blockers and release blockers flagged for 3.4, and ask for an update on their status, with a pointer to the archived python-dev post describing how to request that the change be included in 3.4.0 rather than being left to 3.4.1. I know at least I have been setting those on the assumption things would work the same as they have in previous releases, since you hadn't said anything prior to rc1 about doing things differently. To be fair this isn't really different from 3.3.0, just that I didn't require a specific format for issues and went through all changes manually. That's the part that worries me - if Larry is assuming the post to python-dev is enough to get people to change their behaviour at short notice, I'm concerned things that should be release blockers won't end up blocking doing so. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
On Tue, 18 Feb 2014 18:54:23 -0500 Barry Warsaw ba...@python.org wrote: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. Agreed too. Python isn't developed in private. 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] Python 3.4: Cherry-picking into rc2 and final
On Tue, 18 Feb 2014 18:46:16 -0800 Guido van Rossum gu...@python.org wrote: I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...) I don't think I understand the concern. Why is this different from any other mistake someone may make when pushing code? Also rebase is only really ok on private repos, as soon as something is published you should use merge. 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] Preview of 3.4 rc2 (so far) is up
On Tue, 18 Feb 2014 20:03:31 -0800 Larry Hastings la...@hastings.org wrote: Only thirty cherry-picked revisions so far. Gosh, you're making my life easy, guys, That's a large number of cherry-picked revisions. How many are actually release-critical? 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] Python 3.4: Cherry-picking into rc2 and final
On 02/19/2014 01:20 PM, Antoine Pitrou wrote: On Tue, 18 Feb 2014 18:46:16 -0800 Guido van Rossum gu...@python.org wrote: I do think there's one legitimate concern -- someone might pull a diff from Larry's branch and then accidentally push it back to the public repo, and then Larry would be in trouble if he was planning to rebase that diff. (The joys of DVCS -- we never had this problem in the cvs or svn days...) I don't think I understand the concern. Why is this different from any other mistake someone may make when pushing code? Also rebase is only really ok on private repos, as soon as something is published you should use merge. If the branch were private, pushing to it would not count as publishing, but would still provide the benefit of having a redundant server-side backup of the data. Being able to rebase without fuss is a possible legitimate reason to keep the branch private, which Guido provided in response to Matthias's question: sorry, but this is so wrong. Is there *any* reason why to keep this branch private? ___ 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
On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net wrote: Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Give Larry some trust and freedom to do things in the way that makes him comfortable. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote: That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Give Larry some trust and freedom to do things in the way that makes him comfortable. I totally agree that Larry should be given fairly wide discretion. He's also feeling out his first big release and deserves some slack. However, I think Matthias wants read access to the release repo because he's *also* cherry picking patches into Ubuntu's archive. We're already seeing some problems, which we want to investigate, and Matthias has also performed archive-wide test rebuilds to find Python 3.4 incompatibilities in 3rd party libraries, most of which we'd like to fix (e.g. main packages, if its not possible to get to everything in universe). Matthias just switched the default for Ubuntu 14.04 to Python 3.4 by default, so this is a great test bed to find problems. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Wed, Feb 19, 2014 at 4:13 AM, Antoine Pitrou solip...@pitrou.net wrote: Agreed too. Python isn't developed in private. That's a ridiculous accusation, bordering on malicious. Larry isn't developing Python in private. He is simply working on something that he'll release when he feels comfortable releasing it. I don't think I understand the concern. Why is this different from any other mistake someone may make when pushing code? Maybe because 1000s of people are apparently ready to micro-manage and criticize Larry's work and waiting for him to screw up? Why are you trying to tell Larry how to use his tools? Larry *volunteered* to be the release manager and got widespread support when he did. If you don't trust him, go fucking fork the release yourself. Also rebase is only really ok on private repos, as soon as something is published you should use merge. And that's exactly why Larry is holding off pushing. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
On Wed, Feb 19, 2014 at 8:16 AM, Barry Warsaw ba...@python.org wrote: On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote: That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Give Larry some trust and freedom to do things in the way that makes him comfortable. I totally agree that Larry should be given fairly wide discretion. He's also feeling out his first big release and deserves some slack. Thanks for the support! However, I think Matthias wants read access to the release repo because he's *also* cherry picking patches into Ubuntu's archive. We're already seeing some problems, which we want to investigate, and Matthias has also performed archive-wide test rebuilds to find Python 3.4 incompatibilities in 3rd party libraries, most of which we'd like to fix (e.g. main packages, if its not possible to get to everything in universe). Again, this is what RC2 is for (and RC1, for that matter; apart from 20+ asyncio patches there really isn't much of a difference between RC1 and RC2). Larry may legitimately feel uncomfortable with what he's got on his local drive and prefer to tweak some things before telling people go ahead test with this -- the difference is that if he was working on new *code*, he could just not commit his work-in-progress, but since here he is assembling the final sequence of *revisions*, he prefers just not to push. (Georg alluded to the fact that you can undo changes in a public repo after they've been pushed, but I suspect he's referring to hg backout, which creates extra revisions, rather than a remote version of hg strip, which would go against the philosophy of DVCS. Either way, Larry's use of Hg is a totally legitimate workflow.) Matthias just switched the default for Ubuntu 14.04 to Python 3.4 by default, so this is a great test bed to find problems. And that's great, of course. But what is really gained by giving Larry trouble over a few days' worth of delay, at most? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final
Am 19.02.2014 16:50, schrieb Guido van Rossum: On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Ned told me just a few days ago that he does regular pre-tag builds of the OSX installers, and as for the Debian/Ubuntu side Barry can say more. The thing with the RCs is that as long as you add patches during the RC phase (which is more or less unavoidable if the schedule is to be kept), the state of the release branch can only profit from more eyes. Give Larry some trust and freedom to do things in the way that makes him comfortable. I have no doubts that Larry will make 3.4 the best Python yet :) So far he has discussed most of his procedures with us, so I don't see a reason not to weigh in here. 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: Cherry-picking into rc2 and final
Am 19.02.2014 19:00, schrieb Georg Brandl: Give Larry some trust and freedom to do things in the way that makes him comfortable. I have no doubts that Larry will make 3.4 the best Python yet :) So far he has discussed most of his procedures with us, so I don't see a reason not to weigh in here. NB, us being the previous release managers. 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: Cherry-picking into rc2 and final
Am 19.02.2014 19:00, schrieb Georg Brandl: Am 19.02.2014 16:50, schrieb Guido van Rossum: On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Ned told me just a few days ago that he does regular pre-tag builds of the OSX installers, and as for the Debian/Ubuntu side Barry can say more. The thing with the RCs is that as long as you add patches during the RC phase (which is more or less unavoidable if the schedule is to be kept), the state of the release branch can only profit from more eyes. There's even some helpful people on #python-dev (like Arfrever from Gentoo) who frequently do post-push reviews, catching embarrassing bugs before they can sneak their way into a release (thank you Arfrever!). OK, that's my reasoning, I'm going to fucking shut up 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
Re: [Python-Dev] python 3 niggle: None 1 raises TypeError
On 2/19/2014 2:53 AM, Lennart Regebro wrote: On Tue, Feb 18, 2014 at 5:10 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Sorry if this has already been suggested, but why not introduce a new singleton to make the database people happier if not happy? To avoid confusion call it dbnull? A reasonable compromise or complete cobblers? :) I think this is possible already, for the database people. The problem is that it will not pass the is None test, which at the very least is not backwards compatible with how they have used it before. The new singleton will be called something else, likely with Null in the name, so that's what I'll call it here... Null. So when switching from None to Null, you must also switch from is None to is Null. Of course it is not backwards compatible... but once all the database related None usage is switched to Null usage it should work the same as before, but with proper (for some database's definition of proper) semantics. ___ 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
On 20 Feb 2014 04:18, Georg Brandl g.bra...@gmx.net wrote: Am 19.02.2014 19:00, schrieb Georg Brandl: Am 19.02.2014 16:50, schrieb Guido van Rossum: On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl g.bra...@gmx.net mailto:g.bra...@gmx.net wrote: Am 19.02.2014 00:54, schrieb Barry Warsaw: On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote: Am 17.02.2014 00:25, schrieb Larry Hastings: And my local branch will remain private until 3.4.0 final ships! sorry, but this is so wrong. Is there *any* reason why to keep this branch private? IMO, no. read-only for !larry sure, but not private. I emphatically agree. There is no need at all for secrecy, or paranoia. And it is very understandable that vendors (or even just our binary building experts) want to make as many tests with what will be RC2 and then final as they can, to catch possible issues before release. That's why it's RC2 and not 3.4final, right? Once Larry says it's baked, everyone *will* have a chance to test it. What value is a preview of the preview really going to add? Ned told me just a few days ago that he does regular pre-tag builds of the OSX installers, and as for the Debian/Ubuntu side Barry can say more. The thing with the RCs is that as long as you add patches during the RC phase (which is more or less unavoidable if the schedule is to be kept), the state of the release branch can only profit from more eyes. There's even some helpful people on #python-dev (like Arfrever from Gentoo) who frequently do post-push reviews, catching embarrassing bugs before they can sneak their way into a release (thank you Arfrever!). OK, that's my reasoning, I'm going to fucking shut up now. I suspect everyone is also highly aware of the fact that there are some ambitious changes in 3.4, the release of rc1 is bringing the usual wave of additional third party testing that has picked up some interesting regressions and usability issues (e.g. the Alembic test suite found a fun one in the inspect module, while the pip installation doesn't currently play nice with UAC on Windows), and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. That brings with it a strong desire to parallelise things as much as possible, and read only access to the upcoming release helps greatly in knowing which regressions have already been addressed, allowing third party testers to more easily focus on any remaining issues. A user beware, this may be rebased without warning clone would be fine for that purpose, and I suspect in most cases just running rc2 - final with such a clone available (preserving Larry's current workflow until rc2) would be sufficient to address most concerns. Regards, 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] PEPs don't redirect on python.org
Apologies if this is misdirected! I notice the switch to the new python.org web site has happened; but now PEPs are simply 404: http://www.python.org/dev/peps/pep-0008/ However, trimming the URL offers a redirect: http://www.python.org/dev/peps/ - http://legacy.python.org/dev/peps/ from which the content can be found. Can a blanket redirect rule be put in that makes all the PEPs at least go to /dev/peps/ ? ChrisA ___ 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] PEPs don't redirect on python.org
On Thu, Feb 20, 2014 at 10:25 AM, Chris Angelico ros...@gmail.com wrote: I notice the switch to the new python.org web site has happened; but now PEPs are simply 404: http://www.python.org/dev/peps/pep-0008/ However, trimming the URL offers a redirect: http://www.python.org/dev/peps/ - http://legacy.python.org/dev/peps/ Oh! Must have been a transitional period. The PEPs now redirect too. Thanks, whoever did that! Makes the linking much easier. :) ChrisA ___ 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] Preview of 3.4 rc2 (so far) is up
On 02/19/2014 02:04 AM, Nick Coghlan wrote: On 19 Feb 2014 14:05, Larry Hastings la...@hastings.org mailto:la...@hastings.org wrote: The URL has changed slightly. Please go here: http://midwinter.com/~larry/3.4.status/ http://midwinter.com/%7Elarry/3.4.status/ You'll notice two things: a merge.status.html file, which shows you the list of revisions that I've cherry-picked after rc1. a tarball containing the resulting source tree. As I cherry-pick more revisions, I'll add new tarballs and update the merge status. For the record, I've passed over only two requested cherry-pick revisions so far: http://bugs.python.org/issue20646 select and kqueue round the timeout aways from zero http://bugs.python.org/issue20679 improve Enum subclass behavior I haven't rejected them, I just want more review. If you'd like to see these changes get cherry-picked for 3.4.0 rc2 (and final) please review them or convince someone else to contribute a review. Only thirty cherry-picked revisions so far. Gosh, you're making my life easy, guys, Larry, you announced your preferred release candidate management process too late to rely on it entirely - you should still audit all the deferred blockers and release blockers flagged for 3.4, and ask for an update on their status, with a pointer to the archived python-dev post describing how to request that the change be included in 3.4.0 rather than being left to 3.4.1. I know at least I have been setting those on the assumption things would work the same as they have in previous releases, since you hadn't said anything prior to rc1 about doing things differently. The release is still about a month away. And yes I still plan to go through the release blockers. //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] Preview of 3.4 rc2 (so far) is up
On 02/19/2014 07:20 AM, Yury Selivanov wrote: About 21 of those are related to asyncio. On 2/19/2014, 7:42 AM, Antoine Pitrou wrote: On Tue, 18 Feb 2014 20:03:31 -0800 Larry Hastings la...@hastings.org wrote: Only thirty cherry-picked revisions so far. Gosh, you're making my life easy, guys, That's a large number of cherry-picked revisions. How many are actually release-critical? Regards Antoine. Yes, I'm allowing in basically all the asyncio changes, because a) there's no installed base, and b) Guido is himself very heavily involved in those changes. It's my opinion that asyncio is going to get a lot of scrutiny after 3.4.0 ships, so even though it's marked provisional it's important to get it right. And I don't have enough domain knowledge to be able to pick and choose their changes. So I'm relying on Victor / Guido / Yury, merging all their changes, and hoping for the best. I really am hoping it'll settle down soon, though, //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] Preview of 3.4 rc2 (so far) is up
On Wed, Feb 19, 2014 at 4:42 PM, Larry Hastings la...@hastings.org wrote: Yes, I'm allowing in basically all the asyncio changes, because a) there's no installed base, and b) Guido is himself very heavily involved in those changes. It's my opinion that asyncio is going to get a lot of scrutiny after 3.4.0 ships, so even though it's marked provisional it's important to get it right. And I don't have enough domain knowledge to be able to pick and choose their changes. So I'm relying on Victor / Guido / Yury, merging all their changes, and hoping for the best. I really am hoping it'll settle down soon, though, I am actively clamping down on these now. Yuri's and Victor's youthful enthusiasm is adorable. :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preview of 3.4 rc2 (so far) is up
On 20 February 2014 10:31, Larry Hastings la...@hastings.org wrote: On 02/19/2014 02:04 AM, Nick Coghlan wrote: The release is still about a month away. And yes I still plan to go through the release blockers. Thanks. I confess I had missed that rc2 - final was already 3 weeks rather than the 2 weeks between rc1 and rc2, so my mental timeline was off. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Nick Coghlan writes: I suspect everyone is also highly aware of the fact that there are some ambitious changes in 3.4, Which is an argument for longer beta and RC periods than usual, or maybe some of the ambition should have been restrained. It's not necessarily a reason why more eyes help (see below). the release of rc1 is bringing the usual wave of additional third party testing that has picked up some interesting regressions and usability issues (e.g. the Alembic test suite found a fun one in the inspect module, while the pip installation doesn't currently play nice with UAC on Windows), and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. OK, but that means we're screwed regardless. We've decided to release what we've got on a specific timeline, and a few extra days of testing is going to make a marginal difference on average. Remember that under time pressure in bugfixing, the average programmer introduces a new bug that gets through to a product every ten lines. OK, so we're[1] 100X better than average, and I suppose for some subset 1000X better. Still that means several new bugs, and some of them may be doozies. That brings with it a strong desire to parallelise things as much as possible, and read only access to the upcoming release helps greatly in knowing which regressions have already been addressed, allowing third party testers to more easily focus on any remaining issues. Sure, but it *doesn't* help in knowing which ones are *correctly* addressed. These *are* ambitious changes; some of the remaining bugs may be very deep. The obvious fixes may do more harm than good. Ie, more eyes is (a) mostly a fallacy (as Heinlein put it, the wisdom of a group is less than or equal to the maximum of the wisdom of the members) and (b) in any case the more eyes effect is diluted if people are deliberately looking at different parts of the code. A user beware, this may be rebased without warning clone would be fine for that purpose, and I suspect in most cases just running rc2 - final with such a clone available (preserving Larry's current workflow until rc2) would be sufficient to address most concerns. Larry's already providing tarballs as I understand it. The argument that a read-only, no cherrypicking by committers repo is nothing but a better tarball is valid, but as I say, AFAICS the expected gain is pretty marginal. The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process? Footnotes: [1] FVO we not containing me. You'll notice I'm not submitting patches.wink/ ___ 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] A misredirected ticket link in hg.python.org/cpython
Go to any commit link in hg.python.org/cpython, for example http://hg.python.org/cpython/rev/d11ca14c9a61. You have this commit message: Issue #6815: os.path.expandvars() now supports non-ASCII Unicode environment variables names and values. [#6815] The [#6815] link is going to http://bugs.python.org/6815. If you follow that link, it redirects to http://legacy.python.org/sf/ and you get message: You did not provide a report number. The link should be http://bugs.python.org/issue6815. Cheers, Vajrasky Kok ___ 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
On Feb 20, 2014, at 10:24 AM, Stephen J. Turnbull wrote: But should Ubuntu desires be distorting a volunteer RE's process? Ubuntu 14.04 final freeze is April 10[1], so I think that's the drop dead date for getting 3.4 final into Ubuntu 14.04. Matthias may correct me, but I think if we can hit that date (well, maybe a day or two early to be safe) we're good. Missing that date probably isn't catastrophic, especially if there are few to no changes between the last Python 3.4 rc before our final freeze, and Python 3.4 final. What it means is that 14.04 won't ship with the final Python 3.4 and we'll have to do a stable release update after 14.04 to catch up to the Python 3.4 final release. It does mean that many Ubuntu users won't see it until 14.04.1, whenever that is, if at all. But if the only difference is a version string and sys.version_info, then I don't think that's so bad. And ultimately we'll have to do that anyway to get the LTS users Python 3.4.1, 3.4.2, and so on. Two notes: Matthias just enabled Python 3.4 as the default Python 3, and there's no going back. Also, we have aligned the Python release schedules with external schedules before, most notably Apple a couple of times. I think it's reasonable to do so *if* we can do it without sacrificing the quality of Python 3.4's final release. Cheers, -Barry [1] https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule ___ 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
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote: The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process? When talk of slipping the final date again was discussed, Guido basically said no. -- ~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] Python 3.4: Cherry-picking into rc2 and final
On 20 Feb 2014 12:26, Ethan Furman et...@stoneleaf.us wrote: On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote: The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process? When talk of slipping the final date again was discussed, Guido basically said no. Guido said no more to the additional Argument Clinic related changes, rather than to an extra rc in general. Note that I made my comment before Larry pointed out the existing schedule was a week longer than I thought, and Barry clarified that there *is* still room for a third rc if Larry decides that would be appropriate. Cheers, Nick. -- ~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/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 niggle: None 1 raises TypeError
On 20/02/14 08:23, Glenn Linderman wrote: Of course it is not backwards compatible... but once all the database related None usage is switched to Null usage it should work the same as before, My problem with this is that there is no clear distinction between database-related None usage and None usage in general. Data retrieved from a database is often passed to other code that has nothing to do with databases, and data received from other code is inserted into databases. Somewhere in between someone is going to have to be careful to translate back and forth between Nones and Nulls. This is a recipe for chaos. -- 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] Python 3.4: Cherry-picking into rc2 and final
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote: Nick Coghlan writes: A user beware, this may be rebased without warning clone would be fine for that purpose, and I suspect in most cases just running rc2 - final with such a clone available (preserving Larry's current workflow until rc2) would be sufficient to address most concerns. Larry's already providing tarballs as I understand it. Yep. Well, just tarball so far ;-) As for a user beware clone: I worry about providing anything that looks/tastes/smells like a repo. Someone could still inadvertently push those revisions back to trunk, and then we'd have a real mess on our hands. Publishing tarballs drops the possibility down to about zero. The conflict here is not Larry's process, it's the decision to make an ambitious release on a short time schedule. I sympathize with Ubuntu to some extent -- they have a business to run, after all. But should Ubuntu desires be distorting a volunteer RE's process? Was Larry told that commercial interests should be respected in designing his process? I haven't seen anything that makes me think we're in trouble. Every release has its bumps; that's what the rc period is for. I remind you we're still a month away. I grant you asyncio is still evolving surprisingly rapidly for an rc. But it doesn't have an installed base yet, and it's provisional anyway, so it's not making me anxious. Worst case, we issue a 3.4.1 on a very accelerated schedule. But it doesn't seem like it'll be necessary. //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: Cherry-picking into rc2 and final
Larry Hastings writes: Someone could still inadvertently push those revisions back to trunk, and then we'd have a real mess on our hands. Publishing tarballs drops the possibility down to about zero. Note: I see no reason for you to change your process for the 3.4.0 release. I just want to record my comments in this thread for future reference. I don't think any of the above is true. First, although possibility of inadvertant push as written is obviously correct, I don't think the implication that the *probability* of an *inadvertant* push is any higher is correct (somebody else -- Antoine? Guido? -- already pointed this out). The reasoning is that if somebody clones from a mirror of your release branch, they will have to make a deliberate decision to push to trunk, or a deliberate decision to merge or cherrypick from your branch into a branch destined for trunk, to cause a problem. That's actually safer than if they apply a patch from the tracker by hand, since in the case of a patch there will be no metadata to indicate that the conflict was caused by concurrent cherrypicks, and if they're sufficiently incautious, the actual change data may be different. That is messy. Second, what real mess? VCS means never having to say 'Oh, shit!' If such a thing happens, you just take your branch, do an ours merge with trunk obsoleting the trunk, and then cherrypick everything appropriate from obs-trunk. Tedious, yes. Somewhat error-prone, I suppose. Keep the buildbots very busy for a while, for sure. Real mess? IMHO, no. The fact that the repair procedure uses only proper merges (vs. rebase) means that rebase confusion can't propagate silently, nor can committed changes (in anybody's branch) be inadvertantly lost. (There are better strategies than the above, which I'll be happy to discuss if and when necessary. And for tedium reduction, there are features like git's filter-branch, which a Mercurial dev assures me can be done with hg too.) Third, tarballs don't drop the possibility to zero. We know that patch reviewers have those patches in local workspaces. In some cases you can diff a file from the tarball and get the patch you want (mostly, as mentioned above) and apply that to your feature branch. In the case of asyncio, some such path to a duplicate cherrypick seems quite probable (compared with near zero, anyway). I haven't seen anything that makes me think we're in trouble. Your evaluation is plenty good enough for me. But the actual information that your assessment is based on is almost private to you, and that's the reason other folks want access to a repo. By almost private I mean that the manipulation of revision information that DVCSes make so convenient is unavailable to them. ___ 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 niggle: None 1 raises TypeError
Greg Ewing writes: Data retrieved from a database is often passed to other code that has nothing to do with databases, and data received from other code is inserted into databases. Somewhere in between someone is going to have to be careful to translate back and forth between Nones and Nulls. Sure. The suggestion is to assign responsibility for such careful translation to implementers of the DB API. This is a recipe for chaos. If it is, then chaos is already upon us because you can't be careful even if you want to. I don't know if fixing it is worth the work and confusion involved in the fixing process, but fixing it will conserve (and maybe reduce) chaos, not create it. ___ 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] A misredirected ticket link in hg.python.org/cpython
In article CAB+fVUUJgf9gtf_uXk+3sndyp2r++=ELss1iv+So=cuwzje...@mail.gmail.com, Vajrasky Kok sky@speaklikeaking.com wrote: Go to any commit link in hg.python.org/cpython, for example http://hg.python.org/cpython/rev/d11ca14c9a61. You have this commit message: Issue #6815: os.path.expandvars() now supports non-ASCII Unicode environment variables names and values. [#6815] The [#6815] link is going to http://bugs.python.org/6815. If you follow that link, it redirects to http://legacy.python.org/sf/ and you get message: You did not provide a report number. The link should be http://bugs.python.org/issue6815. Thanks! I've reported the problem to Noah on the infrastructure team. -- 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] Python 3.4: What to do about the Derby patches
On 20 February 2014 16:42, Ronald Oussoren ronaldousso...@mac.com wrote: On 17 Feb 2014, at 00:43, Nick Coghlan ncogh...@gmail.com wrote: 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). But there is a semantic change: some functions without a signature in 3.4.0 would have a signature in 3.4.1. That's unlikely to affect user code much because AFAIK signatures aren't used a lot yet, but it is a semantic change non the less :-) Heh, you must have managed to miss all the Argument Clinic debates - semantics there is shorthand for the semantics of the call :) It turns out there are some current C signatures where we either need to slightly change the semantics of the API or else add new features to the inspect module before we can represent them properly at the Python layer. So, for the life of Python 3.4, those are off limits for conversion, and we'll sort them out as part of PEP 457 for 3.5. However, there are plenty of others where the signature *can* be adequately represented in 3.4, they just aren't (yet). So the approach Larry has taken is to declare that could expose valid signature data, but doesn't counts as a bug fix for Python 3.4 maintenance release purposes. We'll make sure the porting section of the What's New guide addresses that explicitly for the benefit of anyone porting introspection tools to Python 3.4 (having all of the argument introspection in the inspect module be based on inspect.signature and various enhancements to inspect.signature itself has significantly increased the number of callables that now support introspection). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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 20 Feb 2014, at 08:09, Nick Coghlan ncogh...@gmail.com wrote: On 20 February 2014 16:42, Ronald Oussoren ronaldousso...@mac.com wrote: On 17 Feb 2014, at 00:43, Nick Coghlan ncogh...@gmail.com wrote: 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). But there is a semantic change: some functions without a signature in 3.4.0 would have a signature in 3.4.1. That's unlikely to affect user code much because AFAIK signatures aren't used a lot yet, but it is a semantic change non the less :-) Heh, you must have managed to miss all the Argument Clinic debates - semantics there is shorthand for the semantics of the call :) I skipped most of that discussion, due to the sheer volume and limited time to add something meaningful to that discussion. It turns out there are some current C signatures where we either need to slightly change the semantics of the API or else add new features to the inspect module before we can represent them properly at the Python layer. So, for the life of Python 3.4, those are off limits for conversion, and we'll sort them out as part of PEP 457 for 3.5. That much I noticed, and IIRC it was noticed fairly early on in Argument Clinic’s history that there are C functions that have an API that cannot easily be represented in a pure Python function (other than using ‘*args, **kw’ and manually parsing the argument list). I totally agree that changing the signature of functions should wait for 3.5, but that’s the easy bit. However, there are plenty of others where the signature *can* be adequately represented in 3.4, they just aren't (yet). So the approach Larry has taken is to declare that could expose valid signature data, but doesn't counts as a bug fix for Python 3.4 maintenance release purposes. We'll make sure the porting section of the What's New guide addresses that explicitly for the benefit of anyone porting introspection tools to Python 3.4 (having all of the argument introspection in the inspect module be based on inspect.signature and various enhancements to inspect.signature itself has significantly increased the number of callables that now support introspection). I can live with that, but don’t really agree that exposing new signature data is a bug fix. But maybe I’m just too conservative :-) To end on a positive not, I do like signature objects, and have added support for them to PyObjC to enrich its introspection capabilities. Ronald Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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, at 00:43, Nick Coghlan ncogh...@gmail.com wrote: 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). But there is a semantic change: some functions without a signature in 3.4.0 would have a signature in 3.4.1. That’s unlikely to affect user code much because AFAIK signatures aren’t used a lot yet, but it is a semantic change non the less :-) Ronald ___ 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
