Ah, that’s a pretty serious looking collection of tips. And “Automate
the Boring Stuff” has a good reputation.
By documentation, I mean the official Python documentation 3.11.3 Documentation.
Right.
Look, using a cheat sheet to find out how one might typically perform
common things in Python is reasonable, particularly if you’re new to
Python. But you then need to go to the documentation to read the
specifics of how the things in the cheat sheet actually work.
Note that the index can be a good place to start with the documentation
when you’re trying to look up something specific; I often go there to
find the relevant place in the main documentation.
What index? general, global? there are so many index, all of them?
Since we’re talking about the main Python docs, this index: https://docs.python.org/3/genindex.html
Of course it helps to have a word or function name in mind to use this.
I really wish that I could show you the bash script so that you could
point me in the direction of specific documentation.
What standard library documentation should I focus on, other than os, subprocess, for converting from bash to Python?
That depends on the script. Most scripts exist to orchestrate other
commands, so if you’re not literally running those same commands you
need to know what the purpose of the script is. Which should be
apparent.
Optional:
Should I focus on KISS so I don’t have to worry about exception
handling?
Actually, broadly, YES. A lot of new Python programmers try to catch all
exceptions, but the basic rule of thumb with exceptions is to only catch
the specific ones you expect and know how to handle.
This is the pseudocode. Do you have any suggestions or can you point me to any specific documentation I should focus on?
# Execute a command to restart the server.
# Check if the expected string is in the output of a command.
# If true, execute the command.
# Otherwise, abort the script.
# -u argument type: int
# -R argument type: boolean
# -A argument type: boolean
# -r argument type: boolean
# -t argument type: boolean
# -l argument type: boolean
# -s argument type: boolean
# -d argument type: boolean
# Check if arguments -R and -A
# or arguments -r and -t
# are both true? If so, abort.
# Ask if the user is ready to continue.
# If not, ask for a new value for the -u argument.
# Capture keyboard interrupt to abort
# Execute a command for arguments R to d.
# Execute a command to stop the server.
You could make a Command Line Interface (CLI) around this logic. Based on your description, it might behave something like this:
% ./server.py --help
usage: server.py [-h] [-u VALUE] [-R] [-A] [-r] [-t] [-l] [-s] [-d] [-v]
optional arguments:
-h, --help show this help message and exit
-u VALUE an int. default: 0
-R dont use with -A
-A dont use with -R
-r dont use with -t
-t dont use with -r
-l ...
-s ...
-d ...
-v, --verbose set verbosity level
You’d need these refs:
argparse: to make a clean CLI (not required, but nice)
subprocess: to run system-level commands, e.g. subprocess.run()
So I forgot to add picking a random line from a file. I want to use the secret module and I know it’s an overkill but I want the randomization to be as random as possible, can I do that?
# Pick a random line from the --file argument
# and store the string in a variable.
# Use the variable as an argument to the -r command.
# Execute a command to restart the server.
# Check to see if the expected string is in the output of a command.
# If false, execute the command.
# -f --file argument type: str
# -u argument type: int
# -R argument type: boolean
# -A argument type: boolean
# -r argument type: boolean
# -t argument type: boolean
# -l argument type: boolean
# -s argument type: boolean
# -d argument type: boolean
# Check if arguments -R and -A
# or arguments -r and -t
# are both true? If so, abort.
# Ask if the user is ready to continue.
# If not, ask for a new value for the -u argument.
# Capture keyboard interrupt to abort
# Pick a random line from the --file argument
# and store the string in a variable.
# Use the variable as an argument to the -r command.
# Execute a command for arguments R to d.
# Execute a command to stop the server.
Do I need to worry about the validation of the file such as permission or file exist error?
Duncan Booth’s suggestion was that I should use framework instead because “It saves on a whole lot of boilerplate code that you’d get using something like ArgParse”. Do you have an opinion on this?
I forgot to ask him about the boilerplate code, what is it all about?
Sure, if random.choice is not enough, you can use secrets. The secrets docs has a recipe on how to work with it.
Do I need to worry about the validation of the file such as permission or file exist error?
Generally no, but I’m not sure what kinds of files you’re working with. Some exception handling should cover that. Example:
filepath = pathlib.Path("/path/to/file.txt")
try:
# Code you think might throw an error
filepath.touch()
except PermissionError:
# Do something else
...
except FileNotExistError:
# Do something else
...
else:
# If no errors, the rest of you code
...
Or more simply test if files exists:
if not filepath.exists():
# Do something
return 1
Duncan Booth’s suggestion was that I should use framework instead because “It saves on a whole lot of boilerplate code that you’d get using something like ArgParse”. Do you have an opinion on this?
I certainly used to have the same opinion, and many libraries do save on typing a bunch of starter code (boilerplate). argparse can be a bit overwhelming at first, so those libraries are nice alternatives to the breadth of options argparse provides. I’ve edited the links in my last post with 2 guides that really clarified how to tame argparse. I recommend taking a look at the new links.
Opinion: if writing/testing scripts is not something you plan to get into, then a library might save you some time. Otherwise, I’d “go lean” using what’s in the standard lib.
I’m also a fan of docopt and its philosophy of generating a CLI from a docstring. I found it did not scale with my personal projects, but new users may discover it’s good enough.
Note: the original docopt project is no longer maintained. docopt-ng is a newer project with active maintenance.