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.