Re: [Python-Dev] PEP 385: pruning/reorganizing branches
Comments on some of the branches I've had involvement with... On Mon, Aug 3, 2009 at 11:51 AM, Dirkjan Ochtman wrote: > py3k-short-float-repr: strip streamed-merge Sounds fine. > py3k-issue1717: keep-clone I don't think there's any need to keep this branch; its contents were all merged (in pieces) to py3k (various revisions with numbers in the range 69188--69225). So I think 'strip streamed-merge' is appropriate here, if I'm understanding your terminology. > trunk-math: I think this one can go down as 'strip', too; there's nothing there of interest that isn't already in trunk and py3k. It was merged to trunk in r62380. -- Mark ___ 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] PEP 385: the eol-type issue
Dirkjan Ochtman wrote: >>> * commit hooks be implemented to enforce this - but this should not be >>> necessary if the above was implemented and socially enforced. > > You seem to advocate a two-step approach: enforce line endings through > win32text, catch any errors that slipped through in a hook (commit > hook is an optional first line of defense, changegroup hooks on the > server to protect the rest of the world). > > I think inverting that approach would be better: have strict hooks on > the server to prevent people from pushing inappropriate EOLs, and > provide help on configuring win32text as an extra help for developers > on Windows who use editors that work better with \r\n. That leaves > people to pick their own weapon of choice against propagation of \r\n > (e.g. better editor, commit hooks, whatever) while still making sure > no inappropriate line endings land in the python.org repositories. It > also seems to fit well with the whole consenting adults thing (but > that might just be me). It's about not treating Windows developers as second class citizens. Their platform uses \r\n as its native line ending format, so they should be able to work in that format without any hassles by following some simple instructions (such as "ensure you have version X of the Windows hg client, enable the win32text extension and configure it in such-and-such a way"). Not "oh, yeah, that's an issue but if you search the Intarwebs there are a few different things you can do that kinda sorta work but are a bit fragile and klunky". The precise order the two issues (server side enforcement and client side assistance) are dealt with doesn't really matter because *both* issues need to be addressed before we migrate. win32text needs to be usable on non-Windows clients so that tarballs generated on a *nix machine get the line endings right in the Windows-only files. 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] Functionality in subprocess.Popen.terminate()
Eric Pruitt wrote: > In my GSoC project, I have implemented asnychronous I/O in > subprocess.Popen. Since the read/write operations are asynchronous, the > program may have already exited by the time one calls the asyncread > function I have implemented. While it returns the data just fine, I have > come across an issue with the TerminateProcess function in Windows: if > the program has already exited, when subprocess.Popen.Terminate calls > the Windows built-in "TerminateProcess" function, an "access denied" > error will occur. Should I just make it so that this exception is simply > ignored or perform some kind of check to see if the process exists > beforehand? If the latter, I have been unable to find a way to do so, to > my liking at least. The solutions I saw would require code that seems a > bit excessive to me. I'm pretty sure we already ignore some spurious error messages in cases like calling flush() in file.close(). I would suggest checking what the io module does in such cases and see what kind of precedent it sets. 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] PEP 385: pruning/reorganizing branches
Dirkjan Ochtman wrote: > On Tue, Aug 4, 2009 at 08:06, "Martin v. Löwis" wrote: >> I don't know what your plan is wrt. release tags, i.e. whether you >> want to keep them all. If you are stripping out some of the branches, >> but plan to keep the release tags, I wonder what the tags look like. > > The plan was to keep all maintenance branches and all release tags but > not all release branches (since they seem to contain few commits > anyway). I think I share Martin's confusion here - how can you keep a release tag (e.g. 2.2.2) without also keeping the release branch where that tag was created? Yes, the maintenance branches contain a comparatively small number of commits, but they're still the sources of the maintenance release tags. Or is this a case where Mercurial's DAG allows you to handle those old branches as "abandoned" leaves of the DAG in the history of the affected files, with the tags picking out the relevant versions of the files? 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] PEP 385: pruning/reorganizing branches
On Mon, Aug 03, 2009 at 12:51:36PM +0200, Dirkjan Ochtman wrote: > amk-mailbox: keep-clone? strip -- this branch was for working on a fix for http://bugs.python.org/issue1599254, but the actual work in the branch is available as the patches attached to that item. --amk ___ 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] PEP 385: pruning/reorganizing branches
Dirkjan Ochtman wrote: > > okkoto-sizeof strip - It's an 2008 Google Summer of Code project. The important changes have been applied in r63856. ___ 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] Functionality in subprocess.Popen.terminate()
On Tue, Aug 4, 2009 at 04:27, Nick Coghlan wrote: > Eric Pruitt wrote: >> In my GSoC project, I have implemented asnychronous I/O in >> subprocess.Popen. Since the read/write operations are asynchronous, the >> program may have already exited by the time one calls the asyncread >> function I have implemented. While it returns the data just fine, I have >> come across an issue with the TerminateProcess function in Windows: if >> the program has already exited, when subprocess.Popen.Terminate calls >> the Windows built-in "TerminateProcess" function, an "access denied" >> error will occur. Should I just make it so that this exception is simply >> ignored or perform some kind of check to see if the process exists >> beforehand? If the latter, I have been unable to find a way to do so, to >> my liking at least. The solutions I saw would require code that seems a >> bit excessive to me. > > I'm pretty sure we already ignore some spurious error messages in cases > like calling flush() in file.close(). I would suggest checking what the > io module does in such cases and see what kind of precedent it sets. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > --- > Sounds good enough to me but I was wondering if it might be a good idea to add a function like "pidinuse" to subprocess as a whole that would determine if a process ID was being used and return a simple boolean value. I came across a number of people searching for a way to determine if a PID was running (Google "python check if pid exists") so it seems like the implemented functionality would be of use to the community as a whole, not just my wrapper class. 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] Functionality in subprocess.Popen.terminate()
Eric Pruitt wrote: > On Tue, Aug 4, 2009 at 04:27, Nick Coghlan wrote: >> Eric Pruitt wrote: >>> In my GSoC project, I have implemented asnychronous I/O in >>> subprocess.Popen. Since the read/write operations are asynchronous, the >>> program may have already exited by the time one calls the asyncread >>> function I have implemented. While it returns the data just fine, I have >>> come across an issue with the TerminateProcess function in Windows: if >>> the program has already exited, when subprocess.Popen.Terminate calls >>> the Windows built-in "TerminateProcess" function, an "access denied" >>> error will occur. Should I just make it so that this exception is simply >>> ignored or perform some kind of check to see if the process exists >>> beforehand? If the latter, I have been unable to find a way to do so, to >>> my liking at least. The solutions I saw would require code that seems a >>> bit excessive to me. >> I'm pretty sure we already ignore some spurious error messages in cases >> like calling flush() in file.close(). I would suggest checking what the >> io module does in such cases and see what kind of precedent it sets. >> >> Cheers, >> Nick. >> >> -- >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia >> --- >> > > Sounds good enough to me but I was wondering if it might be a good > idea to add a function like "pidinuse" to subprocess as a whole that > would determine if a process ID was being used and return a simple > boolean value. I came across a number of people searching for a way to > determine if a PID was running (Google "python check if pid exists") > so it seems like the implemented functionality would be of use to the > community as a whole, not just my wrapper class. > > Eric > I'm not sure of the actual details but it seems from your description that even if you check first a race condition will still exist. Specifically the subprocess could terminate after the check and before the TerminateProcess call. So it seems better just to call TerminateProcess and then correctly handle any possible error. Janzert ___ 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] PEP 385: pruning/reorganizing branches
On Mon, Aug 3, 2009 at 23:06, "Martin v. Löwis" wrote: > > empty: keep-clone? > > I use that as a branch to tell build slaves to clean out their > current checkouts. So keep-clone sounds right, assuming it is possible > to target buildslaves at either clones or branches (which, IIUC, would > be necessary anyway, since we are using a mix of branches and clones). > > > amk-mailbox: keep-clone? > > twouters-dictviews-backport: keep-clone? > > bcannon-sandboxing: keep-clone? > > bippolito-newstruct: merges? > keep-clone bcannon-objcap, strip bcannon-sandboxing. > > You'll probably need to explicitly ping the specific owners > (Andrew Kuchling, Thomas Wouters, Brett Cannon, Bob Ippolito) > to understand the fate of these branches. > > This also raises the question how developers should publish their > "own" branches. For the bzr setup, there was apparently a proposal > to use directories for that, i.e. giving each developer a directory > on code.python.org to publish branches. > Yeah, I thought I brought this up and people liked the idea of keeping some user directory on hg.python.org. I am fine with code.python.org as well. But having some place would be really handy (although having bitbucket and Google Code makes this not quite as important). > > Not doing that, but keeping owner information encoded in the clone > name, would be fine as well. > > > release23-branch: merges? > > r23b2-branch: merges? > > r22rc1-branch: strip > > r22b1-branch: merges? > > r22a4-branch: merges? > > r22a3-branch: merges? > > r161-branch: merges? > > It seems we had been creating CVS branches for every release around > that time; I don't remember the details. Each such branch should end > up in a tag. For example, release23-branch should (and does) ultimately > lead to tags/r23. cvs2svn wasn't able to recognize this correctly (as > CVS branches apply to each file individually), so it created the r23 > tag out of various copies that were current when the tag was made. > > I don't know what your plan is wrt. release tags, i.e. whether you > want to keep them all. If you are stripping out some of the branches, > but plan to keep the release tags, I wonder what the tags look like. > > > release22-branch: merged-r24921 > > Not really. Jack Jansen merged some changes that got first applied > to the 2.2 > > > r22b2-branch: merges? merged-r24426 > > r22b2-branch: merges? merged-r24426 > > > release20-maint: keep-named > > See above. So you do plan to keep all past releases? > > > release152p1-patches: merges? > > Probably merged. I don't recall whether 1.5.2p1 really happened; > in r14966, Fred claims that he merged all changes from 1.5.2p2 (!). > > "Hopefully I got all this right!" > > I surely hope the same - I doubt anybody would go back and check > whether anything is missing. > > 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/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: the eol-type issue
On 4/08/2009 7:20 PM, Nick Coghlan wrote: Dirkjan Ochtman wrote: * commit hooks be implemented to enforce this - but this should not be necessary if the above was implemented and socially enforced. You seem to advocate a two-step approach: enforce line endings through win32text, catch any errors that slipped through in a hook (commit hook is an optional first line of defense, changegroup hooks on the server to protect the rest of the world). I think inverting that approach would be better: have strict hooks on the server to prevent people from pushing inappropriate EOLs, and provide help on configuring win32text as an extra help for developers on Windows who use editors that work better with \r\n. That leaves people to pick their own weapon of choice against propagation of \r\n (e.g. better editor, commit hooks, whatever) while still making sure no inappropriate line endings land in the python.org repositories. It also seems to fit well with the whole consenting adults thing (but that might just be me). It's about not treating Windows developers as second class citizens. Their platform uses \r\n as its native line ending format, so they Thanks Nick; I didn't want to be the only one saying that. There is a fine line between asserting reasonable requirements for Windows users and being obstructionist and unhelpful, and I'm trying to stay on the former side :) should be able to work in that format without any hassles by following some simple instructions (such as "ensure you have version X of the Windows hg client, enable the win32text extension and configure it in such-and-such a way"). Not "oh, yeah, that's an issue but if you search the Intarwebs there are a few different things you can do that kinda sorta work but are a bit fragile and klunky". The precise order the two issues (server side enforcement and client side assistance) are dealt with doesn't really matter because *both* issues need to be addressed before we migrate. I'm not that happy with the server being the primary line of defense. Let's say I make a branch of the hg repo, myself and a few others work on it committing as we go, then attempt to merge back upstream. Let's say some of the early commits on that clone introduced "bad" line endings. I'm guessing I would be forced to make a number of whitespace-only checkins to normalize the line-endings before it could merge - and these checkins would then be in the history forever. Or I could attempt to recreate the clone by somehow "replaying" the commits with line endings corrected. Either way, the situation doesn't seem good. win32text needs to be usable on non-Windows clients so that tarballs generated on a *nix machine get the line endings right in the Windows-only files. I agree. It isn't fair to make this windows users problem. It would be like me proposing the repo get imported with \r\n line endings, enforce that with server side hooks, and let non-Windows users worry about the ramifications of that - somehow I doubt that would fly - so neither should it fly for Windows users... I'm more than willing to help on this; I haven't resurrected my stale patch because I find win32text only 1/2 a solution that doesn't work in practice. Therefore that patch is as stale for me as it is anyone. However, if a plan is put in place which offers a full solution and the hg developers are committed to it, I promise I'll put my hand up to help with implementation in a fairly timely manner... Cheers, Mark ___ 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] PEP 385: the eol-type issue
Mark Hammond: > Thanks Nick; I didn't want to be the only one saying that. There is a fine > line between asserting reasonable requirements for Windows users and being > obstructionist and unhelpful, and I'm trying to stay on the former side :) I haven't commented on this issue before because I can't really be helpful. I just don't understand why hg is being considered before it's Windows support is roughly equivalent to svn and cvs. There has been some similar experience with the main repository for the Cocoa port of Scintilla which is in bzr on launchpad. Several times in that repository, files were checked in with wrong line ends making every line appear changed when looking through history. There are several causes for this including user error but bzr (and hg) should default to more helpful behaviour on text files. Neil ___ 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] PEP 385: the eol-type issue
Mark Hammond writes: > Let's say I make a branch of the hg repo, myself and a few others work > on it committing as we go, then attempt to merge back upstream. Let's > say some of the early commits on that clone introduced "bad" line > endings. I'm guessing I would be forced to make a number of > whitespace-only checkins to normalize the line-endings before it could > merge - and these checkins would then be in the history forever. What is wrong with that? I mean, if that is the actual sequence of events, why should the history not reflect that? > Either way, the situation doesn't seem good. I see this assertion made often, so I'm not saying you are necessarily wrong to make it. I just don't see a justification for making it (and, without justification, I would say it *is* wrong to make it). -- \ “Our products just aren't engineered for security.” —Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__) development | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 385: the eol-type issue
On Tue, Aug 4, 2009 at 5:43 PM, Mark Hammond wrote: > I'm more than willing to help on this; I haven't resurrected my stale patch > because I find win32text only 1/2 a solution that doesn't work in practice. > Therefore that patch is as stale for me as it is anyone. However, if a plan > is put in place which offers a full solution and the hg developers are > committed to it, I promise I'll put my hand up to help with implementation > in a fairly timely manner... Not sure what your patch was as I cannot find it, but I did up a quick change to win32text that uses a versioned .win32text file to maintain encoders, decoders and an ignore list http://media.digitalxero.net/win32text.py http://media.digitalxero.net/.win32text and add to your hgrc file [hooks] precommit.eol_encode = python:hgext.win32text.versioned_encode it needs to be precommit since it needs to run before the change set has been created so it can modify the data. Honestly I think this solution is kind of a hack, a much better solution would be to modify the encode/decode hooks to accept a filename so you can at least do ignore pattern matching, but that still ignores versioned encodes / decodes ___ 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] PEP 385: the eol-type issue
On 5/08/2009 3:56 PM, Ben Finney wrote: Mark Hammond writes: Let's say I make a branch of the hg repo, myself and a few others work on it committing as we go, then attempt to merge back upstream. Let's say some of the early commits on that clone introduced "bad" line endings. I'm guessing I would be forced to make a number of whitespace-only checkins to normalize the line-endings before it could merge - and these checkins would then be in the history forever. What is wrong with that? I mean, if that is the actual sequence of events, why should the history not reflect that? The problem is the sequence of events happened in the first place. An extra burden is placed on the developer that will quickly get tiresome. I wouldn't personally be happy if that workflow became the norm. Either way, the situation doesn't seem good. I see this assertion made often, so I'm not saying you are necessarily wrong to make it. I just don't see a justification for making it (and, without justification, I would say it *is* wrong to make it). *shrug* - in my opinion, the fact the developer is faced with that hurdle in their workflow is justification enough to say that developer's situation "doesn't seem good" and should have been prevented from happening by the tool much earlier than proposed. Mark ___ 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] PEP 385: the eol-type issue
Mark Hammond writes: > On 5/08/2009 3:56 PM, Ben Finney wrote: > > Mark Hammond writes: > > > >> Let's say I make a branch of the hg repo, myself and a few others work > >> on it committing as we go, then attempt to merge back upstream. Let's > >> say some of the early commits on that clone introduced "bad" line > >> endings. […] > > The problem is the sequence of events happened in the first place. An > extra burden is placed on the developer that will quickly get > tiresome. I wouldn't personally be happy if that workflow became the > norm. Ah, okay. In that case, the ultimate “problem” is that OS vendors entrenched their incompatible line-ending conventions instead of choosing a single standard. Any line-ending burden borne by developers is a result of that. If things were different, they'd be different. However, we live with the legacy of that stupid set of decisions and have no real option to resolve it permanently short of deprecating entire vistas of tools (or even entire operating systems). > *shrug* - in my opinion, the fact the developer is faced with that > hurdle in their workflow is justification enough to say that > developer's situation "doesn't seem good" and should have been > prevented from happening by the tool much earlier than proposed. AIUI, this is a combination of several things: * different OSen have incompatible, entrenched conventions for line-ending that is embodied in the default output of their text processing tools. * these differences matter in many concrete ways to the tools that process text, so the differences need to be preserved, or explicitly transformed. * distributed VCS has the job of preserving data as present on the filesystem, including whatever line-ending convention is present in a file. * distributed VCS has the job of managing data exchange between users, presenting differences in a way that allows easy inspection and merging. * humans want to pretend that these incompatibilities don't exist, and want “end of line” to be an automatically-handled abstraction. It's not a simple thing to solve, and many clever people have tried over the decades. The fact that a centralised VCS can put the problem aside by requiring an explicit, single decision in the repository, is no help when addressing the constraints of a distributed VCS. At some point, the decision about how to handle line endings in cross-platform data needs to be punted to a human for a context-sensitive assessment, since (as can be seen) the above list of requirements is internally inconsistent and can't be relegated to a one-size-fits-all algorithm. -- \ “All progress has resulted from people who took unpopular | `\ positions.” —Adlai Stevenson | _o__) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
