[issue42572] Better path handling with argparse

Change by Raymond Hettinger : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue42572] Better path handling with argparse

Raymond Hettinger added the comment: New changeset 40b4c405f98f2d35835ef5d183f0327c0c55da6f by Miss Islington (bot) in branch '3.9': bpo-42572: Improve argparse docs for the type parameter. (GH-23849) (GH-23869)

[issue42572] Better path handling with argparse

Change by miss-islington : -- nosy: +miss-islington nosy_count: 5.0 -> 6.0 pull_requests: +22731 pull_request: https://github.com/python/cpython/pull/23869 ___ Python tracker

[issue42572] Better path handling with argparse

Raymond Hettinger added the comment: 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

[issue42572] Better path handling with argparse

Austin Scola added the comment: Thank you Raymond! I learned a few things by reading the proposed documentation updates. -- ___ Python tracker ___

[issue42572] Better path handling with argparse

Raymond Hettinger added the comment: 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.

[issue42572] Better path handling with argparse

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +22711 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23849 ___ Python tracker

[issue42572] Better path handling with argparse

paul j3 added the comment: 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

[issue42572] Better path handling with argparse

Austin Scola added the comment: 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

[issue42572] Better path handling with argparse

Raymond Hettinger added the comment: 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. -- assignee: -> rhettinger components: +Documentation -Library (Lib)

[issue42572] Better path handling with argparse

Eric V. Smith added the comment: 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:

[issue42572] Better path handling with argparse

paul j3 added the comment: 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

[issue42572] Better path handling with argparse

Xavier Morel added the comment: > 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

[issue42572] Better path handling with argparse

paul j3 added the comment: 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.

[issue42572] Better path handling with argparse

Austin Scola added the comment: 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. -- ___ Python tracker

[issue42572] Better path handling with argparse

Eric V. Smith added the comment: 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

[issue42572] Better path handling with argparse

Austin Scola added the comment: 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

[issue42572] Better path handling with argparse

Eric V. Smith added the comment: 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. -- nosy: +eric.smith

[issue42572] Better path handling with argparse

Change by Karthikeyan Singaravelan : -- nosy: +paul.j3, rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue42572] Better path handling with argparse

New submission from Austin Scola : 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`