[Python-Dev] Adding pep-8-casing-compliant aliases for unittest and logging
On 11/11/21 11:53 AM, Matt del Valle wrote:
Okay, so from the replies so far it looks like this is very quickly going into the 'never gonna happen' dumpster, so in the interests of salvaging *something* out of it:
[...]
I just dislike having to settle for 'it's what we've got'. With these two modules in particular, a lot of the arguments that have been made so far either don't apply or are not as strong (such as the confusion of having builtins.list, builtins.List and typing.List). Additionally, these are significantly more ancillary portions of the stdlib than the builtins, much less likely to cause as severe of a disruption (I personally don't believe a backward-compatible change like this which only adds aliases would be as disruptive as many people claim, but concede that that's subjective), and much less likely to have the implementation change so drastically as to want to change out types for factory functions or vice-versa.
So perhaps we could narrow the scope of this down to just adding snake_case aliases to the logging and unittest modules [...]
+1 I would happily change all my unittest and logging usage to snake case if those aliases existed. -- ~Ethan~
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 :-) -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
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~
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 -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Fri, Nov 12, 2021, 1:39 AM Christopher Barker
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).
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.
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)
Jonathan Crall writes:
But perhaps a subset of it (pytest lite?) might be isolated and considered for inclusion down the line?
*Anything* might be considered for inclusion, although Guido might dispose of it with a simple "please, no". That is not going to happen to your suggestion! :-) But somebody's got to do the work of identifying the subset, and coordinating with PyTest on whether they would use the subset in their more extended framework, and (one hopes) volunteer to maintain the module in the stdlib. There's also the issue of how mature PyTest is. If it's still gaining features at some pace, it probably doesn't want to be part of the stdlib yet. 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. Steve
On Sat, 13 Nov 2021 at 08:47, Stephen J. Turnbull
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
On Sat, Nov 13, 2021 at 3:52 AM Paul Moore
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/KZEZ2Q... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
участники (6)
-
Christopher Barker -
Ethan Furman -
Jonathan Crall -
Jonathan Goble -
Paul Moore -
Stephen J. Turnbull