Snake_case aliases to camelCased methods in unittest

[gryznar (Grzegorz Ryznar)]

I am proposing to add aliases to untitest methods which are currently in camelCase. I don’t think, that jUnit legacy is as much important to violate Python’s naming convention. Of course, for compatibility reasons they would be just aliases, but maybe someday legacy methods could be just deprecated and scheduled to removal.

[ericvsmith]

This likely would not be accepted. We don’t need the hassle of having two names for each method forever.

[gryznar (Grzegorz Ryznar)]

Even with long deprecation period? And I am just wondering if Python could rewrite unittest, would it be still camelCase or snake_case? If this decision could be taken one more time?

[jeanas (Jean Abou Samra)]

PEP 8 – Style Guide for Python Code | peps.python.org

“In particular: do not break backwards compatibility just to comply with this PEP!”

[gryznar (Grzegorz Ryznar)]

Yes, I am aware of this rule. But I am just asking theoretically. If this decision could be taken one more time, would they stil written in camelCase?

[ericvsmith]

If it were a green field implementation, then sure, we’d probably use snake case if it were being done today. But that’s not the case here. Breaking test code seems especially egregious.

[gryznar (Grzegorz Ryznar)]

Ok, I am fine with this inconsistent and I was almost certain to receive such answer. I would like only to hear what would happen if unittest would be written from scratch. Thanks for answer! Topic could be closed.

[jeanas (Jean Abou Samra)]

Sure, consistency would be favored. This is only a theoretical question though.

[Kurt (Kurt Bischoff)]

Would a class wrapper serve your needs?
Maybe something like:

import unittest


def attribute_error(self, *args, **kwargs):
    raise AttributeError
    

def my_unit_test(cls):
    cls.assert_raises = cls.assertRaises
    cls.assert_True = cls.assertTrue
    cls.assertTrue = attribute_error
    cls.assertRaises = attribute_error
    # ...
    return cls


@my_unit_test
class MyTest(unittest.TestCase):

    def test_1(self):
        self.assert_True(1)
        
    def test_2(self):
        with self.assert_raises(AttributeError):
            self.assertTrue(1)
               
    
if __name__ == '__main__':
    unittest.main()
    

[gryznar (Grzegorz Ryznar)]

Fortunately there is pytest and I am not sentenced to use camelCase in Python code

[Rosuav (Chris Angelico)]

@gryznar

Even with long deprecation period? And I am just wondering if Python could rewrite unittest, would it be still camelCase or snake_case?

How long a deprecation period are you thinking of?

Python 2.6 (in 2006) introduced threading.current_thread() as an alias for threading.currentThread() etc. They were officilaly deprecated in Python 3.10 (2020), but with no schedule for actual removal.

Internal consistency is more important than PEP 8 compliance.

[gryznar (Grzegorz Ryznar)]

Maybe this mythical Python 4.0?

[storchaka (Serhiy Storchaka)]

Whatever the period may be, at its end every use of deprecated method should be replaced with a new method. Every existing test, in every project that uses unittest, should be rewritten. You can imagine how much it will cost in man-hours? It is easier to create a new package snake_names_unittest and make every project in the world using it.

[ehomrich (Emerson)]

There was a similar discussion a few weeks ago about renaming or aliasing members of the datetime module to follow PEP-8 naming conventions:

Renaming datetime.datetime to datetime.DateTime

I’m sure at one point every Python developer has been confused between the datetime module, and the datetime class inside that module. Why does datetime.now() not work? Oh, it’s because this file does import datetime, instead of from datetime import datetime. In my experience, this is a common point of frustration. This is also probably due to the fact that most people don’t realise that the datetime.datetime object is actually a class! All these tiny problems will get sorted out, if class da…

The sentiment was that this type of change in the stdlib has much more churn to cause in the ecosystem than benefits, since these are widely used features that may even predate PEP-8.

Libs, frameworks, projects in general would have to be adjusted to prepare for a possible future removal of the old names. Searches on the web would also be affected by redundancy and indirection of names between old and new content, which has a high potential for causing confusion in the public, specially newcomers.

There are other modules that suffer from the same inconsistency, such as logging, which would also be quite problematic to change. Once you change X, there will certainly be people who will demand that you also change Y.

There are things that are less painful to accept as “facts of life”

[strokirk (Dan Strokirk)]

Snake casing more methods in the standard library would be a good thing in my opinion, even if duplicate aliases would of course have to be kept around. The added consistency would help codebases look more clean, and it’s one less minor hump to remember for new programmers.

Especially when writing your own assertions, it currently introduces an choice: do I match the style of the unittest module and make my new assertion camelCase, or match the project styleguides and write it in snake_case? Either option doesn’t look great.

[Rosuav (Chris Angelico)]

@strokirk

Snake casing more methods in the standard library would be a good thing in my opinion, even if duplicate aliases would of course have to be kept around. The added consistency would help codebases look more clean, and it’s one less minor hump to remember for new programmers.

Yep. The downside is that all the consistency you gain across the stdlib is lost within the module, leading to questions like “should I use assertNotEqual or assert_not_equal?” - and the correct answer will be “use assertNotEqual, it works on all versions of Python”. There’s no easy way to do this, which is why PEP 8 specifically says:

In particular: do not break backwards compatibility just to comply with this PEP!

[vovavili (Vladimir)]

In my humble opinion, unless you really need to reduce dependency count, you might as well just use pytest, which just uses assert and decorators, no methods. Given that Python ecosystem has a much better alternative in every way, changing the naming of methods is just sprinkling glitter on an older fruit, instead of buying a fresh one. So there are basically two paths:

1. You work on a code base which already uses unittest CamelCase methods for its unit tests. Great, then for the sake of consistency it’s better that there is only one CamelCase way of naming methods, instead of raising confusion by potentially having CamelCase methods mixed with snake_case ones.

2. You work on a code base which does not have unit tests written yet. Then, why are you not using pytest?

[bittner (Peter Bittner)]

@vovavili

Then, why are you not using pytest?

Because the Python language and community deserves consistency.

It’s not about reasoning for personal projects, it’s for a better future. - Python has made my current present better (than what I had with other programming languages 20+ years ago). Why not invest in a better future today? I think that’s what drives most of “us” who speak for this topic.