Michael Witten added the comment: Thank you for the reply.
* As already stated, I believe that Python 3 is not affected by this problem; certainly, version 3.5.2 does not seem to be affected, as per my ad hoc testing. * Very many programs are targeted to Python 2.7, and probably will be for quite some time. Without my patch, `python' (2.7) itself breaks them as described; yet, with my patch, these programs will just work (without intervention). It seems to me that this patch isn't a change in a feature, but is rather the overdue implementation of promised behavior; the file system is what matters, not the host operating system, which has hitherto been conflated with the file system. That is, this patch is a bug fix. * I'm not sure how a test could be written to handle this situation. I suppose that by default, such a test could be skipped with a warning; a user could be required to set up a relevant mount point, and then to signal the testing infrastructure to use it. --------------- * With regard to the form of the patches, my intention is that they be introduced into the history severally, with the commit messages and other metadata as specified. It would probably make most sense for these commits to be the ancestors of a merge commit that provides the sole reference to this tracker issue. For instance, the most correct and useful application of the patch series is given by the following: $ hg pull --branch 2.7 # This must pull in something new for the rest to work. $ tip=$(hg log --limit 1 --template '{node}' -r tip) $ hg update -c -r 59260b38f7cd4a2ae66928de5227798524006e64 $ hg import /path/to/pep-235-on-posix.patch $ hg merge -r "$tip" $ hg commit --message "Issue #28670: Implement PEP 235 on every POSIX system, and clean up the C code for \`import'" That produces a single commit whose message supplies the usual dearth of information, but whose ancestral history captures the rich details. It should be noted that `hg bundle' and `hg unbundle' could be used to import more directly the proper pre-merge history, albeit at the expense of the human-readability of the "patch" file. That is to say, I'm underwhelmed by the way you guys are managing this project's history. Despite all of its faults, Mercurial is still being underutilized. * I could split the original patch file into 3 separate patch files, but what should I do with the metadata? If each separate patch were to contain its own metadata, would the code review tool still choke? I suspect it would. What's the point? The original file itself is perfectly readable, and you can simply review the diffs after applying them within your repo, anyway. Ironically, the very point of having multiple changesets is to make digesting the changes as easy as possible---not only now, but far into the future, when you're simply looking at the graph of the history! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28670> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com