[Web-SIG] A more useful command-line wsgiref.simple_server?

[PJ Eby]

On Thu, Mar 29, 2012 at 4:16 PM, Sasha Hart <s at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20120329/b8f8ad7e/attachment.html>