"python -m unittest ..." is a pain to type. A "pyunit" script would be a nice shorthand. (unittest2 has a unit2 script that does this.)

And it should do "discover" by default, IMO (like nose does).

Right "unit2" on its own does discover by default now. (On head, not sure if that's released yet.)

+1 for both pyunit script and autodiscovering by default.

Is it should be separate binary? 
Or problem can be solved by regular python script with executable bit? What's about Windows?

A python script should be fine - this is what unittest2 does and I haven't had any requests from Windows users for a binary.

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.

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.

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?

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.

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.

> 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?

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.

Is there still interest in this?  Should it be converted to a PR for 3.8?

-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?

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".