Forums

Hi.

I just signed up today. I have a script that I used to parse the chat logs from a game I play and it works fine on my laptop, but not under the WSGI module.

I am having errors about indentation levels and yields outside of functions and it expecting an indented block. It seems the indentation is not being honored, but spaces turn into tabs, so it sounds like I should use tabs.

Could anyone explain what I need to do to make mod WSGI happy with cherrypy?

I based my /var/www/wsgi.py on this (please excuse me if the formatting is off):

import sys
sys.stdout = sys.stderr

import atexit
import threading
import cherrypy

cherrypy.config.update({'environment': 'embedded'})

if cherrypy.__version__.startswith('3.0') and cherrypy.engine.state == 0:
    cherrypy.engine.start(blocking=False)
    atexit.register(cherrypy.engine.stop)

class Root(object):
def index(self):
    return 'Hello World!'
index.exposed = True

application = cherrypy.Application(Root(), script_name=None, config=None)

Wow....formatting for the forums is annoying. No fckedit?

Hi Nathan, that wsgi script looks fine to me... from your description of the errors, it sounds like there's been some kind of cut & paste error, or maybe something to do with line endings during the transfer from your laptop to PA...

How did you get your code onto the site? Can you post some of the specific errors you were seeing?

Edit: Looks to me like the def inside the class definition isn't indented - it should be. Perhaps this is the problem rather than tabs?

My personal advice: never use tabs in Python code for any reason at all - PEP8 concurs.

Objective advice: never mix tabs and spaces for indentation in the same Python source file, it's asking for trouble.

If you want to check the source file for confusion between tabs and spaces:

1. Open a bash shell (from the dashboard).
2. Find the source file.
3. Run cat -T sourcefile.py on it.

If you see any ^I (that's an upper-case "i") then those are tab characters. My advice is to re-edit the file to include only spaces and fix up the indentation - you can use your editor of choice for this.

It turned out that the end lines are a problem. I prefer Linux. PythonAnywhere seem to use Windows. The end of line character from one line is considered the first character of the next line, therefore creating a confusing (to the compiler) character at the beginning of each line. I selected indented lines, did shift-tab to un-indent them and then did tab to re-indent them and that solved the one issue.

I still had some problems with the pages not working after restarting the setup on the Dashboard->web button on the right. The logs did not fill up with new info.

I could not have more than my base URL work. I tried Flask too and could not get more than my base URL work for that either. I am getting the impression that WSGI is a flawed CGI program. Personally, I don't understand the need for python behind CGI, but then again, I am a programmer and not a system administrator.

It should probably be easy enough to fix my initial problem for other people by detecting and correcting it in a script that runs on the PythonAnywhere server during file uploads.

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:

@app.route("/foo")
def my_function():
    ...

... 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:

@app.route("/foo/")
def my_function():
    ...

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.

That's good stuff, Cartroo. I've been bitten by the trailing slash thing in Flask before.

nathanstenzel, did that help?