On 2012-03-30, at 20:22 , Sasha Hart wrote: > > 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
And it does. In both case it means "use this module for execution". Hence `-m`, as a shorthand for `--module`. > , took the > same kinds of arguments It does as well, both take a Python module on the path. > , could be exchanged for any other -m clause. But > wsgiref.simple_server is not at all doing what Python is doing Of course not, if it did the exact same thing it would be redundant. > so I see no > gain of understanding by reusing the convention. python -m doesn't take a > second positional argument, either. I'm not sure why that would matter. > You can't write '-m blog app -m > wsgiref.simple_server' or '-m blog -m wsgiref.simple_server blog' Naturally, because this makes no sense at all, the tool being invoked to start the server is all of `python -mwsgiref.simple_server`. But that's the very basics of the -m option. > , but you > have to understand lots of specifics to see why. What specific do you have to understand beyond the normal behavior of `-m`? I fail to see why that would be any more troubling than `python -mcalendar -m 6`. Or require any more specifics. > 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). Not sure how that makes sense, it uses the Python instance and site-package in the virtualenv, there is nothing to bypass. > 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. What is not explicit in having an explicit argument, that it's a positional one instead of an option? How is a colon "more explicit"? > 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 The colon is no more explicit than a second positional argument. In fact, it is significantly less so since it can not be separately and clearly documented and the one positional parameter needs to document its parsing rules instead. > 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. 1. It also does not work considering you can't specify the application's name in that scheme, so piling on yet more complexity would be required and there would be two completely different schemes for specifying an application name. I don't find this appealing. 2. You seem to have asserted from the start that the default should be mounting modules, but I have seen no evidence or argument in favor of that so far. Defaulting to scripts not only works with both local modules and arbitrary files and follow cpython's (and most tools's) own behavior, but would also allows using -mwsgiref.simple_server as a shebang line. I find this to have quite a lot of value. _______________________________________________ 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
