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.
I have no problem with getting pytest from PyPi for my projects.
But there are two use cases where that’s less than ideal:
1) The Python standard library itself needs tests. Granted, I suppose the stdlib could use a third party package for testing without shipping it in the stdlib, but no one seems to want to do that at this point.
2) newbies and the community— why is unittest in the stdlib if it’s not the best option??
Personally, In my intro to Python class, I do have my students install Pytest early on and start using it well before I tell them about anything about unittest.
There are two reasons for that:
1) I really think pytest is the better way to go.
2) I introduce unit testing and TDD really early — before classes. So being able to write tests with simple functions is a real win.
But I’m guessing that’s not a very common approach. It really is confusing to the community to have a not-recommended unittest framework in the stdlib.
Granted, it’s only my opinion that it’s “not recommended”, so maybe there is no problem to be solved, but my point is that “just keep it on PyPi” is not really a satisfactory solution, IF unittest is not the recommend way to write tests for Python.
Oh, point 3) I think it was Ethan that said he’d never used pytest. He’s been very active in this community a long time! So clearly having something in the stdlib is very influential.
Anyway — this really needs another thread if we want to continue the discussion.
-CHB
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
_______________________________________________
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/KZEZ2QHR5V6QIHD7QQM75F7I2724JTKN/
Code of Conduct: http://python.org/psf/codeofconduct/