On Fri, Mar 30, 2012 at 3:31 AM, Masklinn <maskl...@masklinn.net> wrote:
> On 2012-03-30, at 04:25 , PJ Eby wrote:
> >
> >> (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.
>
> Earlier I proposed a -m switch (inspired from Python), although the
> repetition of -m may be slightly weird I think it could work nicely.
>
> In either case, the colon separator would be removed and the
> application's variable name would be a positional following the
> script-or-module.
>
I am finding more reasons to dislike that -m:
python -m wsgiref.simple_server -m blog app
Beyond looking a little stuttery, it's really unclear. Anyone could be
forgiven for thinking that -m meant the same thing in both cases, took the
same kinds of arguments, could be exchanged for any other -m clause. But
wsgiref.simple_server is not at all doing what Python is doing so I see no
gain of understanding by reusing the convention. python -m doesn't take a
second positional argument, either. You can't write '-m blog app -m
wsgiref.simple_server' or '-m blog -m wsgiref.simple_server blog', but you
have to understand lots of specifics to see why. I think it's just too
confusing.
On reflection, I feel strongly that a module name should be the default
positional arg, not a filename. I agree with PJ Eby that pointing directly
at a file encourages script/module confusion. I would add that it
encourages hardcoding file paths rather than module names, which is brittle
and not good for the WSGI world (for example, it bypasses virtualenvs and
breaks any time a different deploy directory structure is used). Of course,
this also means no '-m'. Then the typical use case is really just
python -m wsgiref.simple_server blog
A second positional arg is both a new convention and not an explicit one,
where I would prefer either an existing implicit convention or a new
explicit one.
I think PJ Eby is right that the colon convention is only for modules, and
I think following gunicorn's lead here would result in a nicer interface
than forcing (say) --module
python -m wsgiref.simple_server blog:app
If there is a need to point at a filename, I agree that it should be done
explicitly.
python -m wsgiref.simple_server --file=~/app.py
(or whatever the flag should be called). To me this seems like a small cost
to allow the colon by default without possibility of confusion or overly
fancy parsing.
I do really like the idea of having a quick WSGI runner in the stdlib, I
hope it happens and would be happy to help. New users should be able to see
results with a one-liner local server and a quick server deploy tutorial
BEFORE they have to implement a WSGI recipe or understand WSGI. Although
it's not rocket science, it's just easier for everyone when people who
don't (yet) care about WSGI aren't forced to deal with it directly, and
this would help a little with that.
_______________________________________________
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
