A couple of issues have arisen where features were added to str.format without similarly being added to string.Formatter.

This is only possible because the test cases for the two are currently almost entirely separate.

A common set of tests defined as (fmt, args, kwargs, output) tuples would help ensure that the implementations remained consistent in the future.

(ISTM that such test improvements would be beneficial to all branches, and we would also eschew merge issues if we change all branches.  Other core devs sometimes object to test improvements or additions in stable branches though.)

I have some questions about this:

1) In Lib/test/string_tests.py it says:
“Common tests shared by test_str, test_unicode, test_userstring and
test_string”

but

   a) I cannot find test_str

   b) string is imported and only some constants ascii_letters
   and digits are used

   c) In test_join there is a comment “see the test in
   test.test_string.StringTest.test_join” Is that obsolete?
   (I cannot find StringTest in the test_string test)

2) Is there more tests for the build in format (in
test_buildin.BuiltinTest.test_format only the basic machinery is tested.
I would expect something like in test_format.py somewhere

3) it is true that all tests for the build in 'format' should also pass 
in 'string.Formatter().format'

Thanks in advance!

francis

At least the first couple of those look like obsolete comments left over from the 2.x branch (we didn't do a mass renaming in the test suite, so many tests still live in their old locations).

I increased the coverage of formatter module to 40%. I added a new file "test_formatter.py" including some unit tests.

I left a review on rietveld.

FWIW I think string_tests and related files should undergo a (major?) refactoring.  I worked with them a few times and it's a bit of a mess with all those base classes and mixins.  I also found some tests that weren't running because they were accidentally overridden by one of the subclasses, or other tests that were duplicated.  This is especially true on Python 3, where bytes and str share a smaller subset of features.

Thanks for the review. I corrected some issues in my code. Here is the new patch.

The formatter module was deprecated in Python 3.4 and is scheduled
for removal in Python 3.6. See [1] and [2].

---
[1] https://docs.python.org/3/library/formatter.html#module-formatter
[2] https://docs.python.org/3/whatsnew/3.4.html#deprecated

Note that this issue wasn't about the formatter module - it relates to the str.format() method and the string.Formatter *class*.

The formatter module is completely unrelated.

The issue is about tests for str.format and string.Formatter, but in http://bugs.python.org/msg194709 and the associated patch there are tests for the formatter module to increase its coverage.

I suggested on the mentorship list that we break this into two issues.

Francisco, can you sign the contributor agreement? https://www.python.org/psf/contrib/contrib-form/

I added some review comments.

Set to "pending" while I wait to hear back from Francisco on the review comments.

Hi, I signed the contributor agreement. Thank you for your review comments. I did these tests about one year ago and right now I don't have much time to look at it again. I hope to do so in the next months.

> Note that this issue wasn't about the formatter module - it relates to the str.format() method and the string.Formatter *class*.

I would tend to agree with Nick and Eric. From what I see in the patch, the tests are for formatter module and not the string.Formatter class.

This issue is no newcomer friendly, I remove the "easy" keyword.

@Irit Katriel: Please avoid changing the versions field of old inactive issues. It changes artificially the last activity date of an issue and it sends an email to all people in the nosy list. There is no need to update the Version field of the +7500 open bugs.

Victor: Irit is reviewing old issues to decide whether to close or not.  She has to touch it somehow to mark it as reviewed.

Irit: if you only change the version, others may think that you blindly updated the version.  Better to say something that moves the issue forward.  Also, only marking for the next version, now 3.10, would delay the possible future obsolescence of the version marking.  In any case, any coredev who merges would decide about backports.

This particular issue needs major surgery as it is two interleaved but unrelated discussions.  Francisco should have moved his unrelated patch to a new issue as Eric Smith asked.  I opened new issue 42299 and moved the revised patch there, with credit to Francisco and Ezio as reviewer.  I unlinked both from here.

To make the discussion of Nick's issue more readable, the unrelated messages about the unrelated patch should be unlinked.  I believe each message unlink would generate a separate email, as did the file unlinks.

Since nobody implemented this idea in 8 years, maybe it's time to give up and close this issue as out of date. It seeems like Nick was busy with other stuff, and nobody took this task in the meanwhile.