[Python-ideas] Add OS-dependent automatic glob support

[Andrew Barnert]

It seems to me that if you want auto-globbing support on Windows, the "right" way to do it is to link in the fancy setargv instead of the default one. This handles wildcards exactly the same way the command.com/cmd.exe builtin commands do, which I suspect is what Windows users would actually be expecting of they passed a wildcard on the command line. (I think the docs no longer guarantee that this is true, but it's probably still true, and certainly closer to true than if you try to do it manually.)

The only problem is that you can't add a command-line switch that controls at runtime which implementation of setargv got linked into the msvcrt prequel at build time. There used to be a way around this for DOS/Win16 programs, but I don't think there is for NT/Win32 (short of ignoring the argv and asking for and parsing the command line instead), so this would be an all-or-nothing change. Are there programs that depend on _not_ having auto-globbing on Windows? There might be...

At any rate, I can't imagine many programs want POSIX (sh-style) globbing but without other POSIX shell features (at least the different split/quoting/escape rules, if not the various kinds of expansion, etc.); the only reason anyone calls glob.glob for Windows is because it's relatively easy (compared to using win32api to call FindFirstFile, or using win32api to get the whole command line and then using shlex and os to process it, depending on which one they actually wanted) and not _too_ terrible for simple cases. If there's a way to give people something that's not only easier but better, I don't think they'd complain.

Sent from a random iPhone

On Jan 5, 2015, at 5:19, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> Steven D'Aprano writes:
> 
>> In any case, having a platform specific globbing module
> 
> By "platform-specific", do you mean one module that handles all
> platforms appropriately (what this thread is about), or do you mean
> per-platform modules (what "platform-specific" means to me)?
> 
>> is looking more and more useful.  Does this need a PEP?
> 
> If you're really serious about putting it in the stdlib, I would
> certainly think so.  It's absolutely clear that the solution is going
> to be complicated and hard to understand.  Without a PEP, nobody will
> know what is and what is not a bug.  Likely even with a PEP a lot of
> people will claim the PEP is buggy no matter what it says!  I would
> hope the different specs will partition the complainers, but I'm not
> even sure of that. ;-)
> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/