I am going to decline this feature request on the principle of keeping our modules loosely coupled and orthogonal to one another.  

As paul.j3 pointed out, the "type" option seems to work best with simple conversions like "int".  As pointed-out by another respondent, FileType hasn't aged well and it may have been a mistake to include it all.  Likewise other converters like DateTime have been previously discussed and rejected.

There is a gray area between where argument parsing stops and application logic begins.   Since this is a standard library module, we should draw the line at simple converters/validators like "int", leaving anything more complex for downstream logic.  That will afford users greater flexibility and control than supported by the add_argument() API which intentionally only handles common cases.

[Braden Groom]
> I agree with Paul. This is probably simple enough for applications
> to implement. It also doesn't make sense to add either of these
> if the precedent was set by rejecting DateTime previously.

I concur as well.

[Mauricio Villegas]
> FYI there is a new python package that extends argparse 
> with the enhancements proposed here and more.

Thank you for the link. It will likely prove to be a valuable resource for people finding this issue in the future.  The referenced project shows the value of external projects being able to go in directions that are well beyond the scope of our standard library module: "Not exclusively intended for parsing command line arguments. The main focus is parsing yaml or jsonnet configuration files and not necessarily from a command line tool."