Snake_case aliases to camelCased methods in unittest

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.


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


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?

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

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?

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.


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.

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

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

class MyTest(unittest.TestCase):

    def test_1(self):
    def test_2(self):
        with self.assert_raises(AttributeError):
if __name__ == '__main__':
1 Like

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

1 Like

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.

1 Like

Maybe this mythical Python 4.0?

1 Like

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.


7 posts were split to a new topic: Codecrumbs: deprecate and refactor code across library boundaries

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

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” :man_shrugging:

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.


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!


2 posts were merged into an existing topic: Codecrumbs: deprecate and refactor code across library boundaries

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?

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.