[prev in list] [next in list] [prev in thread] [next in thread]
List: python-ideas
Subject: [Python-ideas] Re: Adding pep-8-casing-compliant aliases for unittest and logging
From: Christopher Barker <pythonchb () gmail ! com>
Date: 2021-11-13 17:52:47
Message-ID: CALn7ch8fAmfEz7+Vrjz9yk74HjKOvtS-SmObiKT9va+QUjURcQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Nov 13, 2021 at 3:52 AM Paul Moore <p.f.moore@gmail.com> wrote:
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/
>
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
[Attachment #5 (text/html)]
<div>On Sat, Nov 13, 2021 at 3:52 AM Paul Moore <<a \
href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:</div><div \
dir="auto"><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" \
dir="auto"> I love pytest, and I'm a happy user of it. But I've never wanted \
it in<br> the stdlib. Because it's a developer tool, basically. </blockquote><div \
dir="auto"><br></div><div dir="auto">I have no problem with getting pytest from PyPi \
for my projects.</div><div dir="auto"><br></div><div dir="auto">But there are two use \
cases where that's less than ideal:</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div \
dir="auto">2) newbies and the community— why is unittest in the stdlib if it's not \
the best option?? </div><div dir="auto"><br></div><div dir="auto">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.</div><div \
dir="auto"><br></div><div dir="auto">There are two reasons for that:</div><div \
dir="auto"><br></div><div dir="auto">1) I really think pytest is the better way to \
go. </div><div dir="auto"><br></div><div dir="auto">2) I introduce unit testing and \
TDD really early — before classes. So being able to write tests with simple \
functions is a real win. </div><div dir="auto"><br></div><div dir="auto">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. </div><div \
dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div \
dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Anyway — \
this really needs another thread if we want to continue the discussion.</div><div \
dir="auto"><br></div><div dir="auto">-CHB </div><div dir="auto"><br></div><div \
dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)" \
dir="auto">As a developer,<br> I'm perfectly fine having my tools installed in a \
per-project<br> virtualenv, or set up as standalone commands via pipx, or \
whatever<br> works best for my project. I don't need the full "developer<br>
experience" in the stdlib, because pip install works fine. And yes, I<br>
know that for some developers, access to PyPI isn't as easy as that<br>
(I've been in that position myself, many times!) but there are<br>
workarounds and hacks, which are fine if it's setting up stuff once on<br>
your dev machine.<br>
<br>
And having pytest able to change and innovate is important - if it<br>
became part of the stdlib, it would (of necessity) stagnate, and the<br>
role of innovator in testing tools would pass to someone else.<br>
<br>
**However**, the situation is completely different for packages that<br>
are used in applications that get shipped out to end users. And<br>
"applications" is a very broad term, that covers full standalone<br>
executables, web services, one-file scripts, Jupyter notebooks, etc.<br>
<br>
Python's story on building and deploying such applications is still<br>
pretty bad (and I say this as a packaging specialist!) We've focused<br>
on libraries at the cost of the final result, and as a consequence<br>
it's extremely easy to use packages from PyPI when developing your new<br>
application, but when you get round to deploying it, things get hard<br>
and you start wishing that the stuff you used was in the stdlib,<br>
because that would make things so much easier. So there's regular<br>
discussions about adding functionality to the stdlib, but it's *that*<br>
sort of package (requests, toml, bits of numpy, data structure<br>
libraries, etc), and not tools like pytest (or tox, hypothesis, nox,<br>
black, or flake8, ...)<br>
<br>
So basically, I don't think it's likely that a proposal to add pytest<br>
to the stdlib would get very far (it's fine as a PyPI package) but<br>
that's specific to pytest, and as a general principle, "it's on PyPI<br>
so it doesn't need to be in the stdlib" *doesn't* apply, and \
won't<br> until we have a better deployment story for Python tools.<br>
<br>
Paul<br>
_______________________________________________<br>
Python-ideas mailing list -- <a href="mailto:python-ideas@python.org" \
target="_blank">python-ideas@python.org</a><br> To unsubscribe send an email to <a \
href="mailto:python-ideas-leave@python.org" \
target="_blank">python-ideas-leave@python.org</a><br> <a \
href="https://mail.python.org/mailman3/lists/python-ideas.python.org/" \
rel="noreferrer" target="_blank">https://mail.python.org/mailman3/lists/python-ideas.python.org/</a><br>
Message archived at <a \
href="https://mail.python.org/archives/list/python-ideas@python.org/message/KZEZ2QHR5V6QIHD7QQM75F7I2724JTKN/" \
rel="noreferrer" target="_blank">https://mail.python.org/archives/list/python-ideas@python.org/message/KZEZ2QHR5V6QIHD7QQM75F7I2724JTKN/</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" \
target="_blank">http://python.org/psf/codeofconduct/</a><br> \
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" \
data-smartmail="gmail_signature"><div dir="ltr">Christopher Barker, PhD \
(Chris)<br><br> Python Language Consulting<br> - Teaching<br> - Scientific \
Software Development<br> - Desktop GUI and Web Development<br> - wxPython, numpy, \
scipy, Cython<br></div></div>
_______________________________________________
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/JTKECRISGFDPXVPWTNYFOXJBH2VLSEEL/
Code of Conduct: http://python.org/psf/codeofconduct/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic