We Keep Coding

What parameter should I use instead of -m in Nohup

I used this command in the past python3 -m WebBot, but now I want to run my script using nohup.
What should I use instead of -m?

Bash path tab-complete for python -m

When you run a script, you usually do so as follows:
$ python path/to/script.py
However, when running a module, you run it as:
$ python -m path.to.module
It can sometimes be annoying to run a module from the command line because the . separators keep bash from being able to do tab-completion. Is there a custom tab-completion script out there that could handle this situation?

What is `-m` stands for in `python -m unittest`?

What is -m stands for in python -m unittest? The unittest unit testing framework has other command line options like -v -b -c -t but wondering what does -m stands for? Is it part of unittest or other python command line option?

if you run python --help you will see that:
-m mod : run library module as a script (terminates option list)
An explanation as to what that means and -m flage does can be found here, I have copied the important parts below:
Properly designed modules usually do nothing except set up stuff (e.g. functions and types you could import), but they usually won’t have any visible side effect. That’s why you can do import sys and nothing happens.
However, some modules may offer useful stuff when they are run from the command line. Examples for that include venv but also http.server or idlelib: All of those are regular modules that can be imported from other modules without side effects.
But when executed directly, they all do things (e.g. venv sets up a virtual environment, http.server runs a simple HTTP server, and idlelib runs IDLE). This is usually done with the following check:

Can't call py.test <module_name>.py from command line?

I'm using Python 3.3 on Win7, and I'm fairly new to testing and py.test.
I have a simple test to run, and although I can run it from the command line by calling
$ python -m pytest testing.py
when trying to call it with the simpler line
$ py.test testing.py
it returns:
'py.test' is not recognized as an internal or external command,
operable program, or batch file
Do I need to have the py.test source folder in the same location as my program, or am I doing something incorrectly?

The system is telling you:
py.test is not installed in a standard location. If you installed using pip or easy-install, it should be in /usr/local/bin or possibly /opt/bin depending on your flavour of Linux, and these should be on your path.
py.test has not been marked as executable.
You installed from source using setup.py and the directory containing py.test is not on your path, probably in or below your home directory.
Check for these possibilities, correct them if necessary and post the results of your efforts.

Above one is true.
Try to create a new virtual environment and do a new py.test
And check your python installation and path if the executable is accessible by terminal

pip install pytest==6.2.1
It worked for me.
pip install pytest== (any pytest version number)

Execute an installed Python package as a script?

Is there a way to enable a package to be executed as a script? For example:
[~]# easy_install /path/to/foo.egg
...
[~]# python -m foo --name World
Hello World
I've tried creating a __main__.py file inside my package but it's not being executed (I'm using Python 2.6). The following error is raised:
foo is a package and cannot be directly executed
The structure of my package is as follows:
foo/
setup.py
foo/
__init__.py
__main__.py
Running python -m foo.__main__ --name World works as expected, but I would prefer the former way of execution. Is this possible?

This is a regression in Python 2.6. See issue2571:
The ability to execute packages was never intended, since doing so
breaks imports in a variety of subtle ways. It was actually a bug in
2.5 that it was permitted at all, so 2.6 not only disabled it again, but also added a test to make sure it stays disabled (2.4 correctly
rejected it with an ImportError, just as 2.6 does).
You have a few options, you can either always run it specifying main:
$ python -m module.__main__
Or you can write a shell script wrapper that detects the python version and then executes it in the different style.
Or you can execute code on the command line that will import and then run the module, and then perhaps place that in a shell script:
$ python -c "import module; module.main()"
In my own command-line projects I have both the shell script that catches errors (python not being installed, etc.) but the shell script will also execute the import code and detect if the necessary modules have been installed and prompt an error (with a helpful link or install text).

I think this may be a limitation of Python 2.6. I've tested it, and executing a package (either in . or installed from an egg with easy_install) with the -m option works fine in 2.7, but not in 2.6. For example, on my system (Ubuntu) with a test package called pkg_exec in the current directory, and where __main__.py simply prints sys.argv:
xx#xx:~/tmp/pkg_exec$ python2.6 -m pkg_exec
/usr/bin/python2.6: pkg_exec is a package and cannot be directly executed
xx#xx:~/tmp/pkg_exec$ python2.7 -m pkg_exec
['/home/xx/tmp/pkg_exec/pkg_exec/__main__.py']
Also, according to the 2.7 docs:
Changed in version 2.7: Supply the package name to run a __main__ submodule.

Yes, you can do that if the script has the __main__ section.
Of course, you can't execute a package if it is a directory. But if you can run the script itself (say it starts with #!/usr/bin/python3 and you run it with ./script), you can choose another interpreter this way:
/bin/python2 -v ../path/to/my/script status
where -v is for the interpreter (if needed), and status is an argument for your script.

as long as the package is on the python path,
add at the end of the script.
if __name__ == "__main__":
call_script()
$ python -m module_name
will run the module e.g
python -m random