diff --git a/INSTALL b/INSTALL
index 644c524bbbf..4a36c901a1f 100644
--- a/INSTALL
+++ b/INSTALL
@@ -1,6 +1,6 @@
 Thanks for downloading Django.
 
-To install it, make sure you have Python 2.4 or greater installed. Then run
+To install it, make sure you have Python 2.5 or greater installed. Then run
 this command from the command prompt:
 
     python setup.py install
@@ -9,8 +9,9 @@ AS AN ALTERNATIVE, you can just copy the entire "django" directory to Python's
 site-packages directory, which is located wherever your Python installation
 lives. Some places you might check are:
 
+    /usr/lib/python2.7/site-packages (Unix, Python 2.7)
+    /usr/lib/python2.6/site-packages (Unix, Python 2.6)
     /usr/lib/python2.5/site-packages (Unix, Python 2.5)
-    /usr/lib/python2.4/site-packages (Unix, Python 2.4)
     C:\\PYTHON\site-packages         (Windows)
 
 For more detailed instructions, see docs/intro/install.txt.
diff --git a/django/core/cache/__init__.py b/django/core/cache/__init__.py
index bb10e01c65f..b76ddcf0384 100644
--- a/django/core/cache/__init__.py
+++ b/django/core/cache/__init__.py
@@ -29,8 +29,7 @@ except ImportError:
         # Python 2.6 and greater
         from urlparse import parse_qsl
     except ImportError:
-        # Python 2.5, 2.4.  Works on Python 2.6 but raises
-        # PendingDeprecationWarning
+        # Python 2.5.  Works on Python 2.6 but raises PendingDeprecationWarning
         from cgi import parse_qsl
 
 __all__ = [
diff --git a/django/db/backends/oracle/base.py b/django/db/backends/oracle/base.py
index c024e6d7d04..c4642cafd6c 100644
--- a/django/db/backends/oracle/base.py
+++ b/django/db/backends/oracle/base.py
@@ -176,12 +176,6 @@ WHEN (new.%(col_name)s IS NULL)
         # classes to normalize values from the database (the to_python
         # method is used for validation and isn't what we want here).
         elif isinstance(value, Database.Timestamp):
-            # In Python 2.3, the cx_Oracle driver returns its own
-            # Timestamp object that we must convert to a datetime class.
-            if not isinstance(value, datetime.datetime):
-                value = datetime.datetime(value.year, value.month,
-                        value.day, value.hour, value.minute, value.second,
-                        value.fsecond)
             if field and field.get_internal_type() == 'DateTimeField':
                 pass
             elif field and field.get_internal_type() == 'DateField':
diff --git a/django/db/models/base.py b/django/db/models/base.py
index e75eb496956..31310ea0e75 100644
--- a/django/db/models/base.py
+++ b/django/db/models/base.py
@@ -915,10 +915,5 @@ def model_unpickle(model, attrs, factory):
     return cls.__new__(cls)
 model_unpickle.__safe_for_unpickle__ = True
 
-if sys.version_info < (2, 5):
-    # Prior to Python 2.5, Exception was an old-style class
-    def subclass_exception(name, parents, unused):
-        return types.ClassType(name, parents, {})
-else:
-    def subclass_exception(name, parents, module):
-        return type(name, parents, {'__module__': module})
+def subclass_exception(name, parents, module):
+    return type(name, parents, {'__module__': module})
diff --git a/django/http/__init__.py b/django/http/__init__.py
index ae507aac63a..066346c1810 100644
--- a/django/http/__init__.py
+++ b/django/http/__init__.py
@@ -17,13 +17,12 @@ except ImportError:
         # Python 2.6 and greater
         from urlparse import parse_qsl
     except ImportError:
-        # Python 2.5, 2.4.  Works on Python 2.6 but raises
-        # PendingDeprecationWarning
+        # Python 2.5.  Works on Python 2.6 but raises PendingDeprecationWarning
         from cgi import parse_qsl
 
 import Cookie
 # httponly support exists in Python 2.6's Cookie library,
-# but not in Python 2.4 or 2.5.
+# but not in Python 2.5.
 _morsel_supports_httponly = Cookie.Morsel._reserved.has_key('httponly')
 # Some versions of Python 2.7 and later won't need this encoding bug fix:
 _cookie_encodes_correctly = Cookie.SimpleCookie().value_encode(';') == (';', '"\\073"')
diff --git a/django/utils/hashcompat.py b/django/utils/hashcompat.py
index 57435b14be6..b11fa0a6864 100644
--- a/django/utils/hashcompat.py
+++ b/django/utils/hashcompat.py
@@ -3,22 +3,13 @@ The md5 and sha modules are deprecated since Python 2.5, replaced by the
 hashlib module containing both hash algorithms. Here, we provide a common
 interface to the md5 and sha constructors, depending on system version.
 """
-import sys
-import warnings
 
+import warnings
 warnings.warn("django.utils.hashcompat is deprecated; use hashlib instead",
               PendingDeprecationWarning)
 
-if sys.version_info >= (2, 5):
-    import hashlib
-    md5_constructor = hashlib.md5
-    md5_hmac = md5_constructor
-    sha_constructor = hashlib.sha1
-    sha_hmac = sha_constructor
-else:
-    import md5
-    md5_constructor = md5.new
-    md5_hmac = md5
-    import sha
-    sha_constructor = sha.new
-    sha_hmac = sha
+import hashlib
+md5_constructor = hashlib.md5
+md5_hmac = md5_constructor
+sha_constructor = hashlib.sha1
+sha_hmac = sha_constructor
diff --git a/django/utils/http.py b/django/utils/http.py
index 4b43e5835ee..07e96b9ba62 100644
--- a/django/utils/http.py
+++ b/django/utils/http.py
@@ -198,8 +198,8 @@ if sys.version_info >= (2, 6):
         p1, p2 = urlparse.urlparse(url1), urlparse.urlparse(url2)
         return (p1.scheme, p1.hostname, p1.port) == (p2.scheme, p2.hostname, p2.port)
 else:
-    # Python 2.4, 2.5 compatibility. This actually works for Python 2.6 and
-    # above, but the above definition is much more obviously correct and so is
+    # Python 2.5 compatibility. This actually works for Python 2.6 and above,
+    # but the above definition is much more obviously correct and so is
     # preferred going forward.
     def same_origin(url1, url2):
         """
diff --git a/django/utils/itercompat.py b/django/utils/itercompat.py
index 38058e227c2..a56b703983f 100644
--- a/django/utils/itercompat.py
+++ b/django/utils/itercompat.py
@@ -7,7 +7,7 @@ these implementations if necessary.
 import itertools
 import warnings
 
-# Fallback for Python 2.4, Python 2.5
+# Fallback for Python 2.5
 def product(*args, **kwds):
     """
     Taken from http://docs.python.org/library/itertools.html#itertools.product
diff --git a/django/utils/translation/trans_real.py b/django/utils/translation/trans_real.py
index b497d9e354b..9e8285bcf70 100644
--- a/django/utils/translation/trans_real.py
+++ b/django/utils/translation/trans_real.py
@@ -63,8 +63,7 @@ def to_language(locale):
 class DjangoTranslation(gettext_module.GNUTranslations):
     """
     This class sets up the GNUTranslations context with regard to output
-    charset. Django uses a defined DEFAULT_CHARSET as the output charset on
-    Python 2.4.
+    charset.
     """
     def __init__(self, *args, **kw):
         gettext_module.GNUTranslations.__init__(self, *args, **kw)
diff --git a/docs/faq/install.txt b/docs/faq/install.txt
index f500e77a88d..f1e865a9665 100644
--- a/docs/faq/install.txt
+++ b/docs/faq/install.txt
@@ -16,7 +16,7 @@ How do I get started?
 What are Django's prerequisites?
 --------------------------------
 
-Django requires Python_, specifically any version of Python from 2.4
+Django requires Python_, specifically any version of Python from 2.5
 through 2.7. No other Python libraries are required for basic Django
 usage.
 
@@ -40,17 +40,15 @@ PostgreSQL fans, and MySQL_, `SQLite 3`_, and Oracle_ are also supported.
 .. _`SQLite 3`: http://www.sqlite.org/
 .. _Oracle: http://www.oracle.com/
 
-Do I lose anything by using Python 2.4 versus newer Python versions, such as Python 2.5 or 2.6?
+Do I lose anything by using Python 2.5 versus newer Python versions, such as Python 2.6 or 2.7?
 -----------------------------------------------------------------------------------------------
 
 Not in the core framework. Currently, Django itself officially supports any
-version of Python from 2.4 through 2.7, inclusive. However, newer versions of
+version of Python from 2.5 through 2.7, inclusive. However, newer versions of
 Python are often faster, have more features, and are better supported. If you
 use a newer version of Python you will also have access to some APIs that
-aren't available under older versions of Python. For example Django provides
-some `context managers`_ for various operations. If you use Python 2.4 you
-won't be able to use them, however other APIs which provide the same
-functionality are always made available.
+aren't available under older versions of Python. For example, since Python 2.6,
+you can use the advanced string formatting described in `PEP 3101`_.
 
 Third-party applications for use with Django are, of course, free to set their
 own version requirements.
@@ -61,11 +59,11 @@ versions as part of a migration which will end with Django running on Python 3
 
 All else being equal, we recommend that you use the latest 2.x release
 (currently Python 2.7). This will let you take advantage of the numerous
-improvements and optimizations to the Python language since version 2.4, and
+improvements and optimizations to the Python language since version 2.5, and
 will help ease the process of dropping support for older Python versions on
 the road to Python 3.
 
-.. _context managers: http://docs.python.org/reference/datamodel.html#context-managers
+.. _PEP 3101: http://www.python.org/dev/peps/pep-3101/
 
 Can I use Django with Python 2.4?
 ---------------------------------
diff --git a/docs/internals/contributing/writing-code/branch-policy.txt b/docs/internals/contributing/writing-code/branch-policy.txt
index 08dfe8bc769..940b96f7ac2 100644
--- a/docs/internals/contributing/writing-code/branch-policy.txt
+++ b/docs/internals/contributing/writing-code/branch-policy.txt
@@ -135,8 +135,8 @@ Pointing Python at the new Django version
 Once you've retrieved the branch's code, you'll need to change your Python
 ``site-packages`` directory so that it points to the branch version of the
 ``django`` directory. (The ``site-packages`` directory is somewhere such as
-``/usr/lib/python2.4/site-packages`` or
-``/usr/local/lib/python2.4/site-packages`` or ``C:\Python\site-packages``.)
+``/usr/lib/python2.7/site-packages`` or
+``/usr/local/lib/python2.7/site-packages`` or ``C:\Python\site-packages``.)
 
 The simplest way to do this is by renaming the old ``django`` directory to
 ``django.OLD`` and moving the trunk version of the code into the directory
@@ -169,12 +169,5 @@ sure all other lines are commented::
     # On windows a path may look like this:
     # C:/path/to/<branch>
 
-If you're using Django 0.95 or earlier and installed it using
-``python setup.py install``, you'll have a directory called something like
-``Django-0.95-py2.4.egg`` instead of ``django``. In this case, edit the file
-``setuptools.pth`` and remove the line that references the Django ``.egg``
-file. Then copy the branch's version of the ``django`` directory into
-``site-packages``.
-
 .. _path file: http://docs.python.org/library/site.html
 .. _django-developers: http://groups.google.com/group/django-developers
diff --git a/docs/intro/install.txt b/docs/intro/install.txt
index 0b4cf879386..6bf5b705fbc 100644
--- a/docs/intro/install.txt
+++ b/docs/intro/install.txt
@@ -10,13 +10,11 @@ Install Python
 --------------
 
 Being a Python Web framework, Django requires Python. It works with any Python
-version from 2.4 to 2.7 (due to backwards
-incompatibilities in Python 3.0, Django does not currently work with
-Python 3.0; see :doc:`the Django FAQ </faq/install>` for more
-information on supported Python versions and the 3.0 transition), but we
-recommend installing Python 2.5 or later. If you do so, you won't need to set
-up a database just yet: Python 2.5 or later includes a lightweight database
-called SQLite_.
+version from 2.5 to 2.7 (due to backwards incompatibilities in Python 3.0,
+Django does not currently work with Python 3.0; see :doc:`the Django FAQ
+</faq/install>` for more information on supported Python versions and the 3.0
+transition), these versions of Python include a lightweight database called
+SQLite_ so you won't need to set up a database just yet.
 
 .. _sqlite: http://sqlite.org/
 
diff --git a/docs/ref/contrib/gis/install.txt b/docs/ref/contrib/gis/install.txt
index 82df82793c0..40418568c68 100644
--- a/docs/ref/contrib/gis/install.txt
+++ b/docs/ref/contrib/gis/install.txt
@@ -8,7 +8,7 @@ Overview
 ========
 In general, GeoDjango installation requires:
 
-1. :ref:`python24` and :ref:`django`
+1. Python and :ref:`django`
 2. :ref:`spatial_database`
 3. :ref:`geospatial_libs`
 
@@ -32,22 +32,10 @@ instructions are available for:
 Requirements
 ============
 
-.. _python24:
-
-Python 2.4+
------------
-
-Python 2.4 is the minimum version supported by Django, however Python 2.5+ is
-recommended because the `ctypes`__ module comes included; otherwise, 2.4 users
-will need to `download and install ctypes`__.
-
-__ http://docs.python.org/lib/module-ctypes.html
-__ http://sourceforge.net/projects/ctypes/files/
-
 .. _django:
 
-Django
-------
+Python and Django
+-----------------
 
 Because GeoDjango is included with Django, please refer to Django's
 :doc:`installation instructions </intro/install>` for details on how to install.
@@ -1034,7 +1022,6 @@ Required package information:
 * ``flex``: required to build PostGIS
 * ``postgresql-8.1``
 * ``postgresql-server-dev-8.1``: for ``pg_config``
-* ``python-ctypes``: Python 2.4 needs to have ctypes installed separately
 * ``python-psycopg2``
 * ``python-setuptools``: for ``easy_install``
 
@@ -1110,7 +1097,7 @@ Python
 ^^^^^^
 
 First, download the latest `Python 2.7 installer`__ from the Python Web site.
-Next, run the installer and keep the defaults -- for example, keep 
+Next, run the installer and keep the defaults -- for example, keep
 'Install for all users' checked and the installation path set as
 ``C:\Python27``.
 
@@ -1165,7 +1152,7 @@ tree and select :menuselection:`PostGIS 1.5 for PostgreSQL 9.0`.
 
 After clicking next, you will be prompted to select your mirror, PostGIS
 will be downloaded, and the PostGIS installer will begin.  Select only the
-default options during install (e.g., do not uncheck the option to create a 
+default options during install (e.g., do not uncheck the option to create a
 default PostGIS database).
 
 .. note::
@@ -1216,7 +1203,7 @@ executable with ``cmd.exe``, will set this up::
      reg ADD "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v PROJ_LIB /t REG_EXPAND_SZ /f /d "%PROJ_LIB%"
 
 For your convenience, these commands are available in the execuatble batch
-script, :download:`geodjango_setup.bat`.  
+script, :download:`geodjango_setup.bat`.
 
 .. note::
 
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index db62bedf251..90f925c02e1 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -17,6 +17,26 @@ we've `begun the deprecation process for some features`_.
 .. _backwards incompatible changes: backwards-incompatible-changes-1.4_
 .. _begun the deprecation process for some features: deprecated-features-1.4_
 
+Python compatibility
+====================
+
+While not a new feature, it's important to note that Django 1.4 introduces the
+second shift in our Python compatibility policy since Django's initial public
+debut. Django 1.2 dropped support for Python 2.3; now Django 1.4 drops support
+for Python 2.4. As such, the minimum Python version required for Django is now
+2.5, and Django is tested and supported on Python 2.5, 2.6 and 2.7.
+
+This change should affect only a small number of Django users, as most
+operating-system vendors today are shipping Python 2.5 or newer as their default
+version. If you're still using Python 2.4, however, you'll need to stick to
+Django 1.3 until you can upgrade; per :doc:`our support policy
+</internals/release-process>`, Django 1.3 will continue to receive security
+support until the release of Django 1.5.
+
+Django does not support Python 3.x at this time. A document outlining our full
+timeline for deprecating Python 2.x and moving to Python 3.x will be published
+before the release of Django 1.4.
+
 What's new in Django 1.4
 ========================
 
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index b2539d8f065..c316bbf1438 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -79,9 +79,6 @@ These functions, described in detail below, can be used in two different ways:
                 # this code executes inside a transaction
                 # ...
 
-      This technique works with all supported version of Python (that is, with
-      Python 2.4 and greater).
-
     * As a `context manager`_ around a particular block of code::
 
             from django.db import transaction
@@ -96,8 +93,9 @@ These functions, described in detail below, can be used in two different ways:
                     # this code executes inside a transaction
                     # ...
 
-      The ``with`` statement is new in Python 2.5, and so this syntax can only
-      be used with Python 2.5 and above.
+Both techniques work with all supported version of Python. However, in Python
+2.5, you must add ``from __future__ import with_statement`` at the beginning
+of your module if you are using the ``with`` statement.
 
 .. _decorator: http://docs.python.org/glossary.html#term-decorator
 .. _context manager: http://docs.python.org/glossary.html#term-context-manager
diff --git a/docs/topics/install.txt b/docs/topics/install.txt
index ffa445f3585..46d6615a828 100644
--- a/docs/topics/install.txt
+++ b/docs/topics/install.txt
@@ -9,7 +9,7 @@ Install Python
 
 Being a Python Web framework, Django requires Python.
 
-It works with any Python version from 2.4 to 2.7 (due to backwards
+It works with any Python version from 2.5 to 2.7 (due to backwards
 incompatibilities in Python 3.0, Django does not currently work with
 Python 3.0; see :doc:`the Django FAQ </faq/install>` for more
 information on supported Python versions and the 3.0 transition).
@@ -102,11 +102,6 @@ database bindings are installed.
   will also want to read the database-specific :ref:`notes for the MySQL
   backend <mysql-notes>`.
 
-* If you're using SQLite and Python 2.4, you'll need pysqlite_. Use version
-  2.0.3 or higher. Python 2.5 ships with an SQLite wrapper in the standard
-  library, so you don't need to install anything extra in that case. Please
-  read the :ref:`SQLite backend notes <sqlite-notes>`.
-
 * If you're using Oracle, you'll need a copy of cx_Oracle_, but please
   read the database-specific :ref:`notes for the Oracle backend <oracle-notes>`
   for important information regarding supported versions of both Oracle and
diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt
index e2c9f72ea62..06050af899d 100644
--- a/docs/topics/logging.txt
+++ b/docs/topics/logging.txt
@@ -441,10 +441,6 @@ Messages to this logger have the following extra context:
     * ``request``: The request object that generated the logging
       message.
 
-.. note::
-    Due to a limitation in the logging library, this extra
-    context is not available if you are using Python 2.4.
-
 ``django.db.backends``
 ~~~~~~~~~~~~~~~~~~~~~~
 
@@ -462,10 +458,6 @@ For performance reasons, SQL logging is only enabled when
 ``settings.DEBUG`` is set to ``True``, regardless of the logging
 level or handlers that are installed.
 
-.. note::
-    Due to a limitation in the logging library, this extra
-    context is not available if you are using Python 2.4.
-
 Handlers
 --------
 
diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt
index 3f25dfff9f7..a21ad6a77eb 100644
--- a/docs/topics/testing.txt
+++ b/docs/topics/testing.txt
@@ -79,7 +79,7 @@ module defines tests in class-based approach.
     adding some extremely useful features. To ensure that every Django
     project can benefit from these new features, Django ships with a
     copy of unittest2_, a copy of the Python 2.7 unittest library,
-    backported for Python 2.4 compatibility.
+    backported for Python 2.5 compatibility.
 
     To access this library, Django provides the
     ``django.utils.unittest`` module alias. If you are using Python
diff --git a/tests/regressiontests/admin_scripts/tests.py b/tests/regressiontests/admin_scripts/tests.py
index 11bd5c687a3..cf0dfc6cc8d 100644
--- a/tests/regressiontests/admin_scripts/tests.py
+++ b/tests/regressiontests/admin_scripts/tests.py
@@ -1126,20 +1126,14 @@ class CommandTypes(AdminScriptTestCase):
         "--help is handled as a special case"
         args = ['--help']
         out, err = self.run_manage(args)
-        if sys.version_info < (2, 5):
-            self.assertOutput(out, "usage: manage.py subcommand [options] [args]")
-        else:
-            self.assertOutput(out, "Usage: manage.py subcommand [options] [args]")
+        self.assertOutput(out, "Usage: manage.py subcommand [options] [args]")
         self.assertOutput(out, "Type 'manage.py help <subcommand>' for help on a specific subcommand.")
 
     def test_short_help(self):
         "-h is handled as a short form of --help"
         args = ['-h']
         out, err = self.run_manage(args)
-        if sys.version_info < (2, 5):
-            self.assertOutput(out, "usage: manage.py subcommand [options] [args]")
-        else:
-            self.assertOutput(out, "Usage: manage.py subcommand [options] [args]")
+        self.assertOutput(out, "Usage: manage.py subcommand [options] [args]")
         self.assertOutput(out, "Type 'manage.py help <subcommand>' for help on a specific subcommand.")
 
     def test_specific_help(self):
diff --git a/tests/regressiontests/httpwrappers/tests.py b/tests/regressiontests/httpwrappers/tests.py
index 2e2932f0cf6..fbed94413bb 100644
--- a/tests/regressiontests/httpwrappers/tests.py
+++ b/tests/regressiontests/httpwrappers/tests.py
@@ -248,9 +248,6 @@ class CookieTests(unittest.TestCase):
         """
         Test that we don't output tricky characters in encoded value
         """
-        # Python 2.4 compatibility note: Python 2.4's cookie implementation
-        # always returns Set-Cookie headers terminating in semi-colons.
-        # That's not the bug this test is looking for, so ignore it.
         c = SimpleCookie()
         c['test'] = "An,awkward;value"
         self.assertTrue(";" not in c.output().rstrip(';')) # IE compat