On Thu, Mar 29, 2012 at 4:16 PM, Sasha Hart <s...@sashahart.net> wrote:
> If the colon can be made safe for Windows it might be desirable, since > it looks fine and reflects existing practice in a number of places. > For *modules*, yes. For scripts, no. But for module names, there's no conflict. > (A) accept only one of the two types of input at all (e.g. insist only > on importable module name - it looks like this is what gunicorn does > and I like it a lot - short of having your code installed on system > PYTHONPATH, or using virtualenv PYTHONPATH, you can also do this if > you are in the directory of the script/package) > This would tend to be my preference, if we don't support both. > (B) use --file=c:\app.py or similar to disambiguate what kind of > parsing to do - then the typical case can be the importable and users > who really want to refer to files explicitly can do so > This is my preference if we do support both - to explicitly separate modules from scripts somehow. (E) give up colon: first arg is a filepath-or-pythonmodulepath, and > optional second arg is what would have come after the colon. I think > this is your suggestion and it's not unreasonable at all. If we are > talking about 'python -m wsgiref.simple_server c:app app' then the > second positional arg is definitely not the weirdest looking part. I > just question whether it's really necessary - why not either drop the > implicit specification of a filename (A/B) or enforce backslash after > root on windows (C)? I don't like accepting both scripts and modules without an explicit marking as to which you're providing. People confuse the two concepts enough already.
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
