My 2c on the idea - I like this as a way to reduce friction a little for beginners who just want to see their web apps run and may not be comfortable enough to install something else. It would be nice to have a one-liner with no non-stdlib dependencies, like 'python -m SimpleHTTPServer' for running WSGI. But I probably won't be using it much: if you can type (say) 'pip install gunicorn' then 'gunicorn app' is ridiculously easy (not to specifically promote gunicorn, it's just an example).
On Thu, Mar 29, 2012 at 1:14 PM, Masklinn <[email protected]> wrote: > > On 2012-03-29, at 19:46 , PJ Eby wrote: > > * drop the ':' separator syntax, or else use os.pathsep so that it works > > properly on Windows (where ':' can denote a drive letter) > > Ah yes, I had not thought of that, this would be annoying and I don't > think the pathsep helps, since the script is an arbitrary path file it > can contain pathseps. A second — optional as well — positional parameter > would avoid that problem, would not be more typing and would remove the > need for some of the munging in the type callable. > > But now that'd look weird with -m module, unless `-m` is not an > option-with-value but a boolean flag saying to treat the first > positional parameter as a module instead of a script. 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. But aside from that, I really hope os.pathsep won't be used, because then we will have a format for naming a WSGI app object which not only differs from established practice, but (worse) depends on the platform in a non-obvious way (i.e., not just like using os.sep when specifying paths on platform-specific file system, which is normal for people who type out file paths) As I understand (please correct me if I'm wrong), the big obvious problem for Windows is that simply splitting on ':' will do something dumb if the path is something like 'C:\app.py' or 'D:\work\company.apps:foo'. That parsing issue can be worked around for normal cases, but the ambiguous corner cases like 'c:app' are confusing (that could be either a file 'app' on the root of the C: drive, or a callable named 'app' in the module c - unfortunately the \ is not required to specify the root). So if you want to both keep the colon and want to accept all strings which DOS would accept before the colon, you must disambiguate which one you want to parse. But if you can part with the colon OR with the 'c:app' corner case, it can be managed. Here are some alternative suggestions, in case they are helpful. (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) (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 (C) make an executive decision to interpret 'c:app' as object 'app' in module 'c', require roots to be specified like 'c:\', and split from the rightmost : not trailed by \. I believe this only makes a problem in the incredibly specific pathological case where a DOS-savvy windows user is trying to serve a file without an extension directly out of root, while naming root unusually without using the conventional \. and that rare case would generally just generate a 'huh?' - with the exception that the diabolical user made single-letter modules with the same letters as drives and dumped them on PYTHONPATH... I think this would work, just be more complex than the (A) and (B) solution which seems to jibe more with the rest of Python. but if you want to allow files to be specified freely in the same spot that modules might be specified... (D) give up colon: first arg is a filepath-or-pythonmodulepath, and use something like --name=app (defaults to 'application' if not specified) to add the app name to look for in the module... I'm not too keen on this, it is almost as much extra typing as 'pip install' for a very typical case. The colon is nice because it's one keystroke and you can expect to use it (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)? _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
