I feel like a much better future would be drafting a PEP which adds pytest-style unit tests to stdlib 
Either way, the cost is the same (the previous way of CamelCase unittest methods would be considered as “un-Pythonic”), but the benefit of change would be much larger.
1 Like
In my own experience, in spite of not belonging to the stdlib, pytest is closer to being the one true go-to tool than unittest.
4 Likes
Sure, I agree. It feels more “pythonic”, if you want so.
The point is, though, that the unittest module is part of the standard library, which gives (newcomers) a feeling that it’s the endorsed go-to solution. And it’s not, if you want to write pythonic code. That hurts!
That’s why it were great to get the code style fixed. We shouldn’t care about PEP8 religion and counter-religion. Python as a welcoming, consistent environment is at stake. That’s it, nothing more.
1 Like
Seriously? Are you saying that Python as a language seems unwelcoming, simply because one of the standard library modules follows a different naming convention? Yes, it’s a point of friction, but isn’t this overblowing the problem just a bit?
Ignoring the exaggerated rhetoric, there’s an important point that people are missing. Changing the unittest module will impact all projects that currently use it for testing, requiring them to spend effort that could be spent elsewhere, simply making cosmetic changes. And they need to test those changes to make sure they got them right - which involves testing your test suite, which is a further complication (especially for projects with complex test infrastructures).
And one project that is a heavy user of unittest is CPython itself. So making this change would have a double cost to the CPython project. Probably even more, as I suspect that the tests for the unittest module itself would be even more complex to update than the average test module…
All of that would suck up resources and effort that could have been spent on adding new features to the language, or improving performance, or simply fixing existing bugs. Is changing from one arbitrary naming convention to another, simply for the sake of “consistency” really worth that cost?
Edit: Before someone says that by having aliases, there’s no need to change, doesn’t that pretty fundamentally ruin the point of the exercise? If CPython itself doesn’t use the recommended forms, what sort of message does that give?
I’m not a native speaker. Maybe “is at stake” is too strong as a statement.
Just wanted to support others’ opinion, because the discussion seemed a bit unbalanced to me.
1 Like
This feeling is the actual problem, not unittest’s naming conventions. The solution is not to revise unittest but to nudge the ecosystem towards pytest while keeping unittest for backwards compatibility. It’s mostly a social problem.
It is widely agreed upon by now that the “batteries included” principle has become more of a bottleneck than a feature. The challenge today is encouraging the use of certain third-party libraries in spite of their “unofficial” status. A similar situation exists with urllib vs requests and to a lesser extent re vs regex.
3 Likes
Hmm. Were you a core dev back when Python 2.6 was current? If not, we may need someone else to answer this: How was the transition from threading.currentThread() to threading.current_thread() handled? Was there pressure to convert the stdlib, or was it left untouched? This might be a special case, though, since 2.6 and 2.7 were both created with Python 3 in mind.
2 Likes
Your reasoning is still flawed. The CPython project could work with solutions that people have presented in this thread. The risk can be contained, the “unneeded effort” spent by people that are willing to do that for free. The real question is: Do we find enough people - in power at CPython - that are willing to invest in making Python more beautiful?
It’s a huge point of friction. It looks ugly. That’s why it hurts. We could easily leave it like this, but it just makes Python less beautiful. Period.
We love Python! That’s why a change like this is being asked for. How good is pragmatic reasoning when what we talk about is really love and passion? (Agreed, I exaggerate, slightly.)
Tone down how you’re providing feedback. It comes off very strongly as “my point of view is right, you’re bad for assuming otherwise”, regardless of your actual intention.
This reads as saying that they don’t know what they’re talking about and are not willing to invest in making Python better, which is completely untrue. It also assumes some quality of “beauty” that is standardized and required, which is not the case.
These are strongly worded statements, and your exaggeration is not helping move the conversation productively. Better would be “I find this difficult because…” and “I’d prefer if it looks like this because…”
This is basically shutting down further conversation by implying that others who do not share your viewpoint do not care, are not considered in their reasoning, and are not equally passionate about Python.
Leave this sort of rhetoric out and stick to technical discussion.
2 Likes
“Practicality beats purity.”
Cf. also the PEP 8 quote I linked to earlier.
I was around, but I don’t recall there being much fuss. It was a much smaller change than the one proposed here, of course, and is used far less extensively than unittest. So I’m not surprised if it wasn’t particularly difficult.
I’m not saying we couldn’t change unittest, and even sort out a reasonable transition. Just that the cost would be massive, and the benefits rather limited - most of the suggested benefits here have been pretty intangible, and often subjective. That’s not to dismiss them, but it’s hard to measure such benefits against a huge implementation cost and say that it’s worth it.
And we have pytest, what’s wrong with that? People seem to have no problem using requests or httpx rather than the stdlib urllib.request - why isn’t it just as reasonable to view unittest and pytest in the same light?
2 Likes
Yes, I was. I can assure you that making a change to the threading module has vastly less impact than changing unittest. And as @pf_moore said, and I hinted at earlier, testing your tests makes this much more difficult, too.
Did we immediately change the stdlib to use the new method name? Frankly I don’t recall. But in my opinion changing currentThread() to current_thread() was a mistake, even if the churn was small. I think we wouldn’t be so quick to make that change today.
I think adding something like pytest to the stdlib would be a mistake. Updates would only get made once a year, and new features aren’t typically backported (though we could make an exception).
In my opinion, unittest’s main purpose today is to have a way to test the stdlib. I also use it for very small projects when I’m trying to minimize dependencies. For other cases, pytest is likely a better fit.
3 Likes
Thanks Eric and Paul for these insights. This is exactly the sort of thing this thread needs: a case study (albeit anecdotal) from a previous situation where the same thing was considered.
3 Likes
Jean’s explanation absolutely hits the nail. Has there been any progress to this regard?
What is the state of moving off the “batteries included” approach, in general? Has anyone ever suggested to remove unittest from the standard library, say via a PEP?
unittest wouldn’t be removed from the stdlib, since it’s used to test the stdlib. At best it could be renamed to “_unittest”, but it wouldn’t be worth the hassle.
2 Likes
Is that good enough of a justification to ship it with the standard library? – Isn’t the standard library “the product” and unittest just part of the toolchain? One could argue that also Make would need to be shipped with the standard library. 
I’m not trying to be polemic, just trying to get the full picture. Would a unittest package on PyPI maybe be good enough, one day?
It’s theoretically possible to do, but a huge amount of work. I wouldn’t stand in the way of someone trying to do it.
unittest is far too widely used to consider removing from the stdlib.
Searching the top 8k projects on PyPI (downloaded 2023-11-22):
-
import unittest: Found 20,621 matching lines in 1,978 projects -
import pytest: Found 37,244 matching lines in 2344 projects
And many project don’t ship tests in their sdists, so actual usage will be much higher.
Plus, in the last Python Developers Survey, 24% of respondents said they use unittest (out of 65% who use any test framework):
3 Likes
It has wide usage in the academic world, not just limited to Python. Renaming its method would create inconsistency with similar frameworks in other programming languages. It would be better to create another framework from scratch rather than ‘editing’ unittest.
And this framework already exists—‘pytest.’ So, let unittest be.
2 Likes