Re: [Django] #4540: Template.render() should verify context instance

[Django]

#4540: Template.render() should verify context instance
-+-
   Reporter:  cephelo@…  |  Owner:  munhitsu
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
-+-
Changes (by SmileyChris):

 * status:  new => closed
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 I'm going to say that we don't need this as critically now. The error
 messages are at least raised in the `render` method now, since we do
 `context.render_context.push()` in there.

 And like ubernostrum stated 3 years ago, doing type checks introduces
 overhead and no matter how negligible, it's still overhead which we don't
 need.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15732: stringfilter documentation example does not work

[Django]

#15732: stringfilter documentation example does not work
-+-
   Reporter:  akaihola   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  easy-pickings
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by SmileyChris):

 * needs_better_patch:  1 => 0


Comment:

 I removed `@stringfilter` from the register doc examples too, so we're
 introducing one concept at a time.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16251 - django/trunk/docs/howto

[noreply]

Author: SmileyChris
Date: 2011-05-19 19:42:28 -0700 (Thu, 19 May 2011)
New Revision: 16251

Modified:
   django/trunk/docs/howto/custom-template-tags.txt
Log:
Fixes #15732 -- better introduction of template filter decorator concepts 
(first register, then stringfilter). Thanks for the patch, hahasee.

Modified: django/trunk/docs/howto/custom-template-tags.txt
===
--- django/trunk/docs/howto/custom-template-tags.txt2011-05-20 02:14:30 UTC 
(rev 16250)
+++ django/trunk/docs/howto/custom-template-tags.txt2011-05-20 02:42:28 UTC 
(rev 16251)
@@ -105,23 +105,6 @@
 "Converts a string into all lowercase"
 return value.lower()
 
-Template filters that expect strings
-
-
-If you're writing a template filter that only expects a string as the first
-argument, you should use the decorator ``stringfilter``. This will
-convert an object to its string value before being passed to your function::
-
-from django.template.defaultfilters import stringfilter
-
-@stringfilter
-def lower(value):
-return value.lower()
-
-This way, you'll be able to pass, say, an integer to this filter, and it
-won't cause an ``AttributeError`` (because integers don't have ``lower()``
-methods).
-
 Registering custom filters
 ~~
 
@@ -140,18 +123,37 @@
 You can use ``register.filter()`` as a decorator instead::
 
 @register.filter(name='cut')
-@stringfilter
 def cut(value, arg):
 return value.replace(arg, '')
 
 @register.filter
-@stringfilter
 def lower(value):
 return value.lower()
 
 If you leave off the ``name`` argument, as in the second example above, Django
 will use the function's name as the filter name.
 
+Template filters that expect strings
+
+
+If you're writing a template filter that only expects a string as the first
+argument, you should use the decorator ``stringfilter``. This will
+convert an object to its string value before being passed to your function::
+
+from django import template
+from django.template.defaultfilters import stringfilter
+
+register = template.Library()
+
+@register.filter
+@stringfilter
+def lower(value):
+return value.lower()
+
+This way, you'll be able to pass, say, an integer to this filter, and it
+won't cause an ``AttributeError`` (because integers don't have ``lower()``
+methods).
+
 Filters and auto-escaping
 ~
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15732: stringfilter documentation example does not work

[Django]

#15732: stringfilter documentation example does not work
-+-
   Reporter:  akaihola   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  easy-pickings
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  1  |
-+-
Changes (by SmileyChris):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [16251]:
 {{{
 #!CommitTicketReference repository="" revision="16251"
 Fixes #15732 -- better introduction of template filter decorator concepts
 (first register, then stringfilter). Thanks for the patch, hahasee.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14757: Add An Example For .extra(tables=[])

[Django]

#14757: Add An Example For .extra(tables=[])
-+-
   Reporter: |  Owner:  nobody
  mikeshultz | Status:  new
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:  documentation extra
 Resolution: |  tables
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by SmileyChris):

 * easy:   => 0


Comment:

 The example follows the bad practice of embedding values in the `where`
 clause rather than in `params`

 It'd also be better if the example was hypothetically useful.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16250 - django/trunk/docs/releases

[noreply]

Author: SmileyChris
Date: 2011-05-19 19:14:30 -0700 (Thu, 19 May 2011)
New Revision: 16250

Modified:
   django/trunk/docs/releases/1.2.txt
Log:
Remove a reference in 1.2 release docs which no longer exists (avoiding a 
sphinx warning when building docs)

Modified: django/trunk/docs/releases/1.2.txt
===
--- django/trunk/docs/releases/1.2.txt  2011-05-20 01:48:41 UTC (rev 16249)
+++ django/trunk/docs/releases/1.2.txt  2011-05-20 02:14:30 UTC (rev 16250)
@@ -1072,7 +1072,7 @@
 Technical message IDs
 -
 
-Up to version 1.1 Django used :ref:`technical message IDs`
+Up to version 1.1 Django used technical message IDs
 to provide localizers the possibility to translate date and time formats. They
 were translatable :term:`translation strings ` that could
 be recognized because they were all upper case (for example

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16249 - django/branches/releases/1.3.X/docs/topics

[noreply]

Author: SmileyChris
Date: 2011-05-19 18:48:41 -0700 (Thu, 19 May 2011)
New Revision: 16249

Modified:
   django/branches/releases/1.3.X/docs/topics/pagination.txt
Log:
[1.3.X] Tweaks to paginator documentation.

Backport of 16248 from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/pagination.txt
===
--- django/branches/releases/1.3.X/docs/topics/pagination.txt   2011-05-20 
01:45:41 UTC (rev 16248)
+++ django/branches/releases/1.3.X/docs/topics/pagination.txt   2011-05-20 
01:48:41 UTC (rev 16249)
@@ -62,8 +62,8 @@
 
 .. note::
 
-Note that you can give ``Paginator`` a list/tuple, a Django ``QuerySet``, 
or
-any other object with a ``count()`` or ``__len__()`` method. When
+Note that you can give ``Paginator`` a list/tuple, a Django ``QuerySet``,
+or any other object with a ``count()`` or ``__len__()`` method. When
 determining the number of objects contained in the passed object,
 ``Paginator`` will first try calling ``count()``, then fallback to using
 ``len()`` if the passed object has no ``count()`` method. This allows
@@ -182,9 +182,9 @@
 When determining the number of objects contained in ``object_list``,
 ``Paginator`` will first try calling ``object_list.count()``. If
 ``object_list`` has no ``count()`` method, then ``Paginator`` will
-fallback to using ``object_list.__len__()``. This allows objects, such
-as Django's ``QuerySet``, to use a more efficient ``count()`` method
-when available.
+fallback to using ``len(object_list)``. This allows objects, such as
+Django's ``QuerySet``, to use a more efficient ``count()`` method when
+available.
 
 .. attribute:: Paginator.num_pages
 
@@ -197,30 +197,36 @@
 ``InvalidPage`` exceptions
 ==
 
-The ``page()`` method raises ``InvalidPage`` if the requested page is invalid
-(i.e., not an integer) or contains no objects. Generally, it's enough to trap
-the ``InvalidPage`` exception, but if you'd like more granularity, you can trap
-either of the following exceptions:
+.. exception:: InvalidPage
 
-``PageNotAnInteger``
+   A base class for exceptions raised when a paginator is passed an invalid
+   page number.
+
+The :meth:`Paginator.page` method raises an exception if the requested page is
+invalid (i.e., not an integer) or contains no objects. Generally, it's enough
+to trap the ``InvalidPage`` exception, but if you'd like more granularity, you
+can trap either of the following exceptions:
+
+.. exception:: PageNotAnInteger
+
 Raised when ``page()`` is given a value that isn't an integer.
 
-``EmptyPage``
+.. exception:: EmptyPage
+
 Raised when ``page()`` is given a valid value but no objects exist on that
 page.
 
-Both of the exceptions are subclasses of ``InvalidPage``, so you can handle
+Both of the exceptions are subclasses of :exc:`InvalidPage`, so you can handle
 them both with a simple ``except InvalidPage``.
 
 
 ``Page`` objects
 
 
-.. class:: Page(object_list, number, paginator)
-
-You usually won't construct :class:`Pages ` by hand -- you'll get them
+You usually won't construct ``Page`` objects by hand -- you'll get them
 using :meth:`Paginator.page`.
 
+.. class:: Page(object_list, number, paginator)
 
 Methods
 ---
@@ -251,15 +257,15 @@
 
 Returns the 1-based index of the first object on the page, relative to all
 of the objects in the paginator's list. For example, when paginating a list
-of 5 objects with 2 objects per page, the second page's 
:meth:`~Page.start_index`
-would return ``3``.
+of 5 objects with 2 objects per page, the second page's
+:meth:`~Page.start_index` would return ``3``.
 
 .. method:: Page.end_index()
 
-Returns the 1-based index of the last object on the page, relative to all 
of
-the objects in the paginator's list. For example, when paginating a list of
-5 objects with 2 objects per page, the second page's 
:meth:`~Page.end_index`
-would return ``4``.
+Returns the 1-based index of the last object on the page, relative to all
+of the objects in the paginator's list. For example, when paginating a list
+of 5 objects with 2 objects per page, the second page's
+:meth:`~Page.end_index` would return ``4``.
 
 Attributes
 --
@@ -275,4 +281,3 @@
 .. attribute:: Page.paginator
 
 The associated :class:`Paginator` object.
-

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16248 - django/trunk/docs/topics

[noreply]

Author: SmileyChris
Date: 2011-05-19 18:45:41 -0700 (Thu, 19 May 2011)
New Revision: 16248

Modified:
   django/trunk/docs/topics/pagination.txt
Log:
Tweaks to paginator documentation.

Modified: django/trunk/docs/topics/pagination.txt
===
--- django/trunk/docs/topics/pagination.txt 2011-05-20 01:45:30 UTC (rev 
16247)
+++ django/trunk/docs/topics/pagination.txt 2011-05-20 01:45:41 UTC (rev 
16248)
@@ -62,8 +62,8 @@
 
 .. note::
 
-Note that you can give ``Paginator`` a list/tuple, a Django ``QuerySet``, 
or
-any other object with a ``count()`` or ``__len__()`` method. When
+Note that you can give ``Paginator`` a list/tuple, a Django ``QuerySet``,
+or any other object with a ``count()`` or ``__len__()`` method. When
 determining the number of objects contained in the passed object,
 ``Paginator`` will first try calling ``count()``, then fallback to using
 ``len()`` if the passed object has no ``count()`` method. This allows
@@ -185,9 +185,9 @@
 When determining the number of objects contained in ``object_list``,
 ``Paginator`` will first try calling ``object_list.count()``. If
 ``object_list`` has no ``count()`` method, then ``Paginator`` will
-fallback to using ``object_list.__len__()``. This allows objects, such
-as Django's ``QuerySet``, to use a more efficient ``count()`` method
-when available.
+fallback to using ``len(object_list)``. This allows objects, such as
+Django's ``QuerySet``, to use a more efficient ``count()`` method when
+available.
 
 .. attribute:: Paginator.num_pages
 
@@ -201,30 +201,37 @@
 ``InvalidPage`` exceptions
 ==
 
-The ``page()`` method raises ``InvalidPage`` if the requested page is invalid
-(i.e., not an integer) or contains no objects. Generally, it's enough to trap
-the ``InvalidPage`` exception, but if you'd like more granularity, you can trap
-either of the following exceptions:
+.. exception:: InvalidPage
 
-``PageNotAnInteger``
+   A base class for exceptions raised when a paginator is passed an invalid
+   page number.
+
+The :meth:`Paginator.page` method raises an exception if the requested page is
+invalid (i.e., not an integer) or contains no objects. Generally, it's enough
+to trap the ``InvalidPage`` exception, but if you'd like more granularity, you
+can trap either of the following exceptions:
+
+.. exception:: PageNotAnInteger
+
 Raised when ``page()`` is given a value that isn't an integer.
 
-``EmptyPage``
+.. exception:: EmptyPage
+
 Raised when ``page()`` is given a valid value but no objects exist on that
 page.
 
-Both of the exceptions are subclasses of ``InvalidPage``, so you can handle
+Both of the exceptions are subclasses of :exc:`InvalidPage`, so you can handle
 them both with a simple ``except InvalidPage``.
 
 
 ``Page`` objects
 
 
+You usually won't construct ``Page`` objects by hand -- you'll get them
+using :meth:`Paginator.page`.
+
 .. class:: Page(object_list, number, paginator)
 
-You usually won't construct :class:`Pages ` by hand -- you'll get them
-using :meth:`Paginator.page`.
-
 .. versionadded:: 1.4
 A page acts like a sequence of :attr:`Page.object_list` when using
 ``len()`` or iterating it directly.
@@ -258,15 +265,15 @@
 
 Returns the 1-based index of the first object on the page, relative to all
 of the objects in the paginator's list. For example, when paginating a list
-of 5 objects with 2 objects per page, the second page's 
:meth:`~Page.start_index`
-would return ``3``.
+of 5 objects with 2 objects per page, the second page's
+:meth:`~Page.start_index` would return ``3``.
 
 .. method:: Page.end_index()
 
-Returns the 1-based index of the last object on the page, relative to all 
of
-the objects in the paginator's list. For example, when paginating a list of
-5 objects with 2 objects per page, the second page's 
:meth:`~Page.end_index`
-would return ``4``.
+Returns the 1-based index of the last object on the page, relative to all
+of the objects in the paginator's list. For example, when paginating a list
+of 5 objects with 2 objects per page, the second page's
+:meth:`~Page.end_index` would return ``4``.
 
 Attributes
 --
@@ -282,4 +289,3 @@
 .. attribute:: Page.paginator
 
 The associated :class:`Paginator` object.
-

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16247 - django/trunk/django/core

[noreply]

Author: SmileyChris
Date: 2011-05-19 18:45:30 -0700 (Thu, 19 May 2011)
New Revision: 16247

Modified:
   django/trunk/django/core/paginator.py
Log:
Remove an unused import from django.core.paginator

Modified: django/trunk/django/core/paginator.py
===
--- django/trunk/django/core/paginator.py   2011-05-20 00:52:36 UTC (rev 
16246)
+++ django/trunk/django/core/paginator.py   2011-05-20 01:45:30 UTC (rev 
16247)
@@ -1,5 +1,4 @@
 from math import ceil
-import collections
 
 class InvalidPage(Exception):
 pass

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16246 - django/branches/releases/1.3.X/docs/topics/http

[noreply]

Author: SmileyChris
Date: 2011-05-19 17:52:36 -0700 (Thu, 19 May 2011)
New Revision: 16246

Modified:
   django/branches/releases/1.3.X/docs/topics/http/sessions.txt
Log:
[1.3.X] Tidy up the sessions documentation creating links for session methods 
and crosslinking settings

Backport of r16245 from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/http/sessions.txt
===
--- django/branches/releases/1.3.X/docs/topics/http/sessions.txt
2011-05-20 00:51:25 UTC (rev 16245)
+++ django/branches/releases/1.3.X/docs/topics/http/sessions.txt
2011-05-20 00:52:36 UTC (rev 16246)
@@ -17,14 +17,15 @@
 
 To enable session functionality, do the following:
 
-* Edit the ``MIDDLEWARE_CLASSES`` setting and make sure
-  ``MIDDLEWARE_CLASSES`` contains 
``'django.contrib.sessions.middleware.SessionMiddleware'``.
-  The default ``settings.py`` created by ``django-admin.py startproject`` 
has
-  ``SessionMiddleware`` activated.
+* Edit the :setting:`MIDDLEWARE_CLASSES` setting and make sure
+  it contains ``'django.contrib.sessions.middleware.SessionMiddleware'``.
+  The default ``settings.py`` created by ``django-admin.py startproject``
+  has ``SessionMiddleware`` activated.
 
 If you don't want to use sessions, you might as well remove the
-``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and 
``'django.contrib.sessions'``
-from your ``INSTALLED_APPS``. It'll save you a small bit of overhead.
+``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and
+``'django.contrib.sessions'`` from your :setting:`INSTALLED_APPS`.
+It'll save you a small bit of overhead.
 
 Configuring the session engine
 ==
@@ -86,56 +87,62 @@
 Using file-based sessions
 -
 
-To use file-based sessions, set the ``SESSION_ENGINE`` setting to
+To use file-based sessions, set the :setting:`SESSION_ENGINE` setting to
 ``"django.contrib.sessions.backends.file"``.
 
-You might also want to set the ``SESSION_FILE_PATH`` setting (which defaults
-to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to control
-where Django stores session files. Be sure to check that your Web server has
-permissions to read and write to this location.
+You might also want to set the :setting:`SESSION_FILE_PATH` setting (which
+defaults to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to
+control where Django stores session files. Be sure to check that your Web
+server has permissions to read and write to this location.
 
 
 Using sessions in views
 ===
 
-When ``SessionMiddleware`` is activated, each ``HttpRequest`` object -- the
-first argument to any Django view function -- will have a ``session``
-attribute, which is a dictionary-like object. You can read it and write to it.
+When ``SessionMiddleware`` is activated, each :class:`~django.http.HttpRequest`
+object -- the first argument to any Django view function -- will have a
+``session`` attribute, which is a dictionary-like object.
 
-A session object has the following standard dictionary methods:
+You can read it and write to ``request.session`` at any point in your view.
+You can edit it multiple times.
 
-* ``__getitem__(key)``
+.. class:: backends.base.SessionBase
 
+This is the base class for all session objects. It has the following
+standard dictionary methods:
+
+.. method:: __getitem__(key)
+
   Example: ``fav_color = request.session['fav_color']``
 
-* ``__setitem__(key, value)``
+.. method:: __setitem__(key, value)
 
   Example: ``request.session['fav_color'] = 'blue'``
 
-* ``__delitem__(key)``
+.. method:: __delitem__(key)
 
   Example: ``del request.session['fav_color']``. This raises ``KeyError``
   if the given ``key`` isn't already in the session.
 
-* ``__contains__(key)``
+.. method:: __contains__(key)
 
   Example: ``'fav_color' in request.session``
 
-* ``get(key, default=None)``
+.. method:: get(key, default=None)
 
   Example: ``fav_color = request.session.get('fav_color', 'red')``
 
-* ``keys()``
+.. method:: keys
 
-* ``items()``
+.. method:: items
 
-* ``setdefault()``
+.. method:: setdefault
 
-* ``clear()``
+.. method:: clear
 
-It also has these methods:
+It also has these methods:
 
-* ``flush()``
+.. method:: flush
 
   Delete the current session data from the session and regenerate the
   session key value that is sent back to the user in the cookie. This is
@@ -143,25 +150,25 @@
   accessed again from the user's browser (for example, the
   :func:`django.contrib.auth.logout()` function calls it).
 
-* ``set_test_cookie()``
+.. method:: set_test_cookie
 
   Sets a test cookie to determine whether the user's browser supports
   cookies. Due to the way cookies work, you won't be able to test this
   until the user's next 

[Changeset] r16245 - django/trunk/docs/topics/http

[noreply]

Author: SmileyChris
Date: 2011-05-19 17:51:25 -0700 (Thu, 19 May 2011)
New Revision: 16245

Modified:
   django/trunk/docs/topics/http/sessions.txt
Log:
Tidy up the sessions documentation creating links for session methods and 
crosslinking settings

Modified: django/trunk/docs/topics/http/sessions.txt
===
--- django/trunk/docs/topics/http/sessions.txt  2011-05-19 02:51:39 UTC (rev 
16244)
+++ django/trunk/docs/topics/http/sessions.txt  2011-05-20 00:51:25 UTC (rev 
16245)
@@ -17,14 +17,15 @@
 
 To enable session functionality, do the following:
 
-* Edit the ``MIDDLEWARE_CLASSES`` setting and make sure
-  ``MIDDLEWARE_CLASSES`` contains 
``'django.contrib.sessions.middleware.SessionMiddleware'``.
-  The default ``settings.py`` created by ``django-admin.py startproject`` 
has
-  ``SessionMiddleware`` activated.
+* Edit the :setting:`MIDDLEWARE_CLASSES` setting and make sure
+  it contains ``'django.contrib.sessions.middleware.SessionMiddleware'``.
+  The default ``settings.py`` created by ``django-admin.py startproject``
+  has ``SessionMiddleware`` activated.
 
 If you don't want to use sessions, you might as well remove the
-``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and 
``'django.contrib.sessions'``
-from your ``INSTALLED_APPS``. It'll save you a small bit of overhead.
+``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and
+``'django.contrib.sessions'`` from your :setting:`INSTALLED_APPS`.
+It'll save you a small bit of overhead.
 
 Configuring the session engine
 ==
@@ -86,56 +87,62 @@
 Using file-based sessions
 -
 
-To use file-based sessions, set the ``SESSION_ENGINE`` setting to
+To use file-based sessions, set the :setting:`SESSION_ENGINE` setting to
 ``"django.contrib.sessions.backends.file"``.
 
-You might also want to set the ``SESSION_FILE_PATH`` setting (which defaults
-to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to control
-where Django stores session files. Be sure to check that your Web server has
-permissions to read and write to this location.
+You might also want to set the :setting:`SESSION_FILE_PATH` setting (which
+defaults to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to
+control where Django stores session files. Be sure to check that your Web
+server has permissions to read and write to this location.
 
 
 Using sessions in views
 ===
 
-When ``SessionMiddleware`` is activated, each ``HttpRequest`` object -- the
-first argument to any Django view function -- will have a ``session``
-attribute, which is a dictionary-like object. You can read it and write to it.
+When ``SessionMiddleware`` is activated, each :class:`~django.http.HttpRequest`
+object -- the first argument to any Django view function -- will have a
+``session`` attribute, which is a dictionary-like object.
 
-A session object has the following standard dictionary methods:
+You can read it and write to ``request.session`` at any point in your view.
+You can edit it multiple times.
 
-* ``__getitem__(key)``
+.. class:: backends.base.SessionBase
 
+This is the base class for all session objects. It has the following
+standard dictionary methods:
+
+.. method:: __getitem__(key)
+
   Example: ``fav_color = request.session['fav_color']``
 
-* ``__setitem__(key, value)``
+.. method:: __setitem__(key, value)
 
   Example: ``request.session['fav_color'] = 'blue'``
 
-* ``__delitem__(key)``
+.. method:: __delitem__(key)
 
   Example: ``del request.session['fav_color']``. This raises ``KeyError``
   if the given ``key`` isn't already in the session.
 
-* ``__contains__(key)``
+.. method:: __contains__(key)
 
   Example: ``'fav_color' in request.session``
 
-* ``get(key, default=None)``
+.. method:: get(key, default=None)
 
   Example: ``fav_color = request.session.get('fav_color', 'red')``
 
-* ``keys()``
+.. method:: keys
 
-* ``items()``
+.. method:: items
 
-* ``setdefault()``
+.. method:: setdefault
 
-* ``clear()``
+.. method:: clear
 
-It also has these methods:
+It also has these methods:
 
-* ``flush()``
+.. method:: flush
 
   Delete the current session data from the session and regenerate the
   session key value that is sent back to the user in the cookie. This is
@@ -143,25 +150,25 @@
   accessed again from the user's browser (for example, the
   :func:`django.contrib.auth.logout()` function calls it).
 
-* ``set_test_cookie()``
+.. method:: set_test_cookie
 
   Sets a test cookie to determine whether the user's browser supports
   cookies. Due to the way cookies work, you won't be able to test this
   until the user's next page request. See `Setting test cookies`_ below for
   more information.
 
-* ``test_cookie_worked()``
+.. 

Re: [Django] #9595: Add support for cache to not expire

[Django]

#9595: Add support for cache to not expire
-+-
   Reporter:  keseldude  |  Owner:  otherjacob
   Type:  New| Status:  new
  feature|  Component:  Core (Cache system)
  Milestone:  1.4|   Severity:  Normal
Version:  1.0|   Keywords:  cache timeout
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  1
  decision needed|  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
-+-
Changes (by simon29):

 * cc: simon@… (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16047: postgresql_psycopg2 never restores autocommit mode when leaving transaction management

[Django]

#16047: postgresql_psycopg2 never restores autocommit mode when leaving 
transaction
management
-+-
   Reporter:  brodie |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  psycopg2 autocommit
Needs documentation:  0  |  transactions
Patch needs improvement:  0  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by kgibula):

 Patch also applies to trunk and tests pass for PostgreSQL 8.4 and psycopg2
 2.4.1. On other backends, however, '!DatabaseWrapper' object doesn't have
 an attribute 'isolation_level' so tests result in attribute errors (I
 tried MySQL and SQLite).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15768: The setUp() method FileStorageTests in tests/regressiontests/file_storage/tests.py uses tempfile.mktemp()

[Django]

#15768: The setUp() method FileStorageTests in
tests/regressiontests/file_storage/tests.py uses tempfile.mktemp()
-+-
   Reporter:  d1b|  Owner:  elbarto
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Testing framework
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by graham_king):

 * milestone:   => 1.4
 * component:  Uncategorized => Testing framework
 * version:  1.3 => SVN
 * stage:  Accepted => Ready for checkin


Comment:

 Patch applies cleanly. Fixes the problem. Tests still pass.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16052: MySQL: CharField's with utf8_bin collation return as str, should return as unicode.

[Django]

#16052: MySQL: CharField's with utf8_bin collation return as str, should return 
as
unicode.
-+-
   Reporter: |  Owner:  graham_king
  graham_king| Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  mysql utf_bin
   Triage Stage:  Design |  unicode
  decision needed|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by graham_king):

 Thanks for the explanation. I thought it was a little too easy! :-)

 It seems the 'standard' way of guessing if we have binary or text data is
 to look for a null byte. Apparently that's what 'grep' and 'git diff' do.
 I've changed the patch to do that, and added tests. A VAR_STRING now
 becomes str if it's binary data (or utf-16), unicode otherwise.

 Null byte idea is from here: http://stackoverflow.com/questions/898669
 /how-can-i-detect-if-a-file-is-binary-non-text-in-python

 Hopefully this means we can do both: not break (VAR)BINARY columns, and
 make utf8_bin !CharField less surprising.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14678: [flatpages] Users are able to add more than one page to the same url

[Django]

#14678: [flatpages] Users are able to add more than one page to the same url
-+-
   Reporter:  seler  |  Owner:  joni
   Type:  Bug| Status:  assigned
  Milestone:  1.4|  Component:  contrib.flatpages
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  flatpages, unique,
   Triage Stage:  Ready for  |  sites
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by graham_king):

 * version:  1.2 => SVN
 * stage:  Accepted => Ready for checkin
 * easy:   => 0
 * milestone:   => 1.4


Comment:

 Yes it's a real problem, which can throw a !MultipleObjectsReturned. Yes
 the patch applies cleanly on latest trunk and fixes the problem. Yes it
 has tests. Yes all the tests still pass with this patch applied.

 It doesn't get much better than this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16056: Memcached configuration mistake

[Django]

#16056: Memcached configuration mistake
---+---
 Reporter:  antonio@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
---+---
 Cache docs has a mistake in the topic about memcached configuration. Where
 it's written "To take advantage of this feature, include all server
 addresses in BACKEND, either separated by semicolons or as a list.", you
 should say to include the addresses in LOCATION, not in BACKEND.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16057: uWSGI documentation

[Django]

#16057: uWSGI documentation
---+---
 Reporter:  jpic   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords:  uwsgi  |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
---+---
 Ticket for officialy proposing the uWSGI documentation which is ready to
 be contributed.

 Source:
 http://piratepad.net/DISxvZLCdG

 Discussion:
 http://groups.google.com/group/django-
 developers/browse_thread/thread/40379c15783c8d8d

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #5929: Allow Fields to use multiple db columns (complex datatypes)

[Django]

#5929: Allow Fields to use multiple db columns (complex datatypes)
-+-
   Reporter:  poelzi |  Owner:
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by ben.coughlan@…):

 * cc: ben.coughlan@… (added)
 * easy:   => 0


Comment:

 This would 'really' simplify django support for [http://code.google.com/p
 /python-money/ python-money].  I'd like to have a MoneyField which needs
 two columns, one for a Decimal value and another for a 3 character
 currency code.

 Right now we're using the example found
 [http://blog.elsdoerfer.name/2008/01/08/fuzzydates-or-one-django-model-
 field-multiple-database-columns/ here] but it leaves a lot to be desired
 regarding lookups and aggregates.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #8593: Image upload in Windows changes filename to lowercase

[Django]

#8593: Image upload in Windows changes filename to lowercase
-+-
   Reporter:  robvdl |  Owner:
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  File
Version:  1.0|  uploads/storage
 Resolution: |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:  upload image
  checkin|  lowercase
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by jezdez):

 * stage:  Accepted => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16055: Filtering over funky generic relations breaks in postgres

[Django]

#16055: Filtering over funky generic relations breaks in postgres
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by victor.van.den.elzen@…):

 * cc: victor.van.den.elzen@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16055: Filtering over funky generic relations breaks in postgres

[Django]

#16055: Filtering over funky generic relations breaks in postgres
---+--
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Database layer (models, ORM)
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
---+--
 When you have a generic foreign key with TextField / CharField object_id,
 and try to use it in a filter with a model that has an integer primary
 key, PostgreSQL 9.0.4 errors out with this:
 {{{
 DatabaseError: operator does not exist: integer = text

 HINT:  No operator matches the given name and argument type(s). You might
 need to add explicit type casts.
 }}}

 A small example:
 {{{
 class Tag(models.Model):
 tag = models.SlugField()
 content_type = models.ForeignKey(ContentType)
 object_id = models.TextField()
 content_object = generic.GenericForeignKey()

 class Animal(models.Model):
 name = models.TextField()
 tags = generic.GenericRelation(Tag)

 print Animal.objects.filter(tags__tag='mammal')
 }}}

 I have a patch that changes Django's generic foreign key tests to also try
 everything with a textual object_id, which exhibits this problem.

 A workaround is to create this cast as implicit in postgres:
 {{{
 CREATE CAST (integer AS text) WITH INOUT AS IMPLICIT
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15766: select_related() changes type of DecimalField

[Django]

#15766: select_related() changes type of DecimalField
-+-
   Reporter:  CarstenF   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
  worksforme |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by anonymous):

 xcsdasdasd

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #8593: Image upload in Windows changes filename to lowercase

[Django]

#8593: Image upload in Windows changes filename to lowercase
-+-
   Reporter:  robvdl |  Owner:
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  File
Version:  1.0|  uploads/storage
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  upload image
Needs documentation:  0  |  lowercase
Patch needs improvement:  0  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by ramiro):

 * owner:  ramiro =>


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16003: Admin incompatible with USE_ETAGS = True

[Django]

#16003: Admin incompatible with USE_ETAGS = True
+-
   Reporter:  lamby |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Release blocker
 Resolution:|   Keywords:  regression
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+-
Changes (by jezdez):

 * component:  Uncategorized => contrib.admin


Comment:

 Yeah, this seems like a rather major issue with the TemplateResponse
 feature, which I think can only be fixed by actually rendering the content
 if needed instead of raising a `ContentNotRenderedError ` exception.

 With proper documentation of which middlewares/decorator modify the
 content we should be able to keep the usefulness of TemplateResponse up.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16022: Cyclic reference in FieldFile causes memory usage to grow considerably (was: Cyclic reference in FieldFile)

[Django]

#16022: Cyclic reference in FieldFile causes memory usage to grow considerably
-+-
   Reporter:  Gustavo|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  memory leak
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16022: Cyclic reference in FieldFile

[Django]

#16022: Cyclic reference in FieldFile
-+-
   Reporter:  Gustavo|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  memory leak
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by Gustavo):

 * keywords:   => memory leak
 * has_patch:  1 => 0


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16022: Cyclic reference in FieldFile

[Django]

#16022: Cyclic reference in FieldFile
-+-
   Reporter:  Gustavo|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.1|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by Gustavo):

 I've tried replacing weakref.ref() with weakref.proxy(), which does work
 but then memory keeps growing as usual. I think a proper way to fix it is
 to break the cyclic reference, but that'd be backwards incompatible.

 I cannot afford spending more time on this, so I'll leave it to someone
 else. I'm happy to test any eventual fix though. In the meantime, we'll be
 using mod_wsgi's ''maximum-requests'' to mitigate the consequences of this
 problem.

 A hint to whoever will have a look at this: Try setting ''self.instance''
 to ''None'' in ''!FieldFile.!__init!__'' and you won't notice any memory
 growth when you query many records. This breaks creation, modification and
 deletion of files, but helps demonstrate that this is the problematic
 reference.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16047: postgresql_psycopg2 never restores autocommit mode when leaving transaction management

[Django]

#16047: postgresql_psycopg2 never restores autocommit mode when leaving 
transaction
management
-+-
   Reporter:  brodie |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  psycopg2 autocommit
Needs documentation:  0  |  transactions
Patch needs improvement:  0  |  Has patch:  1
 |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.