The syntax in the Command line documentation was unexpected regarding the `-m` option (specifically `python -mtimeit`) [0].  Showing this:

```
python -mtimeit "range(100)"
# behaving equivalent to this:
python -m timeit "range(100)"
```

This led me to discover many cases where command line arguments are like this in python (e.g. the call working correctly without a space between an argument flag and what is being passed into the command).  Like this:

```
python -c"print('Hi')"
# behaving the same as:
python -c "print('Hi')"
```

This is also the case with pip as well:

```
pip install -rrequirements.txt 
# behaving exactly like:
pip install -r requirements.txt
```

However, when I think of the *nix commands, like `rm`, this behavior fails.  When you want to pass several flags at once, you can either list them separately (e.g. `rm -f -i myfile.py`) or concatenate them together (e.g. `rm -fi myfile.py`), but `rm` fails if you try calling it without a space between the argument(s) and the file to be removed (e.g.`rm -fimyfile.py`).

I'm not sure whether this command line behavior in python is intentional, but it's not obvious as to why this is the case.

[0] https://docs.python.org/3/using/cmdline.html#cmdoption-m

That's an interesting question.  There is much prior art here dating back to the earliest days of Unix.  The Open Group Base Specification has a section dealing with the syntax of utility arguments with suggestions of when or when not a space between the option and the option argument is needed and how to document the difference, i.e.

[-c option_argument] vs [-f[option_argument]]
 
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_01

It looks like the Python man page already sort of uses this syntax but the Python Setup and Usage doc may have different conventions.  If someone wants to pursue this, they might check all the options and provide a PR with any needed updates to the man page and the doc page.  A change in behavior of the command option processing is probably not a good idea at this point unless there is some demonstrable error or ambiguity.