Forums

Full logs: 2016-08-02 19:51:38 Traceback (most recent call last): 2016-08-02 19:51:38 File "/bin/user_wsgi_wrapper.py", line 154, in call 2016-08-02 19:51:38
2016-08-02 19:51:38 app_iterator = self.app(environ, start_response) 2016-08-02 19:51:38 TypeError 2016-08-02 19:51:38 : 2016-08-02 19:51:38 init() takes exactly 2 arguments (3 given) 2016-08-02 19:51:38

I'm guessing something is wrong with my app class, but it works locally. I set the project home and imported the right class in the config file. Any help would be appreciated!

class Pogom(Flask):
    def __init__(self, import_name, **kwargs):
        super(Pogom, self).__init__(import_name, **kwargs)

Does the super/parent class expect to take import_name? Sounds like it's not expecting the import_name variable to be passed in?

I would think so, since it runs fine locally. When I run it locally, there's a startup script:

app = Pogom(__name__)
app.run(threaded=True, use_reloader=False, debug=args.debug, host=args.host, port=args.port)

In the wsgi config I have:

from pogom.app import Pogom as application

How does the wsgi wrapper instantiate the class? Flask version I'm using is 0.11.1

Thanks for the help!

For Flask, what you'd normally do is, in your app code:

app = Flask(__name__)

...then in the WSGI config file you'd do

from flask_app import app as application

That is, the application variable is set to an instance of the Flask class, not to the class itself.

So, I think what you want is to keep the first line of your local code there on PythonAnywhere -- that is, just the

app = Pogom(__name__)

...but not the app.run, and then do the

from pogom_app import app as application

in the WSGI file.

A common pattern for regular Flask apps so that you don't have to have different code on your local machine and on PythonAnywhere is to "guard" the app.run, like this:

app = Flask(__name__)

# code here

if __name__ == "__main__":
    app.run(stuff)

Hope that helps -- let me know if it's not clear. If it isn't, I can probably suggest specific changes if I can look at your code on PythonAnywhere -- we can see it from our side, but we never look without explicit permission.

That's exactly what I needed, thanks.

I'm running into another problem, though. Part of the server spawns another thread to run database stuff in the background. It appears that this thread gets killed, because it stops displaying anything in the server log after a few seconds. I noticed, though that it says thread support is disabled. Is this why? Or is it because I'm in the tarpit?

We don't support threads inside web apps for various arcane technical reasons :-( I'm actually surprised that you're getting anything in the log at all! I'd expect it to fail when you tried to start it.

Understandable. Can I just run the db thread from a bash console?

That depends on whether the db thread needs information from the request in the web app or not.

Hi kayson, did you make the web app work with the threads in the server side? I'm trying to deploy the same code, but I'm still stuck in the app init part :p

Threads will not work in web apps on PythonAnywhere. We specifically disable them in the server config.