Re: [Python-Dev] Python 3.4 version in the tracker
On 12.03.2011 17:09, Eric Smith wrote: > On 03/12/2011 10:55 AM, Éric Araujo wrote: >>> I have a deprecation warning that I need to make an error in 3.4. >> >> A neat trick to remember to do those changes is using a test that fails >> if something does not raise a DeprecationWarning if sys.version_info[:2] >> == (3, 3), or an error if sys.version_info[:3] == (3, 4). You write >> those tests once and let “make test” remind you as soon as the Python >> version changes. > > I like the idea, but it seems a little hostile to the person who > actually changes the version number! If it helps to remember these things (usually deprecations) that we've often forgotten in the past, I don't mind being the one to innocently break the buildbots by increasing the version number. cheers, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Using feature branches for local development
I'm experimenting with creating some local branches for things I'd like to work on during the sprints this week, and have a couple of questions about the associated workflow. 1. While the feature branches are active, is it correct that I can't use a bare "hg push" any more, since I don't want to push the feature branches to hg.python.org? Instead, I need to name all the branches I want to push explicitly. 2. Once I'm done with the feature branch, I need to nuke it somehow (e.g. by enabling the mq extension to gain access to "hg strip" command) If those are both accurate, I may actually create a new subclone, leaving the main local repository with only the changes I actually want to push upstream. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, Mar 13, 2011 at 8:25 PM, Nick Coghlan wrote: > 1. While the feature branches are active, is it correct that I can't > use a bare "hg push" any more, since I don't want to push the feature > branches to hg.python.org? Instead, I need to name all the branches I > want to push explicitly. More or less. If you only want to push the default branch, you could put [alias] pdef = push -r default in the .hg/hgrc as an alias. > 2. Once I'm done with the feature branch, I need to nuke it somehow > (e.g. by enabling the mq extension to gain access to "hg strip" > command) You may *want* to do that, but hg branch obsolete-branch; hg commit -m "I'm done" --close should also do the trick of getting it out of the way of most commands. > If those are both accurate, I may actually create a new subclone, > leaving the main local repository with only the changes I actually > want to push upstream. This is also a good way to work for many people, I think. I personally manage my not-ready-for-prime time code with mq, though. This should protect you from pushing code you're not ready to publish. (hg will tell you wideload:test/b 20:54$ hg push pushing to /private/tmp/test/a abort: source has mq patches applied if you try to push with patches applied to the workspace.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, Mar 13, 2011 at 12:25, Nick Coghlan wrote: > I'm experimenting with creating some local branches for things I'd > like to work on during the sprints this week, and have a couple of > questions about the associated workflow. By local branches, do you mean named branches (using the hg branch command to set a branch name), or unnamed extra heads/extra clones? > 1. While the feature branches are active, is it correct that I can't > use a bare "hg push" any more, since I don't want to push the feature > branches to hg.python.org? Instead, I need to name all the branches I > want to push explicitly. The easy solution is to use a local clone and not push from it to hg.p.o at all. hg push does indeed push all branches (named and unnamed) by default. > 2. Once I'm done with the feature branch, I need to nuke it somehow > (e.g. by enabling the mq extension to gain access to "hg strip" > command) You're implying you want to smash the feature branch down to a single patch? In that case, yeah. > If those are both accurate, I may actually create a new subclone, > leaving the main local repository with only the changes I actually > want to push upstream. That's the easy solution. The slightly harder, but more powerful, solution is to learn MQ. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, Mar 13, 2011 at 7:56 AM, Stephen J. Turnbull wrote: >> 2. Once I'm done with the feature branch, I need to nuke it somehow >> (e.g. by enabling the mq extension to gain access to "hg strip" >> command) > > You may *want* to do that, but hg branch obsolete-branch; > hg commit -m "I'm done" --close should also do the trick of getting > it out of the way of most commands. Alas, "hg outgoing" isn't one of those commands. Since I've enabled mq anyway, I may just start learning how to use it :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
On 13 March 2011 03:00, Raymond Hettinger wrote: >> But in Python 3 this solution is no longer available. How bad is that? >> I'm not sure. But I'd like to at least get the issue out in the open. >> > > Python3.2 should be substantially better in this regard. > It no longer wraps key objects around every input. Instead, it > sorts two parallel arrays of pointers. You can thank Daniel > Stutzbach (another Googler I believe) for this effort. For what it's worth: PS D:\Data> D:\Apps\Python27\python.exe -m timeit -s "L = [(1,2), (3,4), (0,5), (9,100), (3,7), (2,8)]" "sorted(L, lambda (p,q),(r,s): cmp(p*s, q*r))" 10 loops, best of 3: 5.19 usec per loop PS D:\Data> D:\Apps\Python27\python.exe -m timeit -s "L = [(1,2), (3,4), (0,5), (9,100), (3,7), (2,8)]" -s "from fractions import Fraction" "sorted(L, key=lambda t: Fraction(*t))" 1 loops, best of 3: 51.6 usec per loop PS D:\Data> D:\Apps\Python27\python.exe -m timeit -s "L = [(1,2), (3,4), (0,5), (9,100), (3,7), (2,8)]" -s "from fcomp import Fcomp" "sorted(L, key=Fcomp)" 10 loops, best of 3: 8.6 usec per loop PS D:\Data> D:\Apps\Python32\python.exe -m timeit -s "L = [(1,2), (3,4), (0,5), (9,100), (3,7), (2,8)]" -s "from fractions import Fraction" "sorted(L, key=lambda t: Fraction(*t))" 1 loops, best of 3: 64.4 usec per loop PS D:\Data> D:\Apps\Python32\python.exe -m timeit -s "L = [(1,2), (3,4), (0,5), (9,100), (3,7), (2,8)]" -s "from fcomp import Fcomp" "sorted(L, key=Fcomp)" 10 loops, best of 3: 8.41 usec per loop This says to me that using Fraction as a key is substantially worse (and worse still in 3.2 over 2.7). Using a custom key is closer to a comparison function (but still 60-70% slower) and is marginally faster in 3.2. Clearly, the nature of the key is critical here, so take this with even more of a pinch of salt than you normally would with a benchmark. None of my real code is affected either way, but it seems to me that the removal of the comparison function option was (sadly) a case of purity being allowed to beat practicality. Luckily, adding it back wouldn't be a backward compatibility issue :-) Whether it's worth doing, I'll leave to those who would be doing the work to judge... Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, Mar 13, 2011 at 13:25, Nick Coghlan wrote: > I'm experimenting with creating some local branches for things I'd > like to work on during the sprints this week, and have a couple of > questions about the associated workflow. > The way to do this, IMHO, is just create a local clone and work on it. Then you can keep checking partial changes in without ever worrying about accidentally modifying the official repo. Especially if some of this work is experimental and bound to eventually be thrown away, I think it's a more flexible way to work than use MQ. One thing to keep in mind though is backup. I may be paranoid, but I just can't do anything of importance on a local machine (especially a laptop) for any prolonged period of time without occasional backups. Thankfully, a Mercurial repo is about the best tool you have for backing things up - just remote clone it to bitbucket, google code or some place of your own and periodically push there. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, Mar 13, 2011 at 8:32 AM, Eli Bendersky wrote: > The way to do this, IMHO, is just create a local clone and work on it. Then > you can keep checking partial changes in without ever worrying about > accidentally modifying the official repo. Especially if some of this work is > experimental and bound to eventually be thrown away, I think it's a more > flexible way to work than use MQ. > > One thing to keep in mind though is backup. I may be paranoid, but I just > can't do anything of importance on a local machine (especially a laptop) for > any prolonged period of time without occasional backups. Thankfully, a > Mercurial repo is about the best tool you have for backing things up - just > remote clone it to bitbucket, google code or some place of your own and > periodically push there. Since I have multiple machines to keep in sync, I'm actually thinking a server side sandbox clone is the way to go. That will solve my local issue as well (since the sandbox clone will be separate from the main clone). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
Am 13.03.11 07:25, schrieb Nick Coghlan: I'm experimenting with creating some local branches for things I'd like to work on during the sprints this week, and have a couple of questions about the associated workflow. 1. While the feature branches are active, is it correct that I can't use a bare "hg push" any more, since I don't want to push the feature branches to hg.python.org? Despite what anybody told so far: yes, you can continue to use a bare "hg push". In the clone, edit .hg/hgrc, and have "default" point to the remote repository you want to push to. As the remote repository, you can use one of those you created with a remote clone. If you want to continue to pull from cpython to merge upstream changes, set up a default-push path in .hg/hgrc. Then pull will get incoming changes cpython, outgoing changes go to the sandbox repository. 2. Once I'm done with the feature branch, I need to nuke it somehow (e.g. by enabling the mq extension to gain access to "hg strip" command) I think this will need reconsidertion. Apparently, the recommendation is that you need to flatten all changes into a single commit when integrating is. The way I would do it is to produce a diff, and apply a patch to cpython. One way of producing the patch is to use "hg outgoing", another is to use a named branch in your clone and do "hg diff default feature". The mercurial-recommended way is that you just push your changes to cpython when done, which puts all your individual commits into Python's history. I tried to find an official statement on which way it should be in the devguide, but couldn't find anything. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
You are not permitted to edit property stage of class issue.Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 2E3A11CD34 for ; Sat, 12 Mar 2011 18:58:26 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id E301AEE981 for ; Sat, 12 Mar 2011 18:58:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1299952705; bh=qYZ+1soa1lYFkl/MBhE0kMaEkm6EP9xi0HD2EZzhmNM=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=wHQXREQx40bwINh4NztNuqvbAdeCrdv15TW2zjpZfVksU2wtp/dnIR2PMJhst3tak Awt/95dyrM5Q/9bbYgphd8Zs0Ldnhr8halDZNoPWv/cFbpDyAn4SUQUNBZzc02MGjC gxzVgik0GgKUPQrnX5YwTnofVxzLkEE2dqzDMP2U= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 12 Mar 2011 18:58:25 +0100 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for ; Sat, 12 Mar 2011 18:58:25 +0100 (CET) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from ) id 1PyT56-0007cT-FG for [email protected]; Sat, 12 Mar 2011 18:58:24 +0100 Date: Sat, 12 Mar 2011 18:58:24 +0100 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue11475] [status=closed; resolution=fixed; stage=committed/rejected] TmV3IGNoYW5nZXNldCA3ZmQwNjc3M2MzYzIgYnkgQmVuamFtaW4gUGV0ZXJzb24gaW4gYnJhbmNo ICczLjEnOgp0cnVuYyAtPiBtYXRoLnRydW5jIChjbG9zZXMgIzExNDc1KQpodHRwOi8vaGcucHl0 aG9uLm9yZy9jcHl0aG9uL3Jldi83ZmQwNjc3M2MzYzIKCgpOZXcgY2hhbmdlc2V0IDBlYjIzZGVk YjAzYyBieSBCZW5qYW1pbiBQZXRlcnNvbiBpbiBicmFuY2ggJzIuNyc6CnRydW5jIC0+IG1hdGgu dHJ1bmMgKGNsb3NlcyAjMTE0NzUpCmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2LzBl YjIzZGVkYjAzYwo= ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
You are not permitted to edit property stage of class issue.Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 075991CE7D for ; Sun, 13 Mar 2011 00:11:29 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id C23D6EEB44 for ; Sun, 13 Mar 2011 00:11:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1299971488; bh=ZO2sKQ6jd1TrEYAI+tiEvF5y9+PgMMuHX2WWQDp0bnw=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=qcbzdeBjE9gfe3Ndft/j0SP7zLwuFGa++K1MsuhJ1Uor8zkuv61hyDeKzW0ZY6OB+ Go+whgYoMvp0qWvxE4kBNMfV5pVIlOLeTH3wcnL3jDmTdIKd60qfFKMdB3LpSzYPo3 fCY2j5P3m3chXfY9YTjJGJbK4ybtI0uC4kpA9xJU= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 13 Mar 2011 00:11:28 +0100 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for ; Sun, 13 Mar 2011 00:11:28 +0100 (CET) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from ) id 1PyXy4-0003JY-Jx for [email protected]; Sun, 13 Mar 2011 00:11:28 +0100 Date: Sun, 13 Mar 2011 00:11:28 +0100 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue11312] [status=closed; resolution=fixed; stage=committed/rejected] TmV3IGNoYW5nZXNldCBjMDE3Njk1YWNmMTkgYnkgQmVuamFtaW4gUGV0ZXJzb24gaW4gYnJhbmNo ICcyLjcnOgpjbGFyaWZ5IGNvbmRpdGlvbiBmb3IgcmVhZGxpbmUgdG8gcmV0dXJuIEVPRiAoY2xv c2VzICMxMTMxMikKaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvYzAxNzY5NWFjZjE5 Cg== ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
You are not permitted to edit property stage of class issue.Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id D03D11CCEF for ; Sun, 13 Mar 2011 00:30:54 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 91C45EEA3B for ; Sun, 13 Mar 2011 00:30:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1299972654; bh=YEfRd87zUD9hUNRPQ0gW/hovinbL3pZoGbabcdfUpGU=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=Lne+0Te3eUe78ACgJ/bd+w5w1kpdpCqG/g9KvpoyrohiMrDY0TU8ejIMhpYO8hx/W OtEH1COtBcujwb6w0O8pGyDLovo8D4+GFKJ+S2ziOn+kYEjyHYfiJZIbEj+BPswhXq f1LkEzapQxWETAOMqoj6xFbZ5S/+9zlTYqgtQSTU= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 13 Mar 2011 00:30:54 +0100 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for ; Sun, 13 Mar 2011 00:30:54 +0100 (CET) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from ) id 1PyYGs-0005xP-GA for [email protected]; Sun, 13 Mar 2011 00:30:54 +0100 Date: Sun, 13 Mar 2011 00:30:54 +0100 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue2771] [status=closed; resolution=fixed; stage=committed/rejected] TmV3IGNoYW5nZXNldCBkMGY5N2QyN2I4ZjggYnkgQW50b2luZSBQaXRyb3UgaW4gYnJhbmNoICdk ZWZhdWx0JzoKY2xvc2VzICMyNzcxCmh0dHA6Ly9oZy5weXRob24ub3JnL3Rlc3QvcmV2L2QwZjk3 ZDI3YjhmOAo= ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
You are not permitted to edit property stage of class issue.Return-Path: X-Original-To: [email protected] Delivered-To: [email protected] Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id E18F41CCEF for ; Sun, 13 Mar 2011 00:31:57 +0100 (CET) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id A71FEEE9D3 for ; Sun, 13 Mar 2011 00:31:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1299972717; bh=Ibp6eWhVeNrklL/k3hji/5Ii1lOezo53S23METjDw1I=; h=Date:Message-Id:Content-Type:MIME-Version: Content-Transfer-Encoding:From:To:Subject; b=SFvsALnuTMjXJDF/BlVNobKujYGwQR3VvGbWp+BoRydAeuxb4zXAnjJI1eZl5owoM /Qj50uWq8D/7SlkGBPGrzYamqa2N4j0xyaWH4UZIhXYFJuO5aywdJY3/sNI3WlGRyC X0/K3wAlalv9IHS1LddFM+0jQau87LgY/CqpA8S8= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 13 Mar 2011 00:31:57 +0100 Received: from dinsdale.python.org (svn.python.org [IPv6:2001:888:2000:d::a4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.python.org (Postfix) with ESMTPS for ; Sun, 13 Mar 2011 00:31:57 +0100 (CET) Received: from localhost ([127.0.0.1] helo=dinsdale.python.org ident=hg) by dinsdale.python.org with esmtp (Exim 4.72) (envelope-from ) id 1PyYHt-000633-JZ for [email protected]; Sun, 13 Mar 2011 00:31:57 +0100 Date: Sun, 13 Mar 2011 00:31:57 +0100 Message-Id: Content-Type: text/plain; charset="utf8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 From: [email protected] To: [email protected] Subject: [issue2771] [status=closed; resolution=fixed; stage=committed/rejected] TmV3IGNoYW5nZXNldCA3N2Q0Nzg2YWFlMjkgYnkgQW50b2luZSBQaXRyb3UgaW4gYnJhbmNoICdk ZWZhdWx0JzoKY2xvc2VzICMyNzcxCmh0dHA6Ly9oZy5weXRob24ub3JnL3Rlc3QvcmV2Lzc3ZDQ3 ODZhYWUyOQo= ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, Mar 13, 2011 at 14:41, Nick Coghlan wrote: > On Sun, Mar 13, 2011 at 8:32 AM, Eli Bendersky wrote: > > The way to do this, IMHO, is just create a local clone and work on it. > Then > > you can keep checking partial changes in without ever worrying about > > accidentally modifying the official repo. Especially if some of this work > is > > experimental and bound to eventually be thrown away, I think it's a more > > flexible way to work than use MQ. > > > > One thing to keep in mind though is backup. I may be paranoid, but I just > > can't do anything of importance on a local machine (especially a laptop) > for > > any prolonged period of time without occasional backups. Thankfully, a > > Mercurial repo is about the best tool you have for backing things up - > just > > remote clone it to bitbucket, google code or some place of your own and > > periodically push there. > > Since I have multiple machines to keep in sync, I'm actually thinking > a server side sandbox clone is the way to go. That will solve my local > issue as well (since the sandbox clone will be separate from the main > clone). > This is precisely what I do, since I routinely commit to personal Mercurial repos from 3 different machines. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, Mar 13, 2011 at 8:47 AM, "Martin v. Löwis" wrote: > Am 13.03.11 07:25, schrieb Nick Coghlan: >> 2. Once I'm done with the feature branch, I need to nuke it somehow >> (e.g. by enabling the mq extension to gain access to "hg strip" >> command) > > I think this will need reconsidertion. Apparently, the recommendation > is that you need to flatten all changes into a single commit when > integrating is. The way I would do it is to produce a diff, and apply > a patch to cpython. One way of producing the patch is to use "hg outgoing", > another is to use a named branch in your clone and do > "hg diff default feature". Yeah, I just created a sandbox/ncoghlan code that I'll use to track all my "in-progress" stuff, then I'll generate a diff to apply to my local clone of the cpython repository. > The mercurial-recommended way is that you just push your changes to cpython > when done, which puts all your individual commits into Python's history. > > I tried to find an official statement on which way it should be in the > devguide, but couldn't find anything. It's definitely the latter, but I don't think it is explicitly documented yet that this applies to all pushes, not just patches from the tracker. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, 13 Mar 2011 09:28:28 -0400 Nick Coghlan wrote: > > > The mercurial-recommended way is that you just push your changes to cpython > > when done, which puts all your individual commits into Python's history. > > > > I tried to find an official statement on which way it should be in the > > devguide, but couldn't find anything. > > It's definitely the latter, but I don't think it is explicitly > documented yet that this applies to all pushes, not just patches from > the tracker. I think we (python-dev) will need to take a decision on this. My personal opinion is that we don't want to see all intermediate commits which led to a patch (or feature) in the main repo. It may also lead to many spurious buildbot builds (some of them probably failing), and many commit notifications on python-checkins: you could see an example of the latter with the distutils2 pushes. The counter-argument is that preserving the development history can make changes more understandable. That's only if the history reflects the logical separation of changes, though. If someone wants to split their work into several changesets, a patch series using mq could also be the recommended way (that's how mercurial-devel works). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 version in the tracker
On 03/13/2011 06:49 AM, Georg Brandl wrote: On 12.03.2011 17:09, Eric Smith wrote: On 03/12/2011 10:55 AM, Éric Araujo wrote: I have a deprecation warning that I need to make an error in 3.4. A neat trick to remember to do those changes is using a test that fails if something does not raise a DeprecationWarning if sys.version_info[:2] == (3, 3), or an error if sys.version_info[:3] == (3, 4). You write those tests once and let “make test” remind you as soon as the Python version changes. I like the idea, but it seems a little hostile to the person who actually changes the version number! If it helps to remember these things (usually deprecations) that we've often forgotten in the past, I don't mind being the one to innocently break the buildbots by increasing the version number. Are you volunteering to change all of the PendingDeprecationWarnings to DeprecationWarnings and DeprecationWarnings to errors of some sort? It might be a big job. I'm just trying to figure out what the mechanics would be. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
2011/3/13 Antoine Pitrou : > On Sun, 13 Mar 2011 09:28:28 -0400 > Nick Coghlan wrote: >> >> > The mercurial-recommended way is that you just push your changes to cpython >> > when done, which puts all your individual commits into Python's history. >> > >> > I tried to find an official statement on which way it should be in the >> > devguide, but couldn't find anything. >> >> It's definitely the latter, but I don't think it is explicitly >> documented yet that this applies to all pushes, not just patches from >> the tracker. > > I think we (python-dev) will need to take a decision on this. > > My personal opinion is that we don't want to see all intermediate > commits which led to a patch (or feature) in the main repo. It may > also lead to many spurious buildbot builds (some of them probably > failing), and many commit notifications on python-checkins: you could > see an example of the latter with the distutils2 pushes. +1 for collapsing commits into logical patches. Little is more annoying than annotating something and finding out the commit message was "oops, fix this thingy..." completely out of context of the larger patch. > > The counter-argument is that preserving the development history can > make changes more understandable. That's only if the history reflects > the logical separation of changes, though. > > If someone wants to split their work into several changesets, a patch > series using mq could also be the recommended way (that's how > mercurial-devel works). -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, Mar 13, 2011 at 9:05 PM, Nick Coghlan wrote: > On Sun, Mar 13, 2011 at 7:56 AM, Stephen J. Turnbull > wrote: >> You may *want* to do that, but hg branch obsolete-branch; >> hg commit -m "I'm done" --close should also do the trick of getting >> it out of the way of most commands. > > Alas, "hg outgoing" isn't one of those commands. missing = hg outgoing -b default That's not quite what you want of course, but it all depends on how averse you are to learning mq. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
On Sun, Mar 13, 2011 at 9:32 PM, Eli Bendersky wrote: > The way to do this, IMHO, is just create a local clone and work on it. Then > you can keep checking partial changes in without ever worrying about > accidentally modifying the official repo. Especially if some of this work is > experimental and bound to eventually be thrown away, I think it's a more > flexible way to work than use MQ. The problem is that you need to be working in a straight line. If there are several related but unordered changes involved, once you've committed to a branch it's rather annoying to reorder things. mq makes such reordering easy in many cases. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using feature branches for local development
tl;dr: +1 for pushing only clean changesets. Le 13/03/2011 14:44, Antoine Pitrou a écrit : > I think we (python-dev) will need to take a decision on this. > > My personal opinion is that we don't want to see all intermediate > commits which led to a patch (or feature) in the main repo. It may > also lead to many spurious buildbot builds (some of them probably > failing), and many commit notifications on python-checkins: you could > see an example of the latter with the distutils2 pushes. > > The counter-argument is that preserving the development history can > make changes more understandable. That's only if the history reflects > the logical separation of changes, though. > > If someone wants to split their work into several changesets, a patch > series using mq could also be the recommended way (that's how > mercurial-devel works). Agreed. +1 on pushing only clean changesets instead of a whole series with different versions and fixes. Most of the time that will be one changeset, and when it makes the changes easier to read, more than one (say for a fix in a docstring and doc file followed by a rewrite of that part of the doc file). I also think that it should be allowed to merge a feature branch (unnamed!) that has taken some time to complete and thus has many changesets (think io-in-c), as long as they are clean too: It will be the same situation as with Subversion, only with nicer merge changesets. On another hand, it can be useful to see the whole life of a patch, but this can be achieved by saving the repo with the intermediate changesets somewhere. Having unclean changesets with dead ends and fixes can have educational value and help break the impression that developers don’t make mistakes, which can prevent people from trying to contributing (for more about that, see The Myth of the Programmer Genius: http://www.youtube.com/watch?v=XeJSXfXep4M). For a previous discussion about flattening a branch into a patch or not, see http://mail.python.org/pipermail/python-ideas/2010-July/007538.html (thread started by Tarek). Finally, I’d say that using named branches or clones or MQ is the choice of the developer; history editing is built-in with MQ, extensions like collapse and histedit can work with branches, hg diff + import can flatten too, so we don’t have to mandate one tool. MQ is very powerful and can be a life-saver, but its conflict handling is not as cool as Mercurial’s, and I’ve had good success in cleaning branches with other tools. Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Submitting changes through Mercurial
I've added a feature in the bug tracker where submitters can post Mercurial repository URLs, and then repeatedly create patches. Roundup will extract the current patch (cpython-default:submitter-default), and attach the patch to the issue (which then allows Rietveld review of the patch). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
On Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum wrote:
> I recently advised a Googler who was sorting a large dataset and
> running out of memory. My analysis of the situation was that he was
> sorting a huge list of short lines of the form "shortstring,integer"
> with a key function that returned a tuple of the form ("shortstring",
> integer).
As Raymond pointed out, a change I made for 3.2 significantly shrinks the
memory footprint of sorting with a key (although it's still more
memory-intensive than sorting with cmp).
He could reduce the memory footprint further by sorting in two passes
instead of using a tuple, leveraging the fact that Python guarantees a
stable sort. In 3.2 or later, this technique will require roughly twice as
much memory as just storing the list:
biglist.sort(key=lambda s: int(s.split(',')[1])) # Sort by the integer
biglist.sort(key=lambda s: s.split(',')[0]) # Sort by the shortstring
I think the use cases are pretty narrow where there's plenty of memory for
storing the list but not enough to store two copies.
--
Daniel Stutzbach
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: bump ast version
On Sun, 13 Mar 2011 01:34:21 +0100 benjamin.peterson wrote: > http://hg.python.org/cpython/rev/52940f7f3726 > changeset: 68416:52940f7f3726 > user:Benjamin Peterson > date:Sat Mar 12 18:35:23 2011 -0600 > summary: > bump ast version > > files: > Python/Python-ast.c > > diff --git a/Python/Python-ast.c b/Python/Python-ast.c > --- a/Python/Python-ast.c > +++ b/Python/Python-ast.c > @@ -2,7 +2,7 @@ > > > /* > - __version__ 68409:c017695acf19. > + __version__ 68410:0daa6ba25d9b. Is the version number necessary? It is local to the repository of the person regenerating the file, and therefore not very reliable (for example, 68410 on hg.python.org points to http://hg.python.org/cpython/rev/f757b3b79c2a). The changeset id should be sufficient. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: bump ast version
2011/3/13 Antoine Pitrou : > On Sun, 13 Mar 2011 01:34:21 +0100 > benjamin.peterson wrote: >> http://hg.python.org/cpython/rev/52940f7f3726 >> changeset: 68416:52940f7f3726 >> user: Benjamin Peterson >> date: Sat Mar 12 18:35:23 2011 -0600 >> summary: >> bump ast version >> >> files: >> Python/Python-ast.c >> >> diff --git a/Python/Python-ast.c b/Python/Python-ast.c >> --- a/Python/Python-ast.c >> +++ b/Python/Python-ast.c >> @@ -2,7 +2,7 @@ >> >> >> /* >> - __version__ 68409:c017695acf19. >> + __version__ 68410:0daa6ba25d9b. > > Is the version number necessary? It is local to the repository of the > person regenerating the file, and therefore not very reliable (for > example, 68410 on hg.python.org points to > http://hg.python.org/cpython/rev/f757b3b79c2a). > > The changeset id should be sufficient. I thought people might be comparing based on version numbers. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: bump ast version
A revision number is, indeed, local to the working repository. A changeset ID, however is global. >From Mercurial's documentation: Revision numbers referring to changesets are very likely to be different in another copy of a repository. Do not use them to talk about changesets with other people. Use the changeset ID instead See: http://mercurial.selenic.com/wiki/RevisionNumber ~/santa On Sun, Mar 13, 2011 at 2:27 PM, Benjamin Peterson wrote: > 2011/3/13 Antoine Pitrou : > > On Sun, 13 Mar 2011 01:34:21 +0100 > > benjamin.peterson wrote: > >> http://hg.python.org/cpython/rev/52940f7f3726 > >> changeset: 68416:52940f7f3726 > >> user:Benjamin Peterson > >> date:Sat Mar 12 18:35:23 2011 -0600 > >> summary: > >> bump ast version > >> > >> files: > >> Python/Python-ast.c > >> > >> diff --git a/Python/Python-ast.c b/Python/Python-ast.c > >> --- a/Python/Python-ast.c > >> +++ b/Python/Python-ast.c > >> @@ -2,7 +2,7 @@ > >> > >> > >> /* > >> - __version__ 68409:c017695acf19. > >> + __version__ 68410:0daa6ba25d9b. > > > > Is the version number necessary? It is local to the repository of the > > person regenerating the file, and therefore not very reliable (for > > example, 68410 on hg.python.org points to > > http://hg.python.org/cpython/rev/f757b3b79c2a). > > > > The changeset id should be sufficient. > > I thought people might be comparing based on version numbers. > > > > -- > Regards, > Benjamin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
On Sat, Mar 12, 2011 at 9:17 PM, Terry Reedy wrote: > But in this case, they are much slower. To be faster, one would need > something like "key=lambda p,q:p*(lcm//q)", where lcm is the least common > multiple of of all the q's (denominators). For the example above, lcm = 700. > But for longer lists, it could be outrageously large. > You can get away with less precision. It's okay if the key function loses some information, as long as it still has enough to distinguish each pair of numbers. In other words, you just need a number that's at least as large as the largest lcm between any pair: max_denominator_sq = max(q for p, q in fraction_list) ** 2 # Strictly larger than the lcm between any pair fraction_list.sort(key=lambda p, q: p*max_denominator_sq//q) Using the above, key is 4 times faster than cmp in Python2.6: stutzbach-glaptop:~$ python2.6 -m timeit -s 'fractions = [(i, j) for i in range(100) for j in range(1, 100)]' 'sorted(fractions, cmp=lambda (p,q),(r,s): cmp(p*s, q*r))' 10 loops, best of 3: 23.3 msec per loop stutzbach-glaptop:~$ python2.6 -m timeit -s 'fractions = [(i, j) for i in range(100) for j in range(1, 100)]' 'max_denominator_sq = max(q for p, q in fractions)**2' (1,2), (3,4), (0,5), (9,100), (3,7), (2,8)'sorted(fractions, key=lambda t: t[0]*max_denominator_sq//t[1])' 100 loops, best of 3: 5.52 msec per loop with a further speed improvement in 3.2: stutzbach-glaptop:~$ ~/python/cpython-3.2/python -m timeit -s 'fractions = [(i, j) for i in range(100) for j in range(1, 100)]' 'max_denominator_sq = max(q for p, q in fractions)**2' 'sorted(fractions, key=lambda t: t[0]*max_denominator_sq//t[1])' 100 loops, best of 3: 4.89 msec per loop and more speed improvements with my experimental changes targeting 3.3 (not yet in the bug tracker): :-) stutzbach-glaptop:~$ ~/python/cpython/python -m timeit -s 'fractions = [(i, j) for i in range(100) for j in range(1, 100)]' 'max_denominator_sq = max(q for p, q in fractions)**2' 'sorted(fractions, key=lambda t: t[0]*max_denominator_sq//t[1])' 100 loops, best of 3: 3.73 msec per loop -- Daniel Stutzbach ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python3 regret about deleting list.sort(cmp=...)
On 3/13/2011 2:05 PM, Daniel Stutzbach wrote: On Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum mailto:[email protected]>> wrote: I recently advised a Googler who was sorting a large dataset and running out of memory. My analysis of the situation was that he was sorting a huge list of short lines of the form "shortstring,integer" with a key function that returned a tuple of the form ("shortstring", integer). As Raymond pointed out, a change I made for 3.2 significantly shrinks the memory footprint of sorting with a key (although it's still more memory-intensive than sorting with cmp). He could reduce the memory footprint further by sorting in two passes instead of using a tuple, leveraging the fact that Python guarantees a stable sort. In 3.2 or later, this technique will require roughly twice as much memory as just storing the list: biglist.sort(key=lambda s: int(s.split(',')[1])) # Sort by the integer biglist.sort(key=lambda s: s.split(',')[0]) # Sort by the shortstring I think the use cases are pretty narrow where there's plenty of memory for storing the list but not enough to store two copies. Here are two variations on the idea of two pass sorting, both of which only sort ints for duplicate shortstrings and neither of which use key=. 1. If duplication of shortstrings is (known to be) sparse, sort the lines as they are, then scan to detect runs (slices) of duplicate shortstrings and sort and replace those. (If sort had start and stop index keywords, this could be done in place.) 2. If duplication of shortstrings is (known to be) heavy, read the dataset into a shortstring-list_of_ints dict rathar than a list. Sort the keys in a separate (much shorted) list and sort each value (list of ints) separately. For some post-sort usages, this would be more useful than a flat sorted list. A third idea is to presort the dataset into chunks (a-m, n-z) or however appropriate, perhaps as it is gathered; sort each separately; and then concatenate. This will handle cases where even the flat list is too big for memory. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pydoc for named tuples is missing methods
[I mentioned this to Raymond Hettinger after his PyCon talk, and I
promised a bug and hopefully a patch. I don't see an obvious solution,
though, so I'll ask here first.]
Because named tuple prefixes a single underscore to its added method
names (_asdict, _replace, and _make), those methods' docstrings are
omitted from pydoc:
>>> Point=collections.namedtuple('Point', 'x y')
>>> help(Point)
Help on class Point in module __main__:
[output omitted; it excludes _asdict, _replace, and _make]
pydoc's rules for name inclusion are in pydoc.visiblename():
* If the name is in the hidden list, omit it
* If the name looks like a __special_method__, include it
* If the there is an "all" specified, then include it if it appears in all
* Otherwise, include it if it doesn't begin with an underscore
There doesn't seem to be an obvious way to get around these rules for
named tuples... am I overlooking something?
Thanks.
--
Tim Lesher
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
2011/3/13 Tim Lesher :
> [I mentioned this to Raymond Hettinger after his PyCon talk, and I
> promised a bug and hopefully a patch. I don't see an obvious solution,
> though, so I'll ask here first.]
>
> Because named tuple prefixes a single underscore to its added method
> names (_asdict, _replace, and _make), those methods' docstrings are
> omitted from pydoc:
>
Point=collections.namedtuple('Point', 'x y')
help(Point)
> Help on class Point in module __main__:
> [output omitted; it excludes _asdict, _replace, and _make]
>
> pydoc's rules for name inclusion are in pydoc.visiblename():
>
> * If the name is in the hidden list, omit it
> * If the name looks like a __special_method__, include it
> * If the there is an "all" specified, then include it if it appears in all
> * Otherwise, include it if it doesn't begin with an underscore
>
> There doesn't seem to be an obvious way to get around these rules for
> named tuples... am I overlooking something?
No, probably we should add some sort of __yes_i_am_public__ override
attribute that pydoc looks for. It's such a pity that those methods
have to have underscores...
--
Regards,
Benjamin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On Mon, Mar 14, 2011 at 12:41 PM, Tim Lesher wrote:
> [I mentioned this to Raymond Hettinger after his PyCon talk, and I
> promised a bug and hopefully a patch. I don't see an obvious solution,
> though, so I'll ask here first.]
>
> Because named tuple prefixes a single underscore to its added method
> names (_asdict, _replace, and _make), those methods' docstrings are
> omitted from pydoc:
>
Point=collections.namedtuple('Point', 'x y')
help(Point)
> Help on class Point in module __main__:
> [output omitted; it excludes _asdict, _replace, and _make]
>
> pydoc's rules for name inclusion are in pydoc.visiblename():
>
> * If the name is in the hidden list, omit it
> * If the name looks like a __special_method__, include it
> * If the there is an "all" specified, then include it if it appears in all
> * Otherwise, include it if it doesn't begin with an underscore
>
> There doesn't seem to be an obvious way to get around these rules for
> named tuples... am I overlooking something?
Works for me. Python 3.2 on 32bit Linux.
cheers
James
--
-- James Mills
--
-- "Problems are solved by method"
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
On Mon, Mar 14, 2011 at 12:57 PM, James Mills wrote: >> [output omitted; it excludes _asdict, _replace, and _make] Sorry I missed this bit :) > Works for me. Python 3.2 on 32bit Linux. Scrap that :) cheers James -- -- James Mills -- -- "Problems are solved by method" ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
Addendum: this looks related to bug 1189811. http://bugs.python.org/issue1189811 That issue seems to hinge on the definition of "private". -- Tim Lesher ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pydoc for named tuples is missing methods
Tim Lesher wrote: Because named tuple prefixes a single underscore to its added method names (_asdict, _replace, and _make), those methods' docstrings are omitted from pydoc: IMO these should be called __asdict__, __replace__ and __make__. Users are perfectly entitled to make up their own single-underscore names, so using a single underscore is not sufficient to prevent name collisions. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
