django book hello world

I am following the third chapter in the Django book :

I am trying to change my and but nothing seems to be happening when I alter the urls.

The error I get does not seem consistent with what I have changed my URLS.oy too. I have commeted out everything that is not what I am trying to implement:

from django.http import HttpResponse
import datetime

def hello(request):
    return HttpResponse("Hello world")

def current_datetime(request):
    now =
    html = "<html><body>It is now %s.</body></html>" % now
    return HttpResponse(html)

from django.conf.urls.defaults import patterns, include, url
from django.contrib import admin
from mysite.views import hello, current_datetime

urlpatterns = patterns('',
    # This is going to be our home view.
    # We'll uncomment it later
    url(r'^hello/$', hello),
    url(r'^time/$', current_datetime)

urlpatterns += patterns('',
    url(r'^todo/', include('mysite.todo.urls')),
    url(r'^polls/', include('mysite.polls.urls')),
urlpatterns += patterns('',
    url(r'^$', 'mysite.myapp.views.home', name='home'),
    # Uncomment the next line to enable the admin:
    url(r'^admin/', include(,

    # Uncomment the admin/doc line below to enable admin documentation:
    # url(r'^admin/doc/', include('django.contrib.admindocs.urls')),

and the error:

Using the URLconf defined in mysite.urls, Django tried these URL patterns, in this order:
^$ [name='home']
The current URL, hello, didn't match any of these.

I dont see how this error can be correct as I have modified the URLS.PY to make them an error. If you can advise me on how to get my hello world app working I would appreciate it. I think the tutorial is for django 1.4 and this site runs 1.3 so maybe that will help. Any help is appreciated I have struggling with this error for too long. thanks.

I am shocked. I deleted my entire file and my site still works. I dont know what to do is this an error with py anywhere? or am I missing something really big?

The home.html is being automatically open with my app. even when I delete the view that is providing the right_now object and still am getting the time. this is the site :

Have you clicked reload on the web tab of the dashboard?

yeah that is why it is so weird. it seems like it is not registering because nothing changed.

Same problem happen to me. I can change whatever i want at my and nothing has a effect to my wep app. It is like they use just a old version of my *.py files. On the other hand all changes on the templates of my project works fine.

What happens pythonanywhere ?

@IronHand, @JoeButy -- can I take a look at your files? No need to do anything beyond saying "yes" here on the forums; we just don't look at your files without permission.

Actually, no need -- I've found the problem. It's on our side, I'm preparing a patch (it's a simple fix) and will post back with some details once it's live. It's actually quite an interesting one :-)

OK, that's live now, the problem should be fixed. Sorry about that! Let me know if things still aren't working.

I'll post the details here shortly.


thanks to giles all works fine again. The support is overwhelming.


Awesome, thanks for confirming that!

So, here's what was happening.

Each web app someone has on PythonAnywhere runs on a backend server. We have a cluster of these backends, and the cluster is behind a loadbalancer. Every backend server in the cluster is capable of running any web app; the loadbalancer's job is to spread things out between them so that each one at any given time is only running an appropriately-sized subset of them. It has a list of backends, which we can update in realtime as we add or remove backends to scale up or down, and it looks at incoming requests and uses the domain name to work out which backend to route a request to.

That's all pretty simple. The twist comes when we add the code that reload web apps to the mix.

Reloading a PythonAnywhere web app is simply a case of making an authenticated request to a specific URL. For example, right now (and this might change, it's not an official API, so don't do anything that relies on it) to reload owned by user fred, you'd hit the URL

Now, the PythonAnywhere website itself is just another web app running on one of the backends (a bit recursive, I know). So most requests to it are routed based on the normal loadbalancing algorithm. But calls specifically to that "reload" URL need to be routed differently -- they need to go to the specific backend that is running the site that needs to be reloaded. So, for that URL, and that URL only, the loadbalancer uses the domain name that's specified second-to-the-end in the path bit of the URL to choose which backend to route the request to, instead of using the hostname at the start of the URL.

So, what happened here? Well, the clue was in the usernames of the people who were affected by the problem -- IronHand and JoeButy. Both of you have mixed-case usernames. And your web apps are and

But the code on the "Web" tab that specifies the URL for reloading the selected domain specifies it using your mixed-case usernames -- that is, it specifies that the reload calls should go to the URL for or

And you can probably guess what the problem was -- the backend selection code was case-sensitive. So requests to your web apps were going to one backend, but reload messages were going to another different backend. The fix I just pushed made the backend selection code case-insensitive, as it should have been.

The remaining question -- why did this suddenly crop up today? My best guess is that it's been there for a while, but it was significantly less likely to happen, and so it was written off as a glitch when it happened in the past.

The reason it's become more common is that we actually more than doubled the number of backends yesterday. Because of the way the backend selection code works, when there's a relatively small number of backends it's actually quite likely that the lower-case version of your domain will, by chance, route to the same backend as the mixed-case one. But the doubling of the number of servers changed that, and suddenly the probability that they'd route differently went up drastically.

Why did we double the number of servers? Previously, backends were m1.xlarge AWS instances. We decided that it would be better to have a larger number of smaller backends, so that problems on one server impacted a smaller number of people. So we changed our system to use m1.large instances instead, span up slightly more than twice as many backend servers, and switched the loadbalancer across.

So, there you have it. I hope it was as interesting to read about as it was to figure out :-)

Yes. ok now let me read all that. <- slow reader

everything is working properly thanks

exactly the same problem is happening to me right now. I made a new update on the code by pulling it from github, but it is not reflected on the life server. Even if I, for example, manually delete the admin url of my django app on, I can still access the admin area on the life server.

did you reload your webapp after changing the code?


you can look in my code if you like, actually I would be very thankful for that :)

when I go to your website it says "something went wrong, please check your error log".