Fixed #17965 -- Definitely dropped support for Python 2.5. Thanks jonash for the initial patch and Aymeric Augustin for the review.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17834 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Claude Paroz
parent
27322df995
commit
23d3459761
|
|
@ -407,10 +407,7 @@ class SessionMiddlewareTests(unittest.TestCase):
|
|||
|
||||
# Handle the response through the middleware
|
||||
response = middleware.process_response(request, response)
|
||||
# If it isn't in the cookie, that's fine (Python 2.5)
|
||||
if 'httponly' in settings.SESSION_COOKIE_NAME:
|
||||
self.assertFalse(
|
||||
response.cookies[settings.SESSION_COOKIE_NAME]['httponly'])
|
||||
self.assertFalse(response.cookies[settings.SESSION_COOKIE_NAME]['httponly'])
|
||||
|
||||
self.assertNotIn('httponly',
|
||||
str(response.cookies[settings.SESSION_COOKIE_NAME]))
|
||||
|
|
|
|||
|
|
@ -25,12 +25,7 @@ try:
|
|||
# The mod_python version is more efficient, so try importing it first.
|
||||
from mod_python.util import parse_qsl
|
||||
except ImportError:
|
||||
try:
|
||||
# Python 2.6 and greater
|
||||
from urlparse import parse_qsl
|
||||
except ImportError:
|
||||
# Python 2.5. Works on Python 2.6 but raises PendingDeprecationWarning
|
||||
from cgi import parse_qsl
|
||||
|
||||
__all__ = [
|
||||
'get_cache', 'cache', 'DEFAULT_CACHE_ALIAS'
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ from django.core.management.color import no_style
|
|||
from django.db import (connections, router, transaction, DEFAULT_DB_ALIAS,
|
||||
IntegrityError, DatabaseError)
|
||||
from django.db.models import get_apps
|
||||
from django.utils.itercompat import product
|
||||
from itertools import product
|
||||
|
||||
try:
|
||||
import bz2
|
||||
|
|
|
|||
|
|
@ -18,17 +18,9 @@ try:
|
|||
# The mod_python version is more efficient, so try importing it first.
|
||||
from mod_python.util import parse_qsl
|
||||
except ImportError:
|
||||
try:
|
||||
# Python 2.6 and greater
|
||||
from urlparse import parse_qsl
|
||||
except ImportError:
|
||||
# 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.5.
|
||||
_morsel_supports_httponly = 'httponly' in Cookie.Morsel._reserved
|
||||
# Some versions of Python 2.7 and later won't need this encoding bug fix:
|
||||
_cookie_encodes_correctly = Cookie.SimpleCookie().value_encode(';') == (';', '"\\073"')
|
||||
# See ticket #13007, http://bugs.python.org/issue2193 and http://trac.edgewall.org/ticket/2256
|
||||
|
|
@ -39,26 +31,8 @@ try:
|
|||
except Cookie.CookieError:
|
||||
_cookie_allows_colon_in_names = False
|
||||
|
||||
if _morsel_supports_httponly and _cookie_encodes_correctly and _cookie_allows_colon_in_names:
|
||||
if _cookie_encodes_correctly and _cookie_allows_colon_in_names:
|
||||
SimpleCookie = Cookie.SimpleCookie
|
||||
else:
|
||||
if not _morsel_supports_httponly:
|
||||
class Morsel(Cookie.Morsel):
|
||||
def __setitem__(self, K, V):
|
||||
K = K.lower()
|
||||
if K == "httponly":
|
||||
if V:
|
||||
# The superclass rejects httponly as a key,
|
||||
# so we jump to the grandparent.
|
||||
super(Cookie.Morsel, self).__setitem__(K, V)
|
||||
else:
|
||||
super(Morsel, self).__setitem__(K, V)
|
||||
|
||||
def OutputString(self, attrs=None):
|
||||
output = super(Morsel, self).OutputString(attrs)
|
||||
if "httponly" in self:
|
||||
output += "; httponly"
|
||||
return output
|
||||
else:
|
||||
Morsel = Cookie.Morsel
|
||||
|
||||
|
|
@ -88,7 +62,7 @@ else:
|
|||
|
||||
return val, encoded
|
||||
|
||||
if not _cookie_allows_colon_in_names or not _morsel_supports_httponly:
|
||||
if not _cookie_allows_colon_in_names:
|
||||
def load(self, rawdata):
|
||||
self.bad_cookies = set()
|
||||
super(SimpleCookie, self).load(rawdata)
|
||||
|
|
|
|||
|
|
@ -8,23 +8,6 @@ import __builtin__
|
|||
import itertools
|
||||
import warnings
|
||||
|
||||
# Fallback for Python 2.5
|
||||
def product(*args, **kwds):
|
||||
"""
|
||||
Taken from http://docs.python.org/library/itertools.html#itertools.product
|
||||
"""
|
||||
# product('ABCD', 'xy') --> Ax Ay Bx By Cx Cy Dx Dy
|
||||
# product(range(2), repeat=3) --> 000 001 010 011 100 101 110 111
|
||||
pools = map(tuple, args) * kwds.get('repeat', 1)
|
||||
result = [[]]
|
||||
for pool in pools:
|
||||
result = [x+[y] for x in result for y in pool]
|
||||
for prod in result:
|
||||
yield tuple(prod)
|
||||
|
||||
if hasattr(itertools, 'product'):
|
||||
product = itertools.product
|
||||
|
||||
def is_iterable(x):
|
||||
"A implementation independent way of checking for iterables"
|
||||
try:
|
||||
|
|
@ -34,6 +17,13 @@ def is_iterable(x):
|
|||
else:
|
||||
return True
|
||||
|
||||
def product(*args, **kwds):
|
||||
# PendingDeprecationWarning in 1.5, remove this comment when the Deprecations
|
||||
# will have been advanced for 1.5
|
||||
warnings.warn("django.utils.itercompat.product is deprecated; use the native version instead",
|
||||
PendingDeprecationWarning)
|
||||
return itertools.product(*args, **kwds)
|
||||
|
||||
def all(iterable):
|
||||
warnings.warn("django.utils.itercompat.all is deprecated; use the native version instead",
|
||||
PendingDeprecationWarning)
|
||||
|
|
|
|||
|
|
@ -16,9 +16,8 @@ How do I get started?
|
|||
What are Django's prerequisites?
|
||||
--------------------------------
|
||||
|
||||
Django requires Python_, specifically any version of Python from 2.5
|
||||
through 2.7. No other Python libraries are required for basic Django
|
||||
usage.
|
||||
Django requires Python_, specifically Python 2.6 or 2.7.
|
||||
No other Python libraries are required for basic Django usage.
|
||||
|
||||
For a development environment -- if you just want to experiment with Django --
|
||||
you don't need to have a separate Web server installed; Django comes with its
|
||||
|
|
@ -39,15 +38,14 @@ 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.5 versus newer Python versions, such as Python 2.6 or 2.7?
|
||||
-----------------------------------------------------------------------------------------------
|
||||
Do I lose anything by using Python 2.6 versus newer Python versions, such as Python 2.7?
|
||||
----------------------------------------------------------------------------------------
|
||||
|
||||
Not in the core framework. Currently, Django itself officially supports any
|
||||
version of Python from 2.5 through 2.7, inclusive. However, newer versions of
|
||||
Not in the core framework. Currently, Django itself officially supports
|
||||
Python 2.6 and 2.7. 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, since Python 2.6,
|
||||
you can use the advanced string formatting described in :pep:`3101`.
|
||||
aren't available under older versions of Python.
|
||||
|
||||
Third-party applications for use with Django are, of course, free to set their
|
||||
own version requirements.
|
||||
|
|
@ -58,7 +56,7 @@ 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.5, and
|
||||
improvements and optimizations to the Python language since version 2.6, and
|
||||
will help ease the process of dropping support for older Python versions on
|
||||
the road to Python 3.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,12 @@ Running Django on Jython
|
|||
|
||||
.. index:: Jython, Java, JVM
|
||||
|
||||
.. admonition::
|
||||
|
||||
Django 1.5 has dropped support for Python 2.5. Until Jython provides a new
|
||||
version that supports 2.6, Django 1.5 is no more compatible with Jython.
|
||||
Please use Django 1.4 if you want to use Django over Jython.
|
||||
|
||||
Jython_ is an implementation of Python that runs on the Java platform (JVM).
|
||||
Django runs cleanly on Jython version 2.5 or later, which means you can deploy
|
||||
Django on any Java platform.
|
||||
|
|
|
|||
|
|
@ -7,20 +7,6 @@ in a backward incompatible way, following their deprecation, as per the
|
|||
:ref:`deprecation policy <internal-release-deprecation-policy>`. More details
|
||||
about each item can often be found in the release notes of two versions prior.
|
||||
|
||||
1.3
|
||||
---
|
||||
|
||||
See the :doc:`Django 1.1 release notes</releases/1.1>` for more details on
|
||||
these changes.
|
||||
|
||||
* ``AdminSite.root()``. This method of hooking up the admin URLs will be
|
||||
removed in favor of including ``admin.site.urls``.
|
||||
|
||||
* Authentication backends need to define the boolean attributes
|
||||
``supports_object_permissions`` and ``supports_anonymous_user`` until
|
||||
version 1.4, at which point it will be assumed that all backends will
|
||||
support these options.
|
||||
|
||||
1.4
|
||||
---
|
||||
|
||||
|
|
@ -276,6 +262,15 @@ these changes.
|
|||
in 1.4. The backward compatibility will be removed --
|
||||
``HttpRequest.raw_post_data`` will no longer work.
|
||||
|
||||
1.7
|
||||
---
|
||||
|
||||
See the :doc:`Django 1.5 release notes</releases/1.5>` for more details on
|
||||
these changes.
|
||||
|
||||
* The function ``django.utils.itercompat.product`` will be removed. The Python
|
||||
builtin version should be used instead.
|
||||
|
||||
2.0
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Install Python
|
|||
--------------
|
||||
|
||||
Being a Python Web framework, Django requires Python. It works with any Python
|
||||
version from 2.5 to 2.7 (due to backwards incompatibilities in Python 3.0,
|
||||
version from 2.6 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
|
||||
|
|
@ -31,15 +31,15 @@ probably already have it installed.
|
|||
You can verify that Python is installed by typing ``python`` from your shell;
|
||||
you should see something like::
|
||||
|
||||
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
|
||||
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
|
||||
Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48)
|
||||
[GCC 4.4.5] on linux2
|
||||
Type "help", "copyright", "credits" or "license" for more information.
|
||||
>>>
|
||||
|
||||
Set up a database
|
||||
-----------------
|
||||
|
||||
If you installed Python 2.5 or later, you can skip this step for now.
|
||||
If you installed Python 2.6 or later, you can skip this step for now.
|
||||
|
||||
If not, or if you'd like to work with a "large" database engine like PostgreSQL,
|
||||
MySQL, or Oracle, consult the :ref:`database installation information
|
||||
|
|
|
|||
|
|
@ -221,9 +221,8 @@ your database connection settings.
|
|||
|
||||
If you're new to databases, we recommend simply using SQLite by setting
|
||||
:setting:`ENGINE` to ``'django.db.backends.sqlite3'`` and :setting:`NAME` to
|
||||
the place where you'd like to store the database. SQLite is included as part
|
||||
of Python 2.5 and later, so you won't need to install anything else to support
|
||||
your database.
|
||||
the place where you'd like to store the database. SQLite is included in Python,
|
||||
so you won't need to install anything else to support your database.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
|
|||
|
|
@ -37,8 +37,8 @@ Example::
|
|||
WSGIProcessGroup geodjango
|
||||
WSGIScriptAlias / /home/geo/geodjango/world.wsgi
|
||||
|
||||
Alias /media/ "/usr/lib/python2.5/site-packages/django/contrib/admin/media/"
|
||||
<Directory "/usr/lib/python2.5/site-packages/django/contrib/admin/media/">
|
||||
Alias /media/ "/usr/lib/python2.6/site-packages/django/contrib/admin/media/"
|
||||
<Directory "/usr/lib/python2.6/site-packages/django/contrib/admin/media/">
|
||||
Order allow,deny
|
||||
Options Indexes
|
||||
Allow from all
|
||||
|
|
@ -77,7 +77,7 @@ Example::
|
|||
PythonPath "['/var/www/apps'] + sys.path"
|
||||
</Location>
|
||||
|
||||
Alias /media/ "/usr/lib/python2.5/site-packages/django/contrib/admin/media/"
|
||||
Alias /media/ "/usr/lib/python2.6/site-packages/django/contrib/admin/media/"
|
||||
<Location "/media">
|
||||
SetHandler None
|
||||
</Location>
|
||||
|
|
|
|||
|
|
@ -461,17 +461,6 @@ SQLite 3.3.6 was released in April 2006, so most current binary distributions
|
|||
for different platforms include newer version of SQLite usable from Python
|
||||
through either the ``pysqlite2`` or the ``sqlite3`` modules.
|
||||
|
||||
However, some platform/Python version combinations include older versions of
|
||||
SQLite (e.g. the official binary distribution of Python 2.5 for Windows, 2.5.4
|
||||
as of this writing, includes SQLite 3.3.4). There are (as of Django 1.1) even
|
||||
some tests in the Django test suite that will fail when run under this setup.
|
||||
|
||||
As described :ref:`below<using-newer-versions-of-pysqlite>`, this can be solved
|
||||
by downloading and installing a newer version of ``pysqlite2``
|
||||
(``pysqlite-2.x.x.win32-py2.5.exe`` in the described case) that includes and
|
||||
uses a newer version of SQLite. Python 2.6 for Windows ships with a version of
|
||||
SQLite that is not affected by these issues.
|
||||
|
||||
Version 3.5.9
|
||||
-------------
|
||||
|
||||
|
|
|
|||
|
|
@ -39,3 +39,8 @@ Backwards incompatible changes in 1.5
|
|||
Features deprecated in 1.5
|
||||
==========================
|
||||
|
||||
itercompat.product
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The :func:`~django.utils.itercompat.product` function has been deprecated. Use
|
||||
the builtin `itertools.product` instead.
|
||||
|
|
|
|||
|
|
@ -93,9 +93,7 @@ These functions, described in detail below, can be used in two different ways:
|
|||
# this code executes inside a transaction
|
||||
# ...
|
||||
|
||||
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.
|
||||
Both techniques work with all supported version of Python.
|
||||
|
||||
.. _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.5 to 2.7 (due to backwards
|
||||
It works with any Python version from 2.6 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).
|
||||
|
|
|
|||
|
|
@ -1591,10 +1591,6 @@ your test suite.
|
|||
|
||||
You can use this as a context manager, like this::
|
||||
|
||||
# This is necessary in Python 2.5 to enable the with statement.
|
||||
# In 2.6 and up, it's not necessary.
|
||||
from __future__ import with_statement
|
||||
|
||||
with self.assertTemplateUsed('index.html'):
|
||||
render_to_string('index.html')
|
||||
with self.assertTemplateUsed(template_name='index.html'):
|
||||
|
|
@ -1656,12 +1652,7 @@ your test suite.
|
|||
|
||||
self.assertNumQueries(7, lambda: my_function(using=7))
|
||||
|
||||
If you're using Python 2.5 or greater you can also use this as a context
|
||||
manager::
|
||||
|
||||
# This is necessary in Python 2.5 to enable the with statement, in 2.6
|
||||
# and up it is no longer necessary.
|
||||
from __future__ import with_statement
|
||||
You can also use this as a context manager::
|
||||
|
||||
with self.assertNumQueries(2):
|
||||
Person.objects.create(name="Aaron")
|
||||
|
|
|
|||
1
setup.py
1
setup.py
|
|
@ -88,7 +88,6 @@ setup(
|
|||
'License :: OSI Approved :: BSD License',
|
||||
'Operating System :: OS Independent',
|
||||
'Programming Language :: Python',
|
||||
'Programming Language :: Python :: 2.5',
|
||||
'Programming Language :: Python :: 2.6',
|
||||
'Programming Language :: Python :: 2.7',
|
||||
'Topic :: Internet :: WWW/HTTP',
|
||||
|
|
|
|||
|
|
@ -25,8 +25,6 @@ class FormsWidgetTestCase(TestCase):
|
|||
self.assertHTMLEqual(w.render('email', 'some "quoted" & ampersanded value'), u'<input type="text" name="email" value="some "quoted" & ampersanded value" />')
|
||||
self.assertHTMLEqual(w.render('email', 'test@example.com', attrs={'class': 'fun'}), u'<input type="text" name="email" value="test@example.com" class="fun" />')
|
||||
|
||||
# Note that doctest in Python 2.4 (and maybe 2.5?) doesn't support non-ascii
|
||||
# characters in output, so we're displaying the repr() here.
|
||||
self.assertHTMLEqual(w.render('email', 'ŠĐĆŽćžšđ', attrs={'class': 'fun'}), u'<input type="text" name="email" value="\u0160\u0110\u0106\u017d\u0107\u017e\u0161\u0111" class="fun" />')
|
||||
|
||||
# You can also pass 'attrs' to the constructor:
|
||||
|
|
|
|||
Loading…
Reference in New Issue