Fixed #16155 -- Removed Python 2.4 compatibility constructs from code and mentions from docs. Thanks Aymeric Augustin for the report and patch.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16349 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Ramiro Morales 2011-06-09 20:01:28 +00:00
parent da0c7cd777
commit dff31de20a
20 changed files with 65 additions and 115 deletions

View File

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

View File

@ -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__ = [

View File

@ -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':

View File

@ -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})

View File

@ -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"')

View File

@ -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

View File

@ -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):
"""

View File

@ -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

View File

@ -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)

View File

@ -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?
---------------------------------

View File

@ -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

View File

@ -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/

View File

@ -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``

View File

@ -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
========================

View File

@ -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

View File

@ -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

View File

@ -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
--------

View File

@ -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

View File

@ -1126,9 +1126,6 @@ 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, "Type 'manage.py help <subcommand>' for help on a specific subcommand.")
@ -1136,9 +1133,6 @@ class CommandTypes(AdminScriptTestCase):
"-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, "Type 'manage.py help <subcommand>' for help on a specific subcommand.")

View File

@ -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