[issue27071] unittest.TestCase.assertCountEqual is a very misleading name

[Alden]

Alden  added the comment:

I think we need to re-open this issue.  I have done a poll of a number of 
python developers and every developer I talked to said they initially thought 
this function "assertCountEqual" asserts that the count is equal. Probably 
because that's exactly what the words mean. I think most people in this 
discussion agree that the name is not ideal, but how did we end up picking one 
that explicitly says something completely incorrect?  Not only that but we 
broke backward compatibility for a name that is significantly worse than the 
original.

If you asked any colleague or developer on the street that isn't a python 3 
user what "assert count equal" would do when provided with two lists. I would 
be amazed if anyone said something other than "checks that the two lists store 
the same number of elements".  I have asked everyone I know and no one has said 
anything different.

assertItemsEqual - Most people get this correct, some people think it also 
checks order. This confusion actually isn't that common because people first 
learn the function that DOES check order. (better)

assertFrequencyCountsEqual - Most people aren't sure what this does and would 
be need to look this up. (better)

assertElementCountsEqual - Seems like it checks the count of a list, but leaves 
you with some uncertainty. (not great, but better)

assertCountEqual and assertCountsEqual - Everyone i spoke to thought this 
asserted that number of elements in the collections were equal. Total certainty 
about the wrong functionality.


Explicit is better than implicit.
  * This name is not explicit it implies a completely different behavior.
Readability counts.
  * The words of this function literally mean something else.
Practicality beats purity.
  * Users not in the Python ivory tower immediately recognize this function 
name as something else. 
In the face of ambiguity, refuse the temptation to guess.
  * This name is not just ambiguous it is misleading and makes users guess and 
guess incorrectly.
If the implementation is hard to explain, it's a bad idea.
  * If we can't name this function correctly, maybe it's a bad idea?
Now is better than never.
  * This was a mistake and its better to correct it now than let it live on for 
another two years.

--
nosy: +aldencolerain

___
Python tracker 
<https://bugs.python.org/issue27071>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17050] argparse.REMAINDER doesn't work as first argument

[Alden]

Alden <aldencoler...@gmail.com> added the comment:

Paul.  This is a bug, not a feature in argparse.  Devin is 100% correct.  
According to the docs REMAINDER should be greedy and is used for passing 
arguments to sub commands.  In your example the expected behavior is that if 
you do put "d --foo x a b c" that --foo is none and args gets everything.  We 
shouldn't need to use a gatekeeper or resort to manually parsing the remainder 
arguments.  It also shouldn't take 5 years to acknowledged that it needs to be 
fixed.  I'm happy to make a patch if its a bandwidth issue.  Am I 
misunderstanding and you feel like its not possible to fix?  I guess if there 
is a backward compatibility issue then we need to write a new option that does 
literally return the remainder arguments as documented.

--
nosy: +aldencolerain

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue17050>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com