It's worth remembering that CRLF line endings can come from more than just interactions with Windows systems. For example, when pasting file content into text boxes, line endings will typically be converted to CRLF and it's up to the server back-end to convert them back again if necessary. This is because the HTTP standards require it, and it's done by your web browser irrespective of the platform on which it's running.
The only problem of which I'm aware with CRLF line endings in Python is that if the shebang line ends with
^M then it won't be interpreted correctly. I would have expected Python itself to cope fine with CRLF line endings other than that.
I'm a little puzzled by the problems you're having with applications behind sub-URLs. I've only used Flask on PA myself but I haven't had any such issues. Are you using the
@app.route() decorator to define multiple entry points? Or are you having trouble getting variable substitution to work?
One thing to be aware of - if you assign a decorator like this:
... then you'll get a 404 error if you try to put a trailing slash on the URL - this sometimes confuses people. If you put the trailing slash on the route specification then Flask will automatically send redirects from the non-slash to the with-slash version:
With regards to putting Python "behind CGI", WSGI applications always need to run behind some front end which talks HTTP - WSGI applications cannot parse HTTP requests on their own, they're effectively library code which is invoked by the actual webserver. There are dedicated application wrappers which can be used (uWSGI, for example), but these tend to be quite poor at serving static content so they're often placed behind a standard webserver which reverse-proxies to them (Apache, nginx, etc.). Alternatively, webservers often have WSGI interface modules (e.g. mod_wsgi for Apache) which can be used. Either of these solutions works fine.
It's true that several frameworks (Flask among them) have debug modes which can be invoked directly - these tend to use a pure-Python HTTP server for debugging and development use. These are typically never recommended for production use, however, as they tend to be insecure and low performance.