Comment 7 for bug 1442771

I see now how this happened. By making cidr an optional argument, it changed the way that positional arguments were parsed. This was not a concern when designing the change at the API level because a REST API doesn't have the concept of a positional argument. This is a concern only because the client allows arguments to be specified by position. This does indeed make things more fragile.

I think the proposed fix which would use the cidr argument for either cidr or prefixlen exposes too much ugliness to the end user. I find it confusing to have such a hybrid argument. It is a hack.

Unfortunately, given the constraints of argparse, I can't think of a solution that isn't a hack. But, I think we could come up with something that ends up presenting a nice clean interface to the end user.

My thought was to maybe do a little pre-processing of the args before argparse gets called. We could detect the ambiguity and edit args enough to provide argparse with a hint based on whether a cidr or a integer is being passed. Then, call argparse on the result. Thoughts?