IMO (a subset of) pytest is the superior unit-testing framework. Just having functions prefixed with `test_` is easy and intuitive. It also works well with xdoctest, but I would use it even if that wasn't the case. (That being said, I think the current implementation of fixtures - where you can't easily make an instance of the object outside of the pytest framework - are an anti-pattern, and I will die on that hill).

As for logging, I would love a redesigned logging module. The main issues I have with the current one are: (1) I don't like being forced to put logging initialization at every entry point in my program/library, I wish there was a better way to do that, even though I can't think of what that is. (2) When I do enable logging I often get junk from other libraries using it that I don't need. (3) I want first-class support for instance-level logging objects that belong to a specific object instance, this can sort-of be done with the current interface, but it's a bit clunky.

But as to the original intent of this post, I agree with Stephen Turnbull that foolish pep8 consistency is not a big enough reason to touch the stdlib. And honestly, a better logger would likely be best handled by a third party library, at least for the initial phases of its development and field testing. If it got wide acceptance and was simple enough, perhaps making its way into the stdlib could be considered. But I don't think a good alternative even exists right now.

There is something to be said for replacing unittest with a better no-third-party solution, and I think pytest is a bit too big to bring into the stdlib. But perhaps a subset of it (pytest lite?) might be isolated and considered for inclusion down the line?

On Fri, Nov 12, 2021 at 7:49 AM Stephen J. Turnbull <> wrote:
Christopher Barker writes:

+1 to your earlier comment along the lines of "Java flavor is an issue
(sometimes) worth fixing, non-PEP8 identifiers is not."  (I do not
claim Chris signs on to my formulation, I'm riffing on his. ;-)

 > Note that a LOT of major projects dumped unittest years ago— first
 > for nose and now usually pytest. No one uses a third party library
 > for no reason :-)

I can't speak to PyTest, but Mailman uses tox and nose2 -- a lot -- as
well as doctests, and it's good enough that so far nobody has
suggested moving to something else.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

-Dr. Jon Crall (him)