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

[random832 at fastmail.us]

On Fri, Aug 14, 2015, at 05:32, Kef Schecter wrote:
> 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, "C:\Some Directory With Spaces\*.txt" is a valid wildcard for most
Windows programs.

> 2. Specify some kind of escaping mechanism; for example,
>    ``\[foo\].txt`` would refer to a file that has ``[`` and ``]`` in
>    its filename.  This may not be intuitive behavior for Windows
>    users.

Especially if you're using backslash for quoting - how do you
differentiate it from backslash as a directory separator? Vim manages,
but it's a bit headache-inducing to look at.

> 3. Keep glob.glob's standard functionality.  Programs using this
>    feature will not be able to operate on files that have square
>    brackets in their names.

I actually think #1 is the correct way, but it's worth noting that using
[[] for left bracket already works. This solution is also used in Vim
(even on Windows) and MS-SQL. Right bracket needs no escaping since it's
outside brackets to begin with (but you can if you want). You can even
quote * and ? that way (filenames won't have them on Windows, but can on
Unix).

> 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.

Speaking of least surprise... while _most_ of the quirks of Windows
wildcards are extremely obscure and can probably be safely ignored for
the purpose of this feature (my objection in the scandir discussion was
to relying on the _real_ Windows wildcard implementation in a
cross-platform function without explicitly documenting it, rather than
saying it needs to be emulated), the fact that you can use *.* to match
all files (including those that don't include a dot) and *. to match
only files that do not include a dot is well-known. Filenames on Windows
cannot actually end with a dot.