[Python-ideas] Draft PEP: Automatic Globbing of Filenames in argparse on Windows

[Chris Angelico]

On Fri, Aug 14, 2015 at 7:32 PM, Kef Schecter <furrykef at gmail.com> wrote:
> PEP: XXX
> Title: Automatic Globbing of Filenames in argparse on Windows
>
> For many command-line tools, it is handy to be able to specify
> wildcards in order to operate on more than one file at a time.  On
> Unix-like systems, this is handled automatically by the shell.  On
> Windows, however, the default shell does not have this behavior, nor
> does Microsoft's PowerShell.
>
> Yet Windows users generally expect wildcards to work.  For example,
> most built-in commands such as ``dir`` and ``type`` accept wildcard
> arguments, and have since the early days of MS-DOS.

How does this interact with the 'fileinput' module? Can you tie in with that?

> How It Must Be Done Currently
> =============================
>
>     if platform.system() == 'Windows':
>         filenames = []
>         for filename in args.files:
>             if '*' in filename or '?' in filename or '[' in filename:
>                 filenames += glob.glob(filename)
>             else:
>                 filenames.append(filename)
>         args.files = filenames

Disgusting. :) Definitely needs to be buried away.

> Add a keyword argument to argparse.ArgumentParser.add_argument called
> ``glob``.  If it is true, it will automatically glob filenames using
> code much like the boilerplate code given earlier in `How It Must Be
> Done Currently`_. This argument is only meaningful when nargs is set
> to an appropriate value such as '+' or '*'.

+1

> A possibly better behavior might be to make this argument default to
> True (enabling the functionality automagically without the programmer
> needing to be aware of it) and only expand wildcard arguments that are
> not provided in quotes, similar to how Unix-like shells behave.
> However, there appears to be no simple way to tell whether an argument
> was supplied in quotes or not; the strings in sys.argv already have
> had the quotes removed.

-1. Since Windows users aren't generally used to escaping arguments
(eg compare Windows's "dir /s *.py" to Unix's "find . -name \*.py",
where the latter will be backslash-protected), I would advise against
glob expansion any time the program doesn't explicitly ask for it.

> 1. Use a version of glob.glob without the wildcard functionality that
>    ``[`` and ``]`` provide.  This type of wildcard has never been
>    standard for wildcard arguments to MS-DOS or Windows command-line
>    programs.
>
> Of these, the first should adhere best to the principle of least
> surprise.  Windows users do not expect square brackets to form
> wildcard expressions.  If they want such functionality, they will
> probably already be using a shell such as bash that handles it for
> them.

+1. It also shouldn't do any other form of expansion (eg braces) that
people wouldn't expect of a standard Windows command like dir or copy.

One other difference from glob.glob() that I'd recommend: If the spec
doesn't match any files, return it unchanged, as bash does. (glob.glob
will return an empty list.) Otherwise, sounds good to me - make it
easy to DTRT on all platforms.

ChrisA