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:
parent
da0c7cd777
commit
dff31de20a
5
INSTALL
5
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.
|
||||
|
|
|
@ -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__ = [
|
||||
|
|
|
@ -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':
|
||||
|
|
|
@ -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})
|
||||
|
|
|
@ -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"')
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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):
|
||||
"""
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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?
|
||||
---------------------------------
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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/
|
||||
|
||||
|
|
|
@ -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``
|
||||
|
||||
|
|
|
@ -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
|
||||
========================
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
--------
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.")
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue