This is not a bug.
The 'PARSER' nargs choice is an implementation detail as a way to handle subparsers. The parser needs to know that the first value should be handled, but everything that follows will be handled by the subparser.
By using a subparser, you're effectively using 'PARSER', but it wouldn't make sense to allow 'PARSER' to be set directly as it only makes sense when used in conjunction with a subparser.
I've experimented with an argparse adaptation of profile.py:
parser = argparse.ArgumentParser(usage=usage)
parser.add_argument('-o', '--outfile', dest="outfile",
help="Save stats to <outfile>", metavar="path")
parser.add_argument('-s', '--sort', dest="sort",
help="Sort order when printing to stdout ...",
default=-1)
parser.add_argument('args', nargs=argparse.PARSER,
metavar="scriptfile [arg] ...")
# expect at least one positional, a py module
It is somewhat like subparsers, but without defined subparser choices. Or you could say that PARSER (A...) is to REMAINDER (...) as '+' is to '*'. It requires at least one argument. I could, just as well, have created two arguments, 'scriptfile' and 'args' (with '...').
I don't know if that is an argument for documenting it or not.
I don't think this use case is enough to justify documenting it, since this is not an intuitive meaning of the word PARSER. I think if we wanted to expose this for this kind of use case, we'd want to rename the constant (with an alias for backward compatibility), which would be an enhancement. I'm going to close this, but someone who wants this could open an enhancement request.