Can you sign the Python contributor form  - https://www.python.org/psf/contrib/contrib-form/?  (If you already have, just say so.)

string.Template is tested in Lib/test/test_pep292.py.

Thanks Serhiy.  Given that, I suggest checking if the new tests this adds are already covered in test_pep292.py or not to decide if we should move forward with this patch or not.

Just checked! Apologies for this totally unnecessary patch, didn't know to look elsewhere but now I absolutely do  -- looks like all the tests are there and more. Thank you!

It probably makes sense to move test_pep292.py tests into test_string.py. Test files named after peps are not very helpful.

Or at least add a reference in test_string.py.

Oh! I can do that, and resubmit the patch! Good suggestion. Thank you again.

Reopening and retitling.

Here is an updated patch adding all the tests from test_pep292.py into test_string.py. After this happens test_pep292.py can be removed!

This is not so easy. After adding all the tests from test_pep292.py into test_string.py and removing test_pep292.py we will lost all the history of test_pep292.py. Merging two files in Mercurial is not easy. I already did this and can do again if it is worth.

I'm not too concerned about that. git can handle it well, which we will
have soon.

On Thu, Jun 2, 2016, at 12:50, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> This is not so easy. After adding all the tests from test_pep292.py into
> test_string.py and removing test_pep292.py we will lost all the history
> of test_pep292.py. Merging two files in Mercurial is not easy. I already
> did this and can do again if it is worth.
> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue27185>
> _______________________________________

Benjamin: meaning we should wait for git to merge it, or git will automatically handle the history after conversion?

We should be able to commit it now. git blame can usually figure out
this stuff post facto.

On Thu, Jun 2, 2016, at 13:54, R. David Murray wrote:
> 
> R. David Murray added the comment:
> 
> Benjamin: meaning we should wait for git to merge it, or git will
> automatically handle the history after conversion?
> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue27185>
> _______________________________________

All right, I'll go ahead and commit it, then.

New changeset 89abefdebf4d by R David Murray in branch '3.5':
#27185: move test_pep292 into test_string.
https://hg.python.org/cpython/rev/89abefdebf4d

New changeset c2d3d8c3e0bf by R David Murray in branch 'default':
Merge: #27185: move test_pep292 into test_string.
https://hg.python.org/cpython/rev/c2d3d8c3e0bf

Thanks, Erin.

Hooray thank you everyone!

FWIW I doubt Git is any better at this than Mercurial: <https://github.com/python/cpython/blame/master/Lib/test/test_string.py#L190>

Git can automatically pick up file renames and copies when analysing the history, but has no special metadata for this. I understand Mercurial is the opposite (has metadata, but at least by default does not pick up copies and renames from the history). Perhaps that is what Benjamin was thinking of. I understand Git will only pick up movements of the majority of a file, not parts of files (unless something has changed recently).

Perhaps Serhiy can clarify, but I imagine he was proposing something like this (which I have not tested):

A. Start at revision A
B. Remove test_string and rename test_pep292 in its place, giving revision B
C. Merge revisions A and B, and manually merge the contents of the two test_string versions, giving the final revision

This is even more complex, since you can't merge a revision with its parent.

A. Start at revision A.
B. Rename test_string to test_string_merged, giving revision B.
A. Update back to revision A.
C. Rename test_pep292 to test_string_merged, giving revision C.
D. Merge revisions B and C, and manually merge the contents of the two test_string_merged versions, giving revision D.
E. Rename test_string_merged to test_string, giving the final revision.

On Thu, Jun 2, 2016, at 18:28, Martin Panter wrote:
> 
> Martin Panter added the comment:
> 
> FWIW I doubt Git is any better at this than Mercurial:
> <https://github.com/python/cpython/blame/master/Lib/test/test_string.py#L190>
> 
> Git can automatically pick up file renames and copies when analysing the
> history, but has no special metadata for this. I understand Mercurial is
> the opposite (has metadata, but at least by default does not pick up
> copies and renames from the history). Perhaps that is what Benjamin was
> thinking of. I understand Git will only pick up movements of the majority
> of a file, not parts of files (unless something has changed recently).

git blame -C works quite well in my experience for detecting moved lines
of code.

In general, I think we shouldn't be afraid to reorganize code for fear
of breaking "VCS" history. The tools will catch up. (I think they
largely have already.) At worst, one must manually "follow" the move of
some code through history.

New changeset 27f5eb630499 by Serhiy Storchaka in branch '2.7':
Issue #27185: Rename test_string.py to test_string_merged.py.
https://hg.python.org/cpython/rev/27f5eb630499

New changeset 8218b1309178 by Serhiy Storchaka in branch '2.7':
Issue #27185: Rename test_pep292.py to test_string_merged.py.
https://hg.python.org/cpython/rev/8218b1309178

New changeset 7dac80e0dd5e by Serhiy Storchaka in branch '2.7':
Issue #27185: Merge test_pep292.py into test_string_merged.py.
https://hg.python.org/cpython/rev/7dac80e0dd5e

New changeset e2e309fb2b1e by Serhiy Storchaka in branch '2.7':
Issue #27185: Rename test_string_merged.py back to test_string.py.
https://hg.python.org/cpython/rev/e2e309fb2b1e

Merged test_pep292.py into test_string.py with preserving the history in 2.7.

This required following steps:

hg mv Lib/test/test_string.py Lib/test/test_string_merged.py
hg commit
hg update -C -r -2
hg mv Lib/test/test_pep292.py Lib/test/test_string_merged.py
hg commit
hg update -C -r -2
hg merge
# Manually merge the content of former test_string.py and test_pep292.py.
hg commit
hg mv Lib/test/test_string_merged.py Lib/test/test_string.py
hg commit
hg push

We now should restore deleted test_pep292.py (is it possible with the history?) and repeat above steps in 3.x.

IMO I wouldn’t bother. David has already done the change a different way, which is simpler to understand commit-by-commit, even if it messes with the Mercurial annotate history.

FWIW I guess you could do a similar merge with an old version to restore the deleted file though.

New changeset 70e19b014d2f by Serhiy Storchaka in branch '3.5':
Issue #27185: Rename test_string.py to test_string_merged.py.
https://hg.python.org/cpython/rev/70e19b014d2f

New changeset 0da07e73451d by Serhiy Storchaka in branch '3.5':
Issue #27185: Rename test_pep292.py to test_string_merged.py.
https://hg.python.org/cpython/rev/0da07e73451d

New changeset 14a036c696e8 by Serhiy Storchaka in branch '3.5':
Issue #27185: Merge test_pep292.py into test_string_merged.py.
https://hg.python.org/cpython/rev/14a036c696e8

New changeset 36f5229e45a6 by Serhiy Storchaka in branch '3.5':
Issue #27185: Rename test_string_merged.py back to test_string.py.
https://hg.python.org/cpython/rev/36f5229e45a6

Now the history is restored.