On 11/11/21 9:35 PM, Christopher Barker wrote:

Matt del Valle wrote:

...

So perhaps we could narrow the scope of this down to just adding snake_case aliases to the logging and unittest modules [...]

The reason those are spelled that way is because they are ported from Java.

And IMHO that “Java flavor” is a bigger issue than just the names. It’s the whole structure. So if we’re going to touch those, let’s make a Pythonic API, with PEP 8 compliant names, instead :-)

Besides the names, what are the issues? And are those issues covered by pytest, etc? unittest is the first (and only) testing framework I have ever used, so any info is appreciated. -- ~Ethan~

On Fri, Nov 12, 2021, 1:39 AM Christopher Barker <pythonchb@gmail.com> wrote:

unittest is the first (and only) testing framework I have ever used, so

...

any info is appreciated.

Yes, I like Pytest a lot more.

I should really write this up someday, and I did write a bit about it on this list not too long ago.

So the really short version is:

Unittest requires a fair bit of boilerplate that adds no real functionality.

The assert* methods are only there to provide error reporting that can be done by introspection by the test runner (e.g. pytest)

It’s missing some really key features like paramatrized tests.

Give Pytest a try — I suspect you’ll like it.

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 :-)

-CHB

In my humble opinion, the only two valid reasons to use unittest are if you are writing tests for Python itself, or if you are operating in a locked down enterprise environment where PyPI is off-limits and you have to rely on the stdlib. All other cases should use pytest or something similar (or in a security-conscious environment, petition the appropriate people to evaluate and approve pytest).

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 < stephenjturnbull@gmail.com> 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 -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FJCXM4... Code of Conduct: http://python.org/psf/codeofconduct/

-- -Dr. Jon Crall (him)

On Sat, 13 Nov 2021 at 08:47, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:

A final comment: I wonder if you're being too conservative. It's true that generally we prefer small targeted modules in the stdlib, but everybody needs tests (even if they don't know it ;-), and there might be quite large audiences for the great majority of PyTest. So maybe we could get all of PyTest in (perhaps in a slimmed-down form without some of the redundant/deprecated functionality).

As I mentioned, I'm not a PyTest user (yet! :-), so I wouldn't be a good proponent for this. But I find the proposal exciting.

I love pytest, and I'm a happy user of it. But I've never wanted it in the stdlib. Because it's a developer tool, basically. As a developer, I'm perfectly fine having my tools installed in a per-project virtualenv, or set up as standalone commands via pipx, or whatever works best for my project. I don't need the full "developer experience" in the stdlib, because pip install works fine. And yes, I know that for some developers, access to PyPI isn't as easy as that (I've been in that position myself, many times!) but there are workarounds and hacks, which are fine if it's setting up stuff once on your dev machine. And having pytest able to change and innovate is important - if it became part of the stdlib, it would (of necessity) stagnate, and the role of innovator in testing tools would pass to someone else. **However**, the situation is completely different for packages that are used in applications that get shipped out to end users. And "applications" is a very broad term, that covers full standalone executables, web services, one-file scripts, Jupyter notebooks, etc. Python's story on building and deploying such applications is still pretty bad (and I say this as a packaging specialist!) We've focused on libraries at the cost of the final result, and as a consequence it's extremely easy to use packages from PyPI when developing your new application, but when you get round to deploying it, things get hard and you start wishing that the stuff you used was in the stdlib, because that would make things so much easier. So there's regular discussions about adding functionality to the stdlib, but it's *that* sort of package (requests, toml, bits of numpy, data structure libraries, etc), and not tools like pytest (or tox, hypothesis, nox, black, or flake8, ...) So basically, I don't think it's likely that a proposal to add pytest to the stdlib would get very far (it's fine as a PyPI package) but that's specific to pytest, and as a general principle, "it's on PyPI so it doesn't need to be in the stdlib" *doesn't* apply, and won't until we have a better deployment story for Python tools. Paul