Re: [Python-Dev] Hg: inter-branch workflow
On Wed, Mar 16, 2011 at 10:14 PM, R. David Murray rdmur...@bitdance.comwrote: On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea j...@jcea.es wrote: On 17/03/11 04:41, R. David Murray wrote: Dealing with a null merge when someone else has committed between the time I started the merge dance (I always pull just before I start that) and the time I push is not that hard either. It pretty much amounts to having to do an additional set of merges. (In my case I do a strip and restart my merge dance, but I'm not sure I should recommend that since altering history is considered dangerous :). Could you possibly describe your current approach, marking it with a huge NOT SAFE; AT YOUR OWN RISK banner?. I wonders how other people manage this. I too do a pull before doing the merge, but I don't push each merge separatelly but I do the all the merges locally and then do an unique push. Than can take some time, moreover if I run the complete testsuite in all changed branches. Resolving a +1 head here is tricky, if I *WANT* the other developer to manage her own merging by herself. As it should. Yes, running the entire test suite puts rather a delay into the process. Generally what I do is run the full test suite in the first branch I'm patching, and then only run the specific test suite in the other branches during the merge. This is a bit suboptimal since default will have more code and more tests for that code than the source branch, but I figure the buildbots will yell if something was missed. On the other hand, when we aren't in sprint-commit-frenzy, I may run the full test suite on default before doing the push. OK, so BIG DISCLAIMER: TRY THIS AT YOUR OWN RISK :) My setup is using the share extension. This means I have one repository with multiple checkout directories. I also have one pristine clone of cpython in case I screw up and need to recreate my share setup. The share setup looks like this: hg clone cpython p33 hg share p33 p32 hg share p33 p31 hg share p33 p27 cd p33; hg up default cd ../p32; hg up 3.2 cd ../p31; hg up 3.1 cd ../p27; hg up 2.7 And then I build python in each branch checkout. With luck I only have to do this once (in practice I've had to do it twice so far, but I'm not really expecting to have to do it again, now that I've learned how things work). My working process is to cd into the checkout for the branch I'm patching first (usually 3.1), and do an hg pull followed by an hg up. (It's important the this be two separate commands rather than an hg pull -u because this is a shared setup: pull -u won't update the local working copy if there are no changesets pulled, while hg up updates it unconditionally.) I then apply the patch, and do whatever testing and fixing and NEWS and ACK entries I need, including running the full tests suite. When I'm satisfied, I start the merge dance: do hg pull; hg up (I could use hg pull -u here since I know I haven't done a pull in some other checkout). Then I: hg diff temp.patch hg pull hg up hg ci cd ../p32 hg up hg merge 3.1 [run tests applicable to the patch] hg ci cd ../p33 hg up hg merge 3.2 [run tests applicable to the patch] (if needed: cd ../p27 hg up patch -p1 ../p31/temp.patch [fix and test] [if there were a bunch of changes, hg diff temp.patch] hg ci ) hg pull why do you use hg diff and patch above rather than hg export and hg import? (not implying one is better than the other, learning here...) -gps If this pull shows no changesets, I do an hg push. The fun part comes if there are changesets. At this point there are two options: go through each of the branches doing an up/merge/ci, and then pull/push. Or, what I actually do: hg log hg strip the changeset id of my first checkin Then I start from the top of the section above, but starting by reapplying my temp.patch. There's one other detail, though: because I'm using share, the checkouts lose their parent id when I do the strip. So in each checkout I also need to do 'hg debugsetparent branch' before doing the hg up. Clearly, this procedure is not for everyone, and I may decide it is not for me by and by. But it has worked well so far during the sprints. There's also some room for automation here. I think part of the reason I like it is that it is fairly close to the workflow I had for svn, except the merges go in the opposite direction and they go a *lot* faster. 2.7, though, is more of a pain than with svn because I have to use patch instead of getting the nice merge markers that svnmerge gave me. And I prefer to do all the merges and then push (rather than push-per-merge like Ezio) because I have all the way until that final push to realize I've made a mistake. Which reminds me: I said I'd hit a race twice during the sprints, but that isn't true. It was only once. The other time I used strip, it was because I
[Python-Dev] buildbot error when pushing to 2.5 branch?
When pushed a change to 2.5 branch, I got an error, which I think has to do with buildbot not available for 2.5 codeline. It asked me to notify the tracker and here it is. remote: state = method(*args, **kw) remote: File /data/buildbot/master/master.cfg, line 87, in perspective_addChange remote: changedict['category'] = branch_to_category[changedict['branch']] remote: exceptions.KeyError: '2.5' remote: ] remote: sent email to roundup at rep...@bugs.python.org -- pushing to ssh://h...@hg.python.org/cpython searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 4 changesets with 2 changes to 1 files remote: change(s) NOT sent, something went wrong: remote: [Failure instance: Traceback from remote host -- Traceback (most recent call last): remote: File /usr/lib/python2.6/dist-packages/twisted/spread/banana.py, line 153, in gotItem remote: self.callExpressionReceived(item) remote: File /usr/lib/python2.6/dist-packages/twisted/spread/banana.py, line 116, in callExpressionReceived remote: self.expressionReceived(obj) remote: File /usr/lib/python2.6/dist-packages/twisted/spread/pb.py, line 514, in expressionReceived remote: method(*sexp[1:]) remote: File /usr/lib/python2.6/dist-packages/twisted/spread/pb.py, line 826, in proto_message remote: self._recvMessage(self.localObjectForID, requestID, objectID, message, answerRequired, netArgs, netKw) remote: --- exception caught here --- remote: File /usr/lib/python2.6/dist-packages/twisted/spread/pb.py, line 840, in _recvMessage remote: netResult = object.remoteMessageReceived(self, message, netArgs, netKw) remote: File /usr/lib/python2.6/dist-packages/twisted/spread/pb.py, line 225, in perspectiveMessageReceived remote: state = method(*args, **kw) remote: File /data/buildbot/master/master.cfg, line 87, in perspective_addChange remote: changedict['category'] = branch_to_category[changedict['branch']] remote: exceptions.KeyError: '2.5' remote: ] remote: sent email to roundup at rep...@bugs.python.org remote: notified python-check...@python.org of incoming changeset e9724d7abbc2 remote: notified python-check...@python.org of incoming changeset 8cdb95cf096e remote: notified python-check...@python.org of incoming changeset 6cd7de9deb1a remote: notified python-check...@python.org of incoming changeset 1148131b1099 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On 3/16/2011 11:58 PM, Jesus Cea wrote: I agree that half the changesets are merges now. Which has basically stopped me from reviewing changes. I can't quickly tell the real changes from the noise of merges. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
Am 17.03.2011 06:14, schrieb R. David Murray: On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea j...@jcea.es wrote: On 17/03/11 04:41, R. David Murray wrote: Dealing with a null merge when someone else has committed between the time I started the merge dance (I always pull just before I start that) and the time I push is not that hard either. It pretty much amounts to having to do an additional set of merges. (In my case I do a strip and restart my merge dance, but I'm not sure I should recommend that since altering history is considered dangerous :). Could you possibly describe your current approach, marking it with a huge NOT SAFE; AT YOUR OWN RISK banner?. I wonders how other people manage this. I too do a pull before doing the merge, but I don't push each merge separatelly but I do the all the merges locally and then do an unique push. Than can take some time, moreover if I run the complete testsuite in all changed branches. Resolving a +1 head here is tricky, if I *WANT* the other developer to manage her own merging by herself. As it should. Yes, running the entire test suite puts rather a delay into the process. Generally what I do is run the full test suite in the first branch I'm patching, and then only run the specific test suite in the other branches during the merge. This is a bit suboptimal since default will have more code and more tests for that code than the source branch, but I figure the buildbots will yell if something was missed. On the other hand, when we aren't in sprint-commit-frenzy, I may run the full test suite on default before doing the push. OK, so BIG DISCLAIMER: TRY THIS AT YOUR OWN RISK :) My setup is using the share extension. This means I have one repository with multiple checkout directories. I also have one pristine clone of cpython in case I screw up and need to recreate my share setup. The share setup looks like this: hg clone cpython p33 hg share p33 p32 hg share p33 p31 hg share p33 p27 cd p33; hg up default cd ../p32; hg up 3.2 cd ../p31; hg up 3.1 cd ../p27; hg up 2.7 And then I build python in each branch checkout. With luck I only have to do this once (in practice I've had to do it twice so far, but I'm not really expecting to have to do it again, now that I've learned how things work). My working process is to cd into the checkout for the branch I'm patching first (usually 3.1), and do an hg pull followed by an hg up. (It's important the this be two separate commands rather than an hg pull -u because this is a shared setup: pull -u won't update the local working copy if there are no changesets pulled, while hg up updates it unconditionally.) I then apply the patch, and do whatever testing and fixing and NEWS and ACK entries I need, including running the full tests suite. When I'm satisfied, I start the merge dance: do hg pull; hg up (I could use hg pull -u here since I know I haven't done a pull in some other checkout). Then I: hg diff temp.patch hg pull hg up hg ci cd ../p32 hg up hg merge 3.1 [run tests applicable to the patch] hg ci cd ../p33 hg up hg merge 3.2 [run tests applicable to the patch] (if needed: cd ../p27 hg up patch -p1 ../p31/temp.patch [fix and test] [if there were a bunch of changes, hg diff temp.patch] hg ci ) hg pull If this pull shows no changesets, I do an hg push. The fun part comes if there are changesets. At this point there are two options: go through each of the branches doing an up/merge/ci, and then pull/push. Or, what I actually do: hg log hg strip the changeset id of my first checkin Uh... wouldn't using the rebase extension make this much easier? Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
Am 17.03.2011 09:57, schrieb Eric Smith: On 3/16/2011 11:58 PM, Jesus Cea wrote: I agree that half the changesets are merges now. Which has basically stopped me from reviewing changes. I can't quickly tell the real changes from the noise of merges. Even though every merge changeset mail has merge in its subject? Also, we don't really have more revisions than before: for every merge now we typically had a svnmerge then. (Or not, in which case a bugfix wasn't applied to a branch just because it would have been a bother.) Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On 3/17/2011 6:28 AM, Georg Brandl wrote: Am 17.03.2011 09:57, schrieb Eric Smith: On 3/16/2011 11:58 PM, Jesus Cea wrote: I agree that half the changesets are merges now. Which has basically stopped me from reviewing changes. I can't quickly tell the real changes from the noise of merges. Even though every merge changeset mail has merge in its subject? Also, we don't really have more revisions than before: for every merge now we typically had a svnmerge then. (Or not, in which case a bugfix wasn't applied to a branch just because it would have been a bother.) Maybe it's just the overall volume of the commits during the sprints. Plus, I've always thought it would be a good way to sneak malicious code in by labeling it as an svnmerge or now hg merge, so I've tried to review everything. I find myself slipping behind, and I'm not happy with it. I'm just being cranky, and hg is a convenient target. Just ignore me. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, Mar 17, 2011 at 6:28 AM, Georg Brandl g.bra...@gmx.net wrote: Am 17.03.2011 09:57, schrieb Eric Smith: On 3/16/2011 11:58 PM, Jesus Cea wrote: I agree that half the changesets are merges now. Which has basically stopped me from reviewing changes. I can't quickly tell the real changes from the noise of merges. Even though every merge changeset mail has merge in its subject? I just set up a mail rule to further split up python-checkins email so that they all get tagged with python-checkins-all, while only those that aren't merges get tagged with python-checkins. That should make the latter far less noisy than it has been. Also, we don't really have more revisions than before: for every merge now we typically had a svnmerge then. (Or not, in which case a bugfix wasn't applied to a branch just because it would have been a bother.) I think it has been exacerbated by the flurry of activity from the sprints. It should be less noticeable once things settle down. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, Mar 17, 2011 at 6:26 AM, Georg Brandl g.bra...@gmx.net wrote: Uh... wouldn't using the rebase extension make this much easier? Perhaps, but I/we haven't figured out how to get rebasing to do anything useful. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Generating patch files
Le 16/03/2011 18:49, Martin v. Löwis a écrit : Having the revision of cpython to compare against is the difficult part; how about: 'max( ancestors(default) and not outgoing() )' ? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 06:14, R. David Murray wrote: The fun part comes if there are changesets. At this point there are two options: go through each of the branches doing an up/merge/ci, and then pull/push. Or, what I actually do: hg log hg strip the changeset id of my first checkin Then I start from the top of the section above, but starting by reapplying my temp.patch. There's one other detail, though: because I'm using share, the checkouts lose their parent id when I do the strip. So in each checkout I also need to do 'hg debugsetparent branch' before doing the hg up. Clearly, this procedure is not for everyone Clearly not :). So you do a hg strip and start over again. The problem with this is that your patch will be applied on top of the incoming changeset, and your merge will merge that patch too, if the original pusher haven't done it yet. Tonight I was thinking about doing a merge inside the branch, to solve the +1 branch. Something like transforming: branch 3.2 -My patchincoming patch--- branch 3.x -- to +--+ | | | v branch 3.2 -My patchincoming patch---merge--- | V branch 3.x merge So I merge my patch to the other branches, preserving history and keeping only a single head in the 3.2 branch, that the other developer must merge to 3.x. The bad thing about this is that the new head (the merge) will be assigned to me, but the developer that must merge that head to 3.x is the other guy. The other committer could merge her changeset to 3.x and, if my merge between the two heads is not trivial, she must notice it and do a second merge. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYIAJplgi5GaxT1NAQJ+XAP+On4tEhylQ7gxtTsfnBNKVG4sLwR697cw GneD9Mi79cEGN5ANjkfflhUkd9kwrPgpkPjzLOXUHU1t7w5ozrWYkRpPHRM44rPA 7VL/Mm6/OMhYehnebwiCriEu6CcUBUFAQMC8BfOdaUb3EQsGFqhZkH9sHepOg+MQ ggSv5OGblic= =h7q8 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 13:35, Jesus Cea wrote: Tonight I was thinking about doing a merge inside the branch, to solve the +1 branch. Something like transforming: Another thing I was thinking about tonight was... dropping the +1 head banning. Embrace it. Embrace the mercurial way completely. Each developer is responsible of merging HIS heads. If somebody forgets, nothing wrong will happens. And no patch is left behind, because you can see unmerged patches with hg heads, and bug their owners. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYIBiplgi5GaxT1NAQLVhQP7Bidj3q+e3LqSWHFR3mcDON1HatygPniQ e1Y0bNdeUlk3V0sNG9LQcCNIsd475UrwOJOGTvbaLOP4zaXUrNX9x9cIbhOsD9NA nF8rwDQGucTRHEC8TonG/rGwuOcnFR704ttHU6z0+P/+3lA7/xpl3KL7bK9L/3dS g3ZZ6LTN8Z8= =kfVk -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Solaris family and 64 bits compiling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/11/10 13:19, Jesus Cea wrote: Would be acceptable to change something like: add_library_path(/usr/local/lib) to something similar to: if (platform.uname()==SunOS) and (platform.architecture()[0]==64bits) : add_library_path(/usr/local/lib/64) else : add_library_path(/usr/local/lib) python-dev would consider that change OK?. Resurrecting an old thread. I think that, under SunOS and 64 bits, python should install the lib directory under /usr/local/lib/64, following the convention in the platform. In fact, under OpenIndiana 147, I see this: - -bash-4.0$ type python python is /usr/bin/python - -bash-4.0$ ldd /usr/bin/python libpython2.6.so.1.0 = /usr/lib/libpython2.6.so.1.0 libc.so.1 = /usr/lib/libc.so.1 libdl.so.1 =/lib/libdl.so.1 libm.so.2 = /lib/libm.so.2 - -bash-4.0$ file /usr/bin/python /usr/bin/python:ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available - -bash-4.0$ ls -lA /usr/lib/|grep python lrwxrwxrwx 1 root root 19 Oct 1 10:55 libpython2.6.so - libpython2.6.so.1.0 - -rwxr-xr-x 1 root bin 1788896 Oct 1 10:55 libpython2.6.so.1.0 lrwxrwxrwx 1 root root 22 Oct 1 10:55 libpython2.6_db.so - libpython2.6_db.so.1.0 - -rwxr-xr-x 1 root bin 10372 Oct 1 10:55 libpython2.6_db.so.1.0 drwxr-xr-x 25 root bin 432 Oct 1 10:55 python2.6 - -bash-4.0$ ls -lA /usr/lib/64/|grep python lrwxrwxrwx 1 root root 19 Oct 1 10:55 libpython2.6.so - libpython2.6.so.1.0 - -rwxr-xr-x 1 root bin 2217504 Oct 1 10:55 libpython2.6.so.1.0 lrwxrwxrwx 1 root root 22 Oct 1 10:55 libpython2.6_db.so - libpython2.6_db.so.1.0 - -rwxr-xr-x 1 root bin 13336 Oct 1 10:55 libpython2.6_db.so.1.0 - -bash-4.0$ file /usr/lib/64/libpython2.6.so.1.0 /usr/lib/64/libpython2.6.so.1.0:ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE2 SSE CMOV], dynamically linked, not stripped, no debugging information available - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYIGSJlgi5GaxT1NAQIrGAP/fBcLKIdFN+O8jNArCs01m30pQC5rNAhp hs1mTqlllpGkSQLDeQvcN/ctwFpR8a+mlC4yCFwYFB8CpB9TjilIKRn0RlerfOlw U0OuhezPTGc75NY95a+x8iZG4FQYytMkv7ClPmyDjG/g68CTS/zArRoKGRA7trZk +WbsLPK4lhg= =ScvG -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, Mar 17, 2011 at 07:41, Jesus Cea j...@jcea.es wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 13:35, Jesus Cea wrote: Tonight I was thinking about doing a merge inside the branch, to solve the +1 branch. Something like transforming: Another thing I was thinking about tonight was... dropping the +1 head banning. Embrace it. Embrace the mercurial way completely. Each developer is responsible of merging HIS heads. If somebody forgets, nothing wrong will happens. And no patch is left behind, because you can see unmerged patches with hg heads, and bug their owners. That just makes more work. 1. I, being new to hg, might not realize my error and just think I'm done. I move on with life. 2. Someone has to notice the additional head then contact me. 3. Now I have to go back and figure out not only what I did wrong, but what I have to do to correct it. In the end, yes, it's my problem, but just because you can shoot yourself in the foot doesn't mean we need to let people do it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, 17 Mar 2011 11:26:13 +0100, Georg Brandl g.bra...@gmx.net wrote: Am 17.03.2011 06:14, schrieb R. David Murray: The fun part comes if there are changesets. At this point there are two options: go through each of the branches doing an up/merge/ci, and then pull/push. Or, what I actually do: hg log hg strip the changeset id of my first checkin Uh... wouldn't using the rebase extension make this much easier? As far as I can tell, rebase and share don't mix, because rebase refers to the branch of the working directory. I need to rebase all branches at once. (That is, I've got a repo with changes on multiple branches, and I want to rebase the entire repo...shelve all my changes since the last pull from cpython, do the pull, and then reapply *all* my changes, on all branches.) I tried hg pull --rebase, and that was when I had to rebuild my share setup, because I have no idea what it did, and it didn't look good. I can't remember *what* didn't look good, though, so perhaps I should try it again. It would be great if rebase did work with share, that would make a push race basically a non-issue for me. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 14:10, Brian Curtin wrote: On Thu, Mar 17, 2011 at 07:41, Jesus Cea j...@jcea.es mailto:j...@jcea.es wrote: [..] Each developer is responsible of merging HIS heads. If somebody forgets, nothing wrong will happens. And no patch is left behind, because you can see unmerged patches with hg heads, and bug their owners. That just makes more work. 1. I, being new to hg, might not realize my error and just think I'm done. I move on with life. 2. Someone has to notice the additional head then contact me. 3. Now I have to go back and figure out not only what I did wrong, but what I have to do to correct it. But thinking that you are done is already a problem now, and everybody must deal with your unmerged head doing whatever trick to keep your head apart and don't merge it automatically. That is burdensome and error prone. I would guess that most people would merge your head themselves, just for convenience. And that would not be your plan if, for instance, your patch is being tested/half done/whatever. Allowing multiple heads, your patch is still there, but nobody suffers for it. If fact, if you don't care, your patch will sit out of the tip line and will be not actually integrated in the tip code. So you must merge it, but nobody has to pay any price just because you forgot :). - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYIMk5lgi5GaxT1NAQJPaAP/fJv2IKHQycxyfg4xkZaqQe/VbxrpfAeV l4Q6nQKYXKCFyTGrlh0Hx6Kb8lkdR+H1KOGWQ7tZVDITLvnK4YBYXj6Be4Uoddn8 H/zsJYAHz1rGKmkq1erY5+ejZpQ2BhUnPqz20yomACG/hUCXH+KI7kf5yqZ27fTx 5c/all+SNNg= =XNMs -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Wed, 16 Mar 2011 23:21:37 -0700, Gregory P. Smith g...@krypto.org wrote: why do you use hg diff and patch above rather than hg export and hg import? (not implying one is better than the other, learning here...) We're all learning, even the ones who have used Mercurial before (which isn't me). I have been avoiding hg import because my understanding is that it defaults to commit, and I don't see that it has any advantage over patch itself. If export preserves the commit message (I haven't tried export, didn't even know it existed), then that could indeed be a better way to go for this particular scenario. I'll have to check that out. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, 17 Mar 2011 09:24:26 -0400 R. David Murray rdmur...@bitdance.com wrote: It would be great if rebase did work with share, that would make a push race basically a non-issue for me. rebase as well as strip destroy some history, meaning some of your shared clones may end up having their working copy based on a non-existent changeset. I'm not sure why rebase would be worse that strip in that regard, though. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, 17 Mar 2011 13:35:50 +0100, Jesus Cea j...@jcea.es wrote: On 17/03/11 06:14, R. David Murray wrote: Clearly, this procedure is not for everyone Clearly not :). So you do a hg strip and start over again. The problem with this is that your patch will be applied on top of the incoming changeset, and your merge will merge that patch too, if the original pusher haven't done it yet. Not if the cpython repo is in a fully merged stated. And if it isn't, I will wait until it is. (The update notifications on the IRC channel help with monitoring this.) Tonight I was thinking about doing a merge inside the branch, to solve the +1 branch. Something like transforming: branch 3.2 -My patchincoming patch--- branch 3.x -- to +--+ | | | v branch 3.2 -My patchincoming patch---merge--- | V branch 3.x merge So I merge my patch to the other branches, preserving history and keeping only a single head in the 3.2 branch, that the other developer must merge to 3.x. I cannot at the moment wrap my head around this, and I really have no desire to do so. I will keep things as simple as I can for myself, even if that means I do a little more work (redoing my merge dance on a push race) or have to wait until the repo is sane again. (Or, perhaps, make the repo sane, if the committer who left it in a weird state doesn't seem to be fixing it; and *then* apply my patch.) If you leave an unmerged changeset in 3.2, I would consider that to be leaving the repo in a weird state. I want to see something like this after I do a pull and before I do a push: hg branches default68637:2b3fb2398f45 2.768630:d8eaeee1c063 3.268636:21fe6d393242 (inactive) 3.168625:d9c3cfd36b58 (inactive) 2.668377:d6626c9fc28d (inactive) 2.568263:7790ad8332ba (inactive) That is, only 2.7 and 3.2 are active. This is what is recommended by the devguide, to my understanding. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, Mar 17, 2011 at 9:33 AM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 17 Mar 2011 09:24:26 -0400 R. David Murray rdmur...@bitdance.com wrote: It would be great if rebase did work with share, that would make a push race basically a non-issue for me. rebase as well as strip destroy some history, meaning some of your shared clones may end up having their working copy based on a non-existent changeset. I'm not sure why rebase would be worse that strip in that regard, though. I don't think anyone has laid out why destroying history is considered bad by some, so I thought I'd plug this post: http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html Essentially, lets say I have a handful of commits hacking on C code. While I wrote them, someone changed a C API from under me and pushed their change. However, in the last change, I remove my dependence on this API. I pull, rebase, rebuild and test. The tests pass in the latest commit, so I push. But now if someone tries to go back to those intermediate commits (say, searching for the introduction of a regression), they will find a broken build. It boils down to when you alter history, at each altered commit you have some source tree state for which you haven't built and run the tests. On the flipside, in the case of a single commit, it's easy to pull, rebase, rerun tests, and then push. Running the tests takes a while so you open yourself to another push race, though. 98% of the time, if you don't actually have merge conflicts, applying your change over someone else's without testing will work, so I feel like rebasing a single commit without testing is no big deal. On the off chance that it breaks, the buildbots will find out. Just don't rebase a whole feature branch of commits, leave the final merge in. Reid ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Exercise crashers to ensure they are still covering known error cases
On Thu, 17 Mar 2011 01:01:30 +0100 nick.coghlan python-check...@python.org wrote: http://hg.python.org/cpython/rev/e3fb176add41 changeset: 68628:e3fb176add41 user:Nick Coghlan ncogh...@gmail.com date:Wed Mar 16 19:52:14 2011 -0400 summary: Exercise crashers to ensure they are still covering known error cases files: Lib/test/crashers/README Lib/test/test_crashers.py This has broken many buildbots. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, Mar 17, 2011 at 10:03 AM, Reid Kleckner reid.kleck...@gmail.com wrote: 98% of the time, if you don't actually have merge conflicts, applying your change over someone else's without testing will work, so I feel like rebasing a single commit without testing is no big deal. On the off chance that it breaks, the buildbots will find out. Just don't rebase a whole feature branch of commits, leave the final merge in. This is one of the reasons we're advocating only collapsed patches in the main repository, so those untested intermediate revisions don't exist. Then the commits will consist of either cohesive changes, or else minor bookkeeping stuff like fixing NEWS, ACKS or the merge status. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Exercise crashers to ensure they are still covering known error cases
On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: This has broken many buildbots. I'm pretty sure I know which one is the problem child, so I just pushed a fix which should get that one dying reliably on more platforms. I also tweaked the test to provide more info as to which crashers are being tried in verbose mode. More generally, should we tweak test.script_helper._assert_python to print the failing arguments as part of the assertion message? (the API flexibility pretty much rules out the caller passing in an explicit assertion message) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 17 Mar 2011 09:24:26 -0400 R. David Murray rdmur...@bitdance.com wrote: It would be great if rebase did work with share, that would make a push race basically a non-issue for me. rebase as well as strip destroy some history, meaning some of your shared clones may end up having their working copy based on a non-existent changeset. I'm not sure why rebase would be worse that strip in that regard, though. So maybe the problem was that I tried hg pull --rebase, and that mucked with the checkout. If I do a straight hg rebase, will it rebase *all* the commits in my local repo, regardless of branch? I know how to fix the parent of my working dirs, so that isn't an issue. But do I need to do an hg rebase for each branch? The docs made it sound like I did, but the multi-branch case isn't covered in the scenarios. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Exercise crashers to ensure they are still covering known error cases
On Thu, Mar 17, 2011 at 10:39 AM, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: This has broken many buildbots. I'm pretty sure I know which one is the problem child, so I just pushed a fix which should get that one dying reliably on more platforms. If my last push didn't fix it, I'm not ignoring the problem, I'm just in transit for the next ~30 hours or so. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, 17 Mar 2011 10:03:36 -0400, Reid Kleckner reid.kleck...@gmail.com wrote: I don't think anyone has laid out why destroying history is considered bad by some, so I thought I'd plug this post: http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html Essentially, lets say I have a handful of commits hacking on C code. While I wrote them, someone changed a C API from under me and pushed their change. However, in the last change, I remove my dependence on this API. I pull, rebase, rebuild and test. The tests pass in the latest commit, so I push. But now if someone tries to go back to those intermediate commits (say, searching for the introduction of a regression), they will find a broken build. Yeah, the workflow I'm discussing is about applying individual patches from the tracker, so there's no history in the above sense to worry about. When I start working on a feature branch I will be working in a separate clone and will not rebase. But I will probably produce a collapsed patch when I'm ready to apply to mainline, so the concern with rewriting history won't really apply even there. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, 17 Mar 2011 10:50:24 -0400 R. David Murray rdmur...@bitdance.com wrote: On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 17 Mar 2011 09:24:26 -0400 R. David Murray rdmur...@bitdance.com wrote: It would be great if rebase did work with share, that would make a push race basically a non-issue for me. rebase as well as strip destroy some history, meaning some of your shared clones may end up having their working copy based on a non-existent changeset. I'm not sure why rebase would be worse that strip in that regard, though. So maybe the problem was that I tried hg pull --rebase, and that mucked with the checkout. Can't you just fix the checkout then, using hg up or even hg up -C? (note: I'm not a rebase expert) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] API deprecations in Python 3, from a Python 2 perspective
I've thought some more about deprecations and subsequent deletions in Python 3 (but not read the whole thread -- sorry, I've gotten sick right after coming home from PyCon). I think that as long as a significant number of people are still using Python 2, it may be problematic if we start removing things (or making other backwards-incompatible changes) from later Python 3 versions that existed in early Python 3 versions, even if we've followed PEP 5 for the deprecation period. The problem is that --unrelated to this issue, and for legitimate reasons that we can anticipate-- people will likely ignore the entire Python 3 line until they're ready, which means that they may skip the early Python 3 versions once they port to Python 3. For comparison, suppose you had some code that supported only Python 2.3. Now, even if you ignored Python 2.4, once you were ready for porting to 2.5, you'd either notice the deprecations introduced in 2.4 for stuff removed in 2.5 following PEP 5, or you'd slap yourself on the forehead for not paying attention for such a long time. But you wouldn't complain that core development moves too fast: You know that you are too slow. But if you have a big app finally ported to Python 2.7 (feeling ready Python 3) but are waiting for your last dependency to be ported to Python 3, it's quite reasonable to ignore 3.0, 3.1, 3.2, 3.3... Until you finally attempt to port to 3.4. And if something never got a deprecation warning in 2.7, and was deprecated in 3.2 (say) and removed in 3.4, you'd be in for a shock. And this is not necessarily the kind of stuff that 2to3 does (since the feature existed in 3.0 and 3.1). In some cases 3to2 could even be wrong if we're not careful. I don't want to be alarmist and I don't want to start another moratorium, but I do think that we need to be aware of people coming in sideways into Python 3 and missing the nice deprecations. So let's be conservative with deprecations in the Python 3 line for now. PS. An example of this came up offline: deprecation and eventual removal of various frowned-upon unittest methods. But I anticipate others. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
On Thu, 17 Mar 2011 16:00:50 +0100, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 17 Mar 2011 10:50:24 -0400 R. David Murray rdmur...@bitdance.com wrote: On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 17 Mar 2011 09:24:26 -0400 R. David Murray rdmur...@bitdance.com wrote: It would be great if rebase did work with share, that would make a push race basically a non-issue for me. rebase as well as strip destroy some history, meaning some of your shared clones may end up having their working copy based on a non-existent changeset. I'm not sure why rebase would be worse that strip in that regard, though. So maybe the problem was that I tried hg pull --rebase, and that mucked with the checkout. Can't you just fix the checkout then, using hg up or even hg up -C? (note: I'm not a rebase expert) Perhaps, at the time I knew even less than I do now about mercurial. hg up didn't work, but maybe hg up -C would have. I'll try it again at some point. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Generating patch files
Am 17.03.11 07:30, schrieb Baptiste Carvello: Le 16/03/2011 18:49, Martin v. Löwis a écrit : Having the revision of cpython to compare against is the difficult part; how about: 'max( ancestors(default) and not outgoing() )' ? That fails if there have been later merges with default. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Generating patch files
Am 17.03.11 07:30, schrieb Baptiste Carvello: Le 16/03/2011 18:49, Martin v. Löwis a écrit : Having the revision of cpython to compare against is the difficult part; how about: 'max( ancestors(default) and not outgoing() )' ? I take back what I just said: it looks good. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
2011/3/16 Thomas Heller thel...@ctypes.org: I would like my committer rights to be retracted. I have been contributing to Python here and there for 10 years now, and it was a pleasant experience. Unfortunately, since about a year I have lots more things to do, and I won't be able to contribute anymore (I have not even started to learn mercurial yet). Plus I'm still using 2.6 or even 2.5 with my own Python projects. Thank you very much for you work. We'd always be happy to have you back. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hg: inter-branch workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 14:45, R. David Murray wrote: Not if the cpython repo is in a fully merged stated. And if it isn't, I will wait until it is. (The update notifications on the IRC channel help with monitoring this.) That is repository serialization. The point of HG is to avoid that :-). Moreover, you are supposing that the original committer will merge soon. If you leave an unmerged changeset in 3.2, I would consider that to be leaving the repo in a weird state. I do agree. But there is nothing enforcing it (push hooks), except social pressure. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYJaTZlgi5GaxT1NAQJTmgP+IUCRioVAgSEjXtuufj3T6Vl1Q9XQCHej 4R+RTHeojTleWui3W013tS8cmQMa3Y8RSYh5G60kwhSZmdligRcDHWOzuTkemYol QEv5DDx5dAK/n6XoRA4VWFkVWlw9ZQ8TiiQtvd8h5xiCSxFVTq9NB/LHCQTNzQrW et/jGUvlkOI= =oTMp -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/03/11 16:04, Guido van Rossum wrote: I don't want to be alarmist and I don't want to start another moratorium, but I do think that we need to be aware of people coming in sideways into Python 3 and missing the nice deprecations. So let's be conservative with deprecations in the Python 3 line for now. I can see the motivation for this. I would suggest to keep deprecating things in 3.x, BUT keeping the deprecated stuff around (maybe reimplementing them using the new stuff) until we decide is safe to axe it, instead of the regular 3.x deprecates, 3.(x+1) cleans up. In this way we can keep the improvements, while not leaving people just migrating from 2.7 behind. The problem will be to decide when to do the cleanup... - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTYJcQplgi5GaxT1NAQIeawQAgC3kpmS8RoYoeRn6BRFKTOSEKc6edafY NVKDZ+NAZzTeYqJcr0symc+9A+5J92fJQq2n6tz1/K2yAzS/m1dudAXK7YIb1Ldc EwX8JB2osvCgGM5PFefhGOLZ0VrrlWnHQTEviU5GilGNHzCcbEgNj/3BPnEyCNyv QPmlcyeN+eQ= =xidU -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On 03/17/2011 03:08 PM, Jesus Cea wrote: I would suggest to keep deprecating things in 3.x, BUT keeping the deprecated stuff around (maybe reimplementing them using the new stuff) until we decide is safe to axe it, instead of the regular 3.x deprecates, 3.(x+1) cleans up. At some point, didn't we say PendingDeprecationWarning in version x, DeprecationWarning in x+1, and removal in x+2? That's what I've been doing, but it's not what PEP 5 says. Removing in x+2 would lengthen the timeframe, although I agree with Guido that we should be extra careful for the next several years because of people moving directory from 2.7 to (say) 3.5. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Mar 17, 2011, at 12:22 PM, Eric Smith wrote: On 03/17/2011 03:08 PM, Jesus Cea wrote: I would suggest to keep deprecating things in 3.x, BUT keeping the deprecated stuff around (maybe reimplementing them using the new stuff) until we decide is safe to axe it, instead of the regular 3.x deprecates, 3.(x+1) cleans up. At some point, didn't we say PendingDeprecationWarning in version x, DeprecationWarning in x+1, and removal in x+2? That's what I've been doing, but it's not what PEP 5 says. Removing in x+2 would lengthen the timeframe, although I agree with Guido that we should be extra careful for the next several years because of people moving directory from 2.7 to (say) 3.5. Agreeing with Guido is always a good move :-) In addition, any new deprecations in Py3.x can be marked with py3k warnings in Py2.7 point releases. That would give users the maximum chance to make updates before porting, even if they wait five years to migrate to Py3.x. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Mar 17, 2011, at 4:07 PM, Raymond Hettinger wrote: Agreeing with Guido is always a good move :-) In addition, any new deprecations in Py3.x can be marked with py3k warnings in Py2.7 point releases. That would give users the maximum chance to make updates before porting, even if they wait five years to migrate to Py3.x. And of course, updating 2to3, if possible, would also be appreciated. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Exercise crashers to ensure they are still covering known error cases
Nick Coghlan ncogh...@gmail.com writes: On Thu, Mar 17, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: This has broken many buildbots. I'm pretty sure I know which one is the problem child, so I just pushed a fix which should get that one dying reliably on more platforms. On my Windows buildbots it appears as if this change started creating new debug RTL pop-up windows that my AutoIt script wasn't expecting, so it probably affected the build step in some subsequent builds too since the dialogs kept the python_d process live. I've reset those dialogs and updated my script to automatically acknowledge these dialogs too going forward, but failures prior to this point may not be true failures but just fallout from the prior issue. -- David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On 3/17/2011 11:04 AM, Guido van Rossum wrote: I've thought some more about deprecations and subsequent deletions in Python 3 (but not read the whole thread -- sorry, I've gotten sick right after coming home from PyCon). I think that as long as a significant number of people are still using Python 2, it may be problematic if we start removing things (or making other backwards-incompatible changes) from later Python 3 versions that existed in early Python 3 versions, even if we've followed PEP 5 for the deprecation period. The problem is that --unrelated to this issue, and for legitimate reasons that we can anticipate-- people will likely ignore the entire Python 3 line until they're ready, which means that they may skip the early Python 3 versions once they port to Python 3. ... But if you have a big app finally ported to Python 2.7 (feeling ready Python 3) but are waiting for your last dependency to be ported to Python 3, it's quite reasonable to ignore 3.0, 3.1, 3.2, 3.3... Until you finally attempt to port to 3.4. And if something never got a deprecation warning in 2.7, and was deprecated in 3.2 (say) and removed in 3.4, you'd be in for a shock. Agreed. As Raymond said, such things *should* get a warning in the next release of 2.7, and there will be 'next' 2.7 releases for several years to received such updates. As I understand it, the Pyxxx to PyCapsule CAPI warning was put in 2.7. If 'py3k' warnings need to be specific, I presume that should be possible. People should retest their stuff with each micro (bugfix) release anyway. One counterpoint: everyone should ignore 3.0. And in my opinion, anyone who has ignored 3.1 can continue to ignore it. Which is to say, there is not so much 3.1 stuff frozen in place but what most everyone using 3.1 cannot upgrade to 3.2. So jumping from 2.7 to 3.2 should not be much harder than to 3.1. It might be a little harder to say this about 3.2 when 3.3 comes out. And this is not necessarily the kind of stuff that 2to3 does (since the feature existed in 3.0 and 3.1). In some cases 3to2 could even be wrong if we're not careful. This came up in a tracker issue and I meant to bring it up here before this. Since there is no single 'Python 3', 2to3 really needs to be 2to3.x. So I think the 2to3 that come with 3.x should be specific to 3.x. Or 2to3 should target the latest 3.x. For instance, 2to3 could make the unittest name substitutions now regardless of target version since the now preferred names were in 3.0 already. At the Python level, most of the recent deprecations have either been the delayed unittest cleanup or obscure library methods, many of which were undocumented and/or meant to be private. One exception is the change of .fromstring to .frombytes for a bytes method in one of the modules, a change that should have been in 3.0 but was overlooked. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please retract my committer rights
On 3/17/2011 1:45 PM, Benjamin Peterson wrote: 2011/3/16 Thomas Hellerthel...@ctypes.org: I would like my committer rights to be retracted. I have been contributing to Python here and there for 10 years now, and it was a pleasant experience. Unfortunately, since about a year I have lots more things to do, and I won't be able to contribute anymore (I have not even started to learn mercurial yet). Plus I'm still using 2.6 or even 2.5 with my own Python projects. Thank you very much for you work. We'd always be happy to have you back. In the meanwhile, it would be nice to have another ctypes maintainer, as there are several open issues. There is certainly a opening for a new person with C experience. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Thu, 17 Mar 2011 19:23:30 -0400 Terry Reedy tjre...@udel.edu wrote: People should retest their stuff with each micro (bugfix) release anyway. I'm not sure they should. The point of having micro releases is that they don't bring any visible change in behaviour - apart from fixing bugs, that is. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On Thu, Mar 17, 2011 at 8:35 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 17 Mar 2011 19:23:30 -0400 Terry Reedy tjre...@udel.edu wrote: People should retest their stuff with each micro (bugfix) release anyway. I'm not sure they should. The point of having micro releases is that they don't bring any visible change in behaviour - apart from fixing bugs, that is. But IMHO, it would be that, or urging people to use 2to3 from a separate source. It does not make sense to keep 2to3 frozen while its target moves forward. Even if it is decided that things should not be removed, 2to3 should warn of new deprecations as Python moves into 3.3, 3.4, and beyond. js -- Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
On 03/17/2011 07:23 PM, Terry Reedy wrote: As I understand it, the Pyxxx to PyCapsule CAPI warning was put in 2.7. In 2.7, the CObject constructor PyCObject_FromVoidPtr() threw a PendingDeprecationWarning exception. Like other warnings, these aren't active by default. This still caused two problems: * If you enabled warnings, PyCObject_FromVoidPtr() would return NULL. There is definitely code out there that assumes PyCObject_FromVoidPtr() always succeeds and doesn't bother checking the pointer it gets back. That's a bad assumption, the code is therefore buggy--but exposing these heretofore unnoticed bugs caused problems. * If you enabled warnings-as-errors, a PendingDeprecationWarning is therefore an error. In some environments there's a requirement that Python must build from scratch and pass its unit test suite without errors, with warnings-as-errors turned on. Python 2.7 shipped with one module still using PyCObject_FromVoidPtr(), bsddb, as it's externally maintained. (I wanted to change it to use PyCapsule for 2.7 but was told to leave it alone.) bsddb's test threw the warning, the warning was an error, now people had a problem. In 2.7.1 PyCObject_FromVoidPtr() now calls PyErr_WarnPy3k(). This means it's been promoted to throwing DeprecationWarning! But that's also guarded with Py_Py3kWarningFlag so it's not active unless you ask for that too (as with -3 on the command-line, etc). /larry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective
Antoine Pitrou wrote: On Thu, 17 Mar 2011 19:23:30 -0400 Terry Reedy tjre...@udel.edu wrote: People should retest their stuff with each micro (bugfix) release anyway. I'm not sure they should. The point of having micro releases is that they don't bring any visible change in behaviour - apart from fixing bugs, that is. Even bug fixes can have unintended consequences (in other words, new bugs). Or perhaps there is work-around code in place that now causes problems because there is nothing to work around. Even if neither of those two cases is true, why would you not want the warm, fuzzy feeling of contentment *knowing* that your code runs on the latest Python? ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Wed, Mar 16, 2011 at 5:02 AM, Nick Coghlan ncogh...@gmail.com wrote: On Tue, Mar 15, 2011 at 11:34 PM, Guido van Rossum gu...@python.org wrote: Can you be specific? What is different between those RFCs? I finally got around to trying to backport some of the additional urljoin tests from http://bugs.python.org/issue1500504 (specifically, the additional ones Mike Brown provided), but got tripped up by the behavioural changes between the earlier RFCs and RFC 3986 regarding the way .. is handled. Ah, got it. Even in test_urlparse, a bunch of the normative tests from RFC 3986 are commented out because they fail (by design) when run through urllib.parse.urljoin. Some of the additional tests also fail because our urljoin implementation has a whitelist of schemas that support relative references, whereas 3986 expects relative references to work for unknown schemas as well. There's actually quite a few more terminology changes as well (as Senthil pointed out in his email), but it was specifically the failing test cases for urljoin semantics that bit me again yesterday. The problem is that it is quite a lot of work to get fully general URI parsing to work correctly, but the overlap with legacy URL parsing is large enough that many (most?) use cases in practice work just fine with the older RFC semantics. So would having two different API functions, one legacy and one conforming, be a problem? Ideally the conforming API's name would not be something lame like urllib2 but something timeless. :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
Nick Coghlan wrote: The problem is that it is quite a lot of work to get fully general URI parsing to work correctly, but the overlap with legacy URL parsing is large enough that many (most?) use cases in practice work just fine with the older RFC semantics. Yes. We can have API which strictly confirms to latest RFC by definition, but the problem is there is code out there which 'expects' the parsing behavior remain unchanged so that their existing code does not break. And with parsing behavior unchanged means conforming to older RFC parsing rules. The solution seems to be extra function or an flag in the urlparse method which will exhibit the more latest behavior. Guido wrote: So would having two different API functions, one legacy and one conforming, be a problem? Ideally the conforming API's name would not be something lame like urllib2 but something timeless. :-) :-) Should blame Jeremy for that name!. But urllib2 is long replaced by urllib.parse, urllib.request and urllib.response. Considering how you remember urllib2, I think it's name has stood the test of time. But seriously, I think an additional function or additional flag in the current functions/method in the parse module is sufficient than going for another module. -- Senthil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?
On Thu, Mar 17, 2011 at 8:19 PM, Senthil Kumaran orsent...@gmail.com wrote: Nick Coghlan wrote: The problem is that it is quite a lot of work to get fully general URI parsing to work correctly, but the overlap with legacy URL parsing is large enough that many (most?) use cases in practice work just fine with the older RFC semantics. Yes. We can have API which strictly confirms to latest RFC by definition, but the problem is there is code out there which 'expects' the parsing behavior remain unchanged so that their existing code does not break. And with parsing behavior unchanged means conforming to older RFC parsing rules. The solution seems to be extra function or an flag in the urlparse method which will exhibit the more latest behavior. Guido wrote: So would having two different API functions, one legacy and one conforming, be a problem? Ideally the conforming API's name would not be something lame like urllib2 but something timeless. :-) :-) Should blame Jeremy for that name!. But urllib2 is long replaced by urllib.parse, urllib.request and urllib.response. Considering how you remember urllib2, I think it's name has stood the test of time. It stood out like a sore thumb. :-) But seriously, I think an additional function or additional flag in the current functions/method in the parse module is sufficient than going for another module. I vote for a new function, not a flag. (Others can explain my rule of thumb against flag arguments whose values are nearly always constants.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
