One of the types of arguments that I find myself most often passing to `argparse.ArgumentParser` is paths. I think that I am probably not alone in frequent usage of paths as arguments. Given this, it would be extremely helpful to have an `argparse.Action` in `argparse` or an type similar to `FileType` that converted the string to a path. A path type factory could also have an arguments to optionally check if the path exists, or is a directory, or other similar predicates.

I think this would be a type, not an action.

I'm not sure this would pass the bar of something that should be added to the stdlib. But in any event, it should be developed on PyPI first, perhaps by adding it to argparse-types.

Hey Eric,

Thanks for the response. I'm unfamiliar with the process of adding features to the language. Would you mind explaining to me what some of the qualifications are for getting something added to the stdlib? And also what role packages on PyPI play in that process?

I am also willing (and interested) in helping out in implementing this, but I don't want to step on anyone's toes so if the offer for help is rejected I will not be upset.

Thanks!

Hi, Austin.

If it's something that can be implemented in a library (which this suggestion qualifies as), then we typically want to see it on PyPI and to gain some traction there. I only suggested argparse-types because it also has some argparse add-ons. But you could certainly make a new package on PyPI.

But even then I'm not sure this would make it into the stdlib. For add-on functionality we're usually happy to leave things on PyPI. On the other hand, paths are somewhat more fundamental than some of the things in argparse-types. You might want to bring it up on the python-ideas mailing list and see how much support you get there.

Awesome, thank you for the guidance Eric. I'll start a thread on the python-ideas mailing list, gauge the level of support, and go from there.

What exactly do you do with a path argument?

Admittedly I'm not expert with os and os.path modules, but isn't a path just a string passed to a function such as cwd(), or joined to another create a filename.

I don't know what a 'path' type or action would do.

> What exactly do you do with a path argument?

Because they mention "convert[ing] the string to a path", I would expect an output of `pathlib.Path`, optionally checked for existence / non-existence and / or kind (file, directory, symlink, ...).

Obviously it is rather easy to bring your own, but OP's expectation is that paths input is common enough (especially in smaller standalone scripts I would expect) that having a helper in a standard library would be... helpful.

The pathlib.Path is new since I paid much attention to os matters (I cut my teeth on py2.5).

Off hand it looks like the user could

    import pathlib
    parser.add_argument('-p', type=pathlib.Path)

to convert a string into a Path object.

A custom type function could call this, and apply any desired methods before returning the Path object. But that should be up to the user, not the `argparse` developers.

Importing path specific modules such as pathlib (which in turn has a lot of imports) goes against the attempt to reduce the number of unnecessary imports with modules like argparse.

https://bugs.python.org/issue30152
Reduce the number of imports for argparse

After this diet argparse still imports os, and uses:

    os.path.basename

I might also note that argparse has only one custom 'type' function, the FileType factory.  Other common type functions like 'int' and 'float' are Python builtin's.  Adding a custom 'bool' (to be used instead of the builtin 'bool') has been rejected.

https://bugs.python.org/issue37564

json, yaml, and datetime types have also been rejected
https://bugs.python.org/issue35005

The more I think about this, the more I think it shouldn't be in the stdlib. paul.j3 is correct that the simple case is just type=pathlib.Path.

For something more adventurous you could start with:

@dataclass(eq=True, frozen=True)
class ArgumentPath:
    must_exist: bool = False
    # Add other conditions as needed.

    def __call__(self, val):
        result = Path(val)
        if self.must_exist:
            if not result.exists():
                raise ValueError(f"path {result} must exist")
        return result

The reason I think this shouldn't be in the stdlib is that there are race conditions here between when you inspect the filesystem and when you'd actually use the path. What if the file was deleting, or it went from being a directory to a file?

I think the best advice is to use type=pathlib.Path, and handle anything else when you try to cd, or open, or whatever it is you're doing with the path.

It probably wouldn't hurt to document type=pathlib.Path in the argparse docs.

Agreed that we should not include new functionality here and instead just update the docs to show what can currently be done.

I'll write-up a documentation patch for this.

I think that type=pathlib.Path is probably all that I was looking for here. I was unaware types could be passed easily like that and so updated documentation would definitely be helpful. The predicates such as existence would just have been nice-to-haves, but not necessary (and eric.smith brings up a good point about race conditions).

One caution - the type parameter is a callable (function) that takes one string as argument.  I proposed `pathlib.Path` because it does that, returning a Path object.  It's a class instance creator.  I believe the module has other class initiators.

bool() has confused many users.  While it returns a bool class instance, True or False, the only string that returns False is the empty one, with argparse can't supply. It does not convert strings like 'False' or 'no' to boolean False.

Eric and Paul, I've attached a substantial rewrite of the docs for the *type* parameter:

* Document the exceptions that are handled.
* Show a wider range of examples that work with *type*.
* Discuss when *type* shouldn't be used:  bool, JSONDecoder, etc.
* Create a less whimsical example of a user-defined type converter.
* Explain the interaction between *type* and *default*.

Let me know what you think.

Thank you Raymond! I learned a few things by reading the proposed documentation updates.

New changeset b0398a4b7fb5743f6dbb72ac6b2926e0a0c11498 by Raymond Hettinger in branch 'master':
bpo-42572:  Improve argparse docs for the type parameter. (GH-23849)
https://github.com/python/cpython/commit/b0398a4b7fb5743f6dbb72ac6b2926e0a0c11498

New changeset 40b4c405f98f2d35835ef5d183f0327c0c55da6f by Miss Islington (bot) in branch '3.9':
bpo-42572:  Improve argparse docs for the type parameter. (GH-23849) (GH-23869)
https://github.com/python/cpython/commit/40b4c405f98f2d35835ef5d183f0327c0c55da6f