Strange bug with Django syncdb

Hello, I've found some interesting errors concerning this tutorial:

The code for inside

/ > home > rbkkr95 > djangomysite > djangomysite >


# Django settings for djangomysite project.

DEBUG = True



    'default': {
        'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
        'NAME': '/home/rbkkr95/djangomysite/db.sqlite',                      # Or path to database file if using sqlite3.
        # The following settings are not used with sqlite3:
        'USER': '',
        'PASSWORD': '',
        'HOST': '',         # Empty for localhost through domain sockets or '' for localhost through TCP.
        'PORT': '',                      # Set to empty string for default.

# Hosts/domain names that are valid for this site; required if DEBUG is False
# See

# Local time zone for this installation. Choices can be found here:
# although not all choices may be available on all operating systems.
# In a Windows environment this must be set to your system time zone.
TIME_ZONE = 'America/Chicago'

   # Language code for this installation. All choices can be found here:
   LANGUAGE_CODE = 'en-us'

   SITE_ID = 1

 # If you set this to False, Django will make some optimizations so as not
 # to load the internationalization machinery.
  USE_I18N = True

 # If you set this to False, Django will not format dates, numbers and
 # calendars according to the current locale.
 USE_L10N = True

 # If you set this to False, Django will not use timezone-aware datetimes.
 USE_TZ = True

 # Absolute filesystem path to the directory that will hold user-uploaded files.
  # Example: "/var/www/"

 # URL that handles the media served from MEDIA_ROOT. Make sure to use a
 # trailing slash.
  # Examples: "", ""
  MEDIA_URL = ''

 # Absolute path to the directory static files should be collected to.
 # Don't put anything in this directory yourself; store your static files
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
 # Example: "/var/www/"

 # URL prefix for static files.
# Example: "", ""
STATIC_URL = '/static/'

# Additional locations of static files
    # Put strings here, like "/home/html/static" or "C:/www/django/static".
    # Always use forward slashes, even on Windows.
    # Don't forget to use absolute paths, not relative paths.

# List of finder classes that know how to find static files in
# various locations.
#    'django.contrib.staticfiles.finders.DefaultStorageFinder',

     # Make this unique, and don't share it with anybody.

# List of callables that know how to import templates from various sources.
#        'django.template.loaders.eggs.Loader',

  # Uncomment the next line for simple clickjacking protection:
  # 'django.middleware.clickjacking.XFrameOptionsMiddleware',

ROOT_URLCONF = 'djangomysite.urls'

# Python dotted path to the WSGI application used by Django's runserver.
WSGI_APPLICATION = 'djangomysite.wsgi.application'

# Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.

# Uncomment the next line to enable the admin:
# Uncomment the next line to enable admin documentation:
# 'django.contrib.admindocs',

   # A sample logging configuration. The only tangible logging
   # performed by this configuration is to send an email to
   # the site admins on every HTTP 500 error when DEBUG=False.
  # See for
 # more details on how to customize your logging configuration.
   LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
     'filters': {
       'require_debug_false': {
           '()': 'django.utils.log.RequireDebugFalse'
   'handlers': {
       'mail_admins': {
        'level': 'ERROR',
          'filters': ['require_debug_false'],
        'class': 'django.utils.log.AdminEmailHandler'
   'loggers': {
       'django.request': {
        'handlers': ['mail_admins'],
          'level': 'ERROR',
           'propagate': True,

The following command

14:04 ~/djangomysite $ python ./ syncdb

gave the following error:

Traceback (most recent call last):
 File "./", line 10, in <module>
  File "/usr/local/lib/python2.7/site-packages/django/core/management/", lin
  e 429, in execute_from_command_line
  File "/usr/local/lib/python2.7/site-packages/django/core/management/", lin
e 379, in execute
  File "/usr/local/lib/python2.7/site-packages/django/core/management/", lin
e 252, in fetch_command
app_name = get_commands()[subcommand]
  File "/usr/local/lib/python2.7/site-packages/django/core/management/", lin
e 101, in get_commands
apps = settings.INSTALLED_APPS
  File "/usr/local/lib/python2.7/site-packages/django/utils/", line 276, i
 n __getattr__
 File "/usr/local/lib/python2.7/site-packages/django/conf/", line 42, in _s
self._wrapped = Settings(settings_module)
  File "/usr/local/lib/python2.7/site-packages/django/conf/", line 142, in _
  File "/usr/local/lib/python2.7/logging/", line 777, in dictConfig
   File "/usr/local/lib/python2.7/logging/", line 562, in configure
  'filter %r: %s' % (name, e))
 ValueError: Unable to configure filter 'require_debug_false': Cannot resolve 'django.ut
 ils.log.RequireDebugFalse': No module named RequireDebugFalse

I don't know anything about all these files, and what's wrong with these, or what's perhaps wrong with my code, that I just copied from the tutorial. I hope I have given you enough interesting information.

That settings file isn't the one that would be generated by the tutorial. A few bits that stand out that are different are:

# Python dotted path to the WSGI application used by Django's runserver.
WSGI_APPLICATION = 'djangomysite.wsgi.application'


'filters': {
   'require_debug_false': {
       '()': 'django.utils.log.RequireDebugFalse'

The second one suggests that there's a Django version difference involved. Did you do this in a virtualenv with Django 1.4 or 1.5? Or did you copy the config from somewhere else?

Going to the folder

/ > home > rbkkr95 > .virtualenvs > django14 > lib >  python2.7

I notice that I used django 1.4. And this should be the folder where all the malicious files are stored, corrupting the console.
This is where informatics fail: if you started using an old version, and later use a second program that uses a new version, then there is a version difference.
That's why I love Chrome OS and the Cloud Concept so much.

If you're using a virtualenv, you need to activate it in the console that you're using. Search the forums for 'virtualenv' there's a lot of detail about how to use virtualenvs.

I have taken a radical decision: the whole deletion of my web app, because I want to start anew. The biggest mistake I've made is not documenting any of my actions. That's because I'm totally inexperienced, but I sometimes want to spend my free time for programming.
You guys are very helpful. Aditionally, I've learnt that I have to take version differences into account when I'm programming.

Wait. It doesn't delete my code... I just want to undo all of my mistakes. So, how to delete all of my previous codes and start fully afresh? I quote:

This will delete your web app and its associated wsgi file. It will not delete your code.

I may also refer to this topic:

I have an idea: deleting my pythonanywhere account and setting up a new one?!