Quoting Raymond Hettinger <python at rcn.com>: > The combination of batch file and run.py isn't as good as the -m option, > but it works and mostly meets my needs. The batch file is rather dumb, > doesn't work with other python command line options, and won't work > pipes. Hmm, that point about command line options is a good one. I know I'd find it handy to be able to throw in a '-i' when I wanted one. Then again for commands with minor variations, I tend to rely on command line history rather than using a batch file (that is, I'll type out a long invocation sequence once a session, then edit it as needed) > Could Nick's idea be done without an -m option? To be fair to Ilya - his idea, my implementation :) > If a user types, > "python abc.py" and "abc.py" is not found, before aborting, try looking > for it on sys.path. That's do-able, but the command line option seems cleaner if the interpreter is going to provide C-level support for this. I interpreted Guido's last message as saying he's prepared to tolerate the command line option if there's sufficient support for it. To summarise the differences between the two approaches: Pros (-m over runpy.py, in order of significance as I see it): - easy to combine with other Python command line options - OS & environment independent - easier to use with a non-installed interpreter - no work for Python packaging folks - more concise to invoke - no namespace issues with naming a script - C API for those embedding python Cons: - YACLO (Yet Another Command Line Option) - CPython specific (other interpreters could choose to reimplement) With YACLO seeming to be Guido's main reason for being -0 on the idea. It looks like the script option would require input from those with better knowledge than me of the packaging set up for Windows, *nix and Mac as to how it could be made to work 'nicely' in each environment. And the issue of combining it with other command line options would remain. It's all very well to have "runpy.py" as an executable script, but providing extra options to the interpreter would require: 1. Locate runpy.py (e.g. /usr/bin/local/runpy.py, /usr/bin/runpy.py) 2. Invoke python <options> <dir>/runpy.py <module> Which means we're back to having to find out where at least part of the Python installation lives on each machine (only once per machine, which is an improvement over the status quo, but still not as tidy as a single command line option). I find that persuasive enough that I think it's worthwhile to finish the '-m' patch, and add a documentation patch. Regards, Nick. -- Nick Coghlan Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4