CLI parameter order matters a bit too much in `listen.py`
Closed this issue · 2 comments
There are a couple important "global" parameters for listen.py that change the behavior of the Readers/Writers we create. Namely, --verbose, --encoding, and --network_eol. If you specify any of them AFTER specifying any readers or writers, the readers/writers get instantiated before the global parameters get parsed, resulting in very confused users.
Most other applications that do as much from the command line as listen.py does (at least, that I've used), allow for these types of parameters to be provided anywhere on the command line. You end up with parsing command line args as one complete step, then follow through in a 2nd block of code instantiating things once ALL the parameters have been parsed... So it would be a bit of a messy change for listen.py. Certainly doable, though.
It's bitten me once, so I'm sure it's going to happen to other users at some point.
Looking at this again w/ fresh eyeballs, this was mostly just "user error". I've read through all the argument parsing code, and the disclaimer note on the bottom of --help output, and retested. Looks like --verbose works fine wherever you put it (not sure why I thought it didn't), but --encoding and --network_eol have to come before the readers/writers they're for, which is exactly what the usage message says at the bottom. Ha.
That being said, I'd still argue that --encoding in particular needs to be specified exactly once and can't change between parsing segments. If you change encoding between them, you'll just make Python spit out TypeError: a bytes-like object is required, not 'str' on the very first input read().