classification
Title: pyunit script as shorthand for python -m unittest
Type: Stage: resolved
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: michael.foord Nosy List: asvetlov, barry, berker.peksag, cheryl.sabella, eric.araujo, hieu.nguyen, michael.foord, ned.deily, pitrou, tshepang
Priority: normal Keywords: patch

Created on 2012-03-12 21:00 by michael.foord, last changed 2018-07-31 09:17 by berker.peksag. This issue is now closed.

Files
File name Uploaded Description Edit
issue14266.diff berker.peksag, 2012-12-12 13:24
Messages (16)
msg155476 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2012-03-12 21:00
"python -m unittest ..." is a pain to type. A "pyunit" script would be a nice shorthand. (unittest2 has a unit2 script that does this.)
msg155477 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-03-12 21:03
And it should do "discover" by default, IMO (like nose does).
msg155479 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2012-03-12 21:05
Right "unit2" on its own does discover by default now. (On head, not sure if that's released yet.)
msg174405 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-11-01 12:06
+1 for both pyunit script and autodiscovering by default.
msg174905 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-11-05 13:08
Is it should be separate binary? 
Or problem can be solved by regular python script with executable bit? What's about Windows?
msg174907 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2012-11-05 13:11
A python script should be fine - this is what unittest2 does and I haven't had any requests from Windows users for a binary.
msg177426 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-12-13 17:15
Yes, let’s keep the pydoc/pyvenv/etc convention for pyunit.  The audience is developers, whom we expect to be able to set up their environment correctly, and the -m fallback still works.
msg177549 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-12-15 19:05
Berker's proposed implementation looks weird to me. Why the "__unittest" variable?
Also, it would be better to make unittest's API more flexible, rather than manually tweaking sys.argv to enable discovery.
msg177564 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-12-15 21:03
I think the __unittest name is magic to hide modules from the unittest package in error/failure tracebacks.

About the script: can’t it be as simple as runpy.run_module?
msg177748 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2012-12-19 15:47
Antoine and Éric: Thank you for the reviews and suggestions.

> Why the "__unittest" variable?

I added the "__unittest" variable after read issue 7815 and the related
changeset: http://hg.python.org/cpython/rev/2858cae540e4/

See also:
- http://stackoverflow.com/questions/12583015/how-can-i-hide-my-stack-frames-in-a-testcase-subclass
- https://github.com/nose-devs/nose2/pull/28/files

However, without the variable tracebacks are still clear:

$ pyunit -v
test_acc (test_bar.TestAcc) ... ok
test_acc_negative (test_bar.TestAccNegative) ... ok
test_mul (test_foo.TestMul) ... ok
test_mul_negative (test_foo.TestMulNegative) ... ok
test_mul (test_baz.TestMul) ... FAIL

======================================================================
FAIL: test_mul (test_baz.TestMul)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/hacking/cpython/test_baz.py", line 12, in test_mul
    self.assertEqual(3, mul(2, 2))
AssertionError: 3 != 4

----------------------------------------------------------------------
Ran 5 tests in 0.002s

FAILED (failures=1)

> Also, it would be better to make unittest's API more flexible, rather
> than manually tweaking sys.argv to enable discovery.

You're right. Something like that? unittest.main(discover=True)

> About the script: can’t it be as simple as runpy.run_module?

I will try that, thanks.
msg183489 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2013-03-04 19:38
As I mentioned on python-dev, having a `pyunit` script is nice (whatever it's called), but we need to keep the `-m invocation` which will probably be the recommendation on distros such as Debian which provide multiple versions of Python.  We're not going to want to install all possible flavors of `pyunit2.6`, `pyunit2.7`, `punit2.6-dbg`, `pyunit-3.2-dbg`, etc. etc.
msg183491 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2013-03-04 19:45
> We're not going to want to install all possible flavors of
> `pyunit2.6`, `pyunit2.7`, `punit2.6-dbg`, `pyunit-3.2-dbg`, etc. etc.

Why not?
msg183495 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2013-03-04 20:09
On Mar 04, 2013, at 07:45 PM, Antoine Pitrou wrote:

>
>Antoine Pitrou added the comment:
>
>> We're not going to want to install all possible flavors of
>> `pyunit2.6`, `pyunit2.7`, `punit2.6-dbg`, `pyunit-3.2-dbg`, etc. etc.
>
>Why not?

We don't know at package build time which versions will be necessary or
possible, since that depends on the user's system on which the package will be
installed.  So we can't add those files to the package manifest.  They could
be installed dynamically by a maintainer script (that gets triggered at
package installation time) but that's less than ideal because then we'll need
to also add machinery to properly track deletions so that when they're
dependencies get removed we can remove the scripts too.  This is something
that's very much frowned upon in Debian, especially for /usr/bin scripts.
msg313222 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2018-03-04 22:26
Is there still interest in this?  Should it be converted to a PR for 3.8?
msg313223 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-03-04 22:34
-0.5.  I have mixed feelings about this.  While I can see the utility of it, I think more recently we have been moving away from the concept of installed scripts for standard library features primarily because they are difficult to manage when there are multiple versions of Python installed and with virtual environments.  Speaking of which, how would this work in practice within venvs? And how would it work with the Windows launcher, py?
msg322398 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2018-07-26 05:54
I agree with Ned. I've been using "python -m foo" instead of "foo" more in the past few years.

pyvenv has been deprecated in Python 3.6 and its documentation now uses "python -m venv".

+1 for closing this as "rejected".
History
Date User Action Args
2018-07-31 09:17:48berker.peksagsetstatus: open -> closed
stage: patch review -> resolved
2018-07-31 08:58:22michael.foordsetresolution: rejected
2018-07-26 05:54:38berker.peksagsetmessages: + msg322398
2018-03-04 22:34:43ned.deilysetnosy: + ned.deily
messages: + msg313223
2018-03-04 22:26:01cheryl.sabellasetnosy: + cheryl.sabella
messages: + msg313222
2013-03-04 20:48:53tshepangsetnosy: + tshepang
2013-03-04 20:09:46barrysetmessages: + msg183495
2013-03-04 19:45:01pitrousetmessages: + msg183491
2013-03-04 19:38:02barrysetmessages: + msg183489
2013-03-04 19:35:52barrysetnosy: + barry
2012-12-19 15:48:01berker.peksagsetmessages: + msg177748
2012-12-15 21:03:53eric.araujosetmessages: + msg177564
2012-12-15 19:05:47pitrousetmessages: + msg177549
stage: needs patch -> patch review
2012-12-13 17:15:36eric.araujosetnosy: + eric.araujo
messages: + msg177426
2012-12-12 13:24:16berker.peksagsetfiles: + issue14266.diff
nosy: + berker.peksag

keywords: + patch
versions: + Python 3.4, - Python 3.3
2012-11-05 13:11:56michael.foordsetmessages: + msg174907
2012-11-05 13:08:13asvetlovsetmessages: + msg174905
2012-11-01 12:06:30asvetlovsetnosy: + asvetlov
messages: + msg174405
2012-10-25 22:59:10hieu.nguyensetnosy: + hieu.nguyen
2012-03-12 21:05:48michael.foordsetmessages: + msg155479
2012-03-12 21:03:17pitrousetnosy: + pitrou
messages: + msg155477
2012-03-12 21:00:36michael.foordcreate