<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.python.django.devel">
    <title>gmane.comp.python.django.devel</title>
    <link>http://blog.gmane.org/gmane.comp.python.django.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/36046"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/36031"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/36022"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/36014"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/36009"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35999"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35975"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35974"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35967"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35961"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35956"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35953"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35948"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35940"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35939"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35936"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35928"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35926"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35923"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.django.devel/35919"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/36046">
    <title>Python 3 port - now available on GitHub</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/36046</link>
    <description>&lt;pre&gt;The single codebase port of Django to Python 3 is now available on
GitHub [1]. Recent core changes have been merged, and the test results
are available at [2].

Summary:

2.7.2: Ran 4734 tests in 540.793s - OK (skipped=112, expected
failures=3)
3.2.2: Ran 4688 tests in 524.807s - OK (skipped=120, expected
failures=2, unexpected successes=1)

Recent tests only cover the SQLite backend and were run on Linux. Help
with testing other DB backends (and the GIS functionality) would be
much appreciated!

Regards,

Vinay Sajip

[1] https://github.com/vsajip/django/tree/django3
[2] https://gist.github.com/1373553

&lt;/pre&gt;</description>
    <dc:creator>Vinay Sajip</dc:creator>
    <dc:date>2012-05-25T09:51:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/36031">
    <title>Suggestion: make auth login view more dynamic</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/36031</link>
    <description>&lt;pre&gt;I couldn't find an existing ticket but I'd like to suggest a change to make the basic auth view more dynamic (I'm not fond of hardcoded context variables :-))

change:

def login(request, template_name='registration/login.html',
          redirect_field_name=REDIRECT_FIELD_NAME,
          authentication_form=AuthenticationForm,
          current_app=None, extra_context=None):

to:

def login(request, template_name='registration/login.html',
          redirect_field_name=REDIRECT_FIELD_NAME,
          authentication_form=AuthenticationForm,
          current_app=None, extra_context=None, form_name='form'):


and obviously:

    context = {
        form_name: form,
        redirect_field_name: redirect_to,
        'site': current_site,
        'site_name': current_site.name,
    }


Kind Regards,

Hedde van der Heide

&lt;/pre&gt;</description>
    <dc:creator>Hedde van der Heide</dc:creator>
    <dc:date>2012-05-23T11:02:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/36022">
    <title>Announcement: twice-monthly Django sprints in San Francisco</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/36022</link>
    <description>&lt;pre&gt;My company, Votizen, now has an office in San Francisco, just a block
from the 4th St Caltrain station.  We have room to host sprints -
easily 25 people, though we can grow if there is demand.  We have a
professional kitchen, great coffee gear, and maybe a kegerator soon.
There are many great places to eat within an easy walk.

We will begin hosting day-long, twice-monthly sprints for Django on
the 1st and 3rd Saturdays of each month.  We hope that by making it a
comfortable length and a regular occurrence, we can grow a good core
of contribution.

Note: this first sprint will be on Sunday, June 3rd due to a prior
commitment - sorry about that. :-)

Since we need to manage space and setup demands in order to make this
a regular event, we'll use eventbrite for free tickets.

If your company would like to sponsor food &amp;amp; beverage on a per-event
basis, that would be appreciated.  Please contact me off-list for
logistics.

So, if you are in the bay area and would like to contribute,
collaborate, mentor or be ment&lt;/pre&gt;</description>
    <dc:creator>Jeremy Dunck</dc:creator>
    <dc:date>2012-05-22T19:30:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/36014">
    <title>ModelForm enforces its version of save_m2m</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/36014</link>
    <description>&lt;pre&gt;Hello everybody,

Currently, Django ModelForm enforces it's local version of save_m2m:
https://github.com/django/django/blob/38408f8007eae21b9f1cbbcc7f86d4b2042ff86a/django/forms/models.py#L76

As a result, users who want to overload save_m2m can not support
commit=False: https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/contrib/generic_m2m.py#L50

Wouldn't it be great if users could overload save_m2m ?

If you agree, I volunteer to do the ticket and pull request. Else I'll
leave my hack in my app :(

Regards

&lt;/pre&gt;</description>
    <dc:creator>James Pic</dc:creator>
    <dc:date>2012-05-22T09:53:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/36009">
    <title>Customizable serialization now passing Django's test suite.</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/36009</link>
    <description>&lt;pre&gt;I've been working away on django-serializers&amp;lt;https://github.com/tomchristie/django-serializers&amp;gt;lately, and I've now got a
customizable serialization API that's backwards compatible with the existing
serializers, and is passing Django's serializer tests.

Exactly where I take this will depend on how Piotr Grabowski's GSoC project
progresses, but I'd certainly appreciate any input regarding the API design,
or if there would be any obvious blockers that'd prevent something along 
these
lines making it's way in as a replacement to the existing serializers.

This work intentionally doesn't (yet) address customizable deserialization,
and as such it currently only supports the existing loaddata 
deserialization.


Running the existing tests with django-serializers
==================================================

* Clone Django

* Install django-serializers

* Replace the existing dumpdata serializers with django-serializer's 
versions

In `django/core/serializers/__init__.py`, replace these strings:

"django.cor&lt;/pre&gt;</description>
    <dc:creator>Tom Christie</dc:creator>
    <dc:date>2012-05-21T11:39:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35999">
    <title>Sitemaps files using the X-Robots-Tag HTTP header</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35999</link>
    <description>&lt;pre&gt;I just created ticket 18351, which is to add the X-Robots-Tag HTTP header 
to our default sitemaps.

The reason for this is somewhat complicated, and I've explained it in the 
ticket &amp;lt;https://code.djangoproject.com/ticket/18351&amp;gt;, but basically, the 
goal is to make it so sitemaps don't appear in search results anymore 
(though of course, you want their urls to continue appearing). Currently we 
don't set any special headers on our sitemaps, and as a result, you can 
find sitemaps within search results.

If you so desire, you can prove this with clever queries like: [ 
sitemap.xml site:yourdjangosite.com ]

I've put a patch on the bug that adds:

response['X-Robots-Tag'] = 'noindex, noodp, noarchive, noimageindex'

To all sitemap files. I haven't added this to the documentation, since it 
seems like an implementation detail. I've run the tests, and I hope I'm 
good to have the patch landed. 

Would appreciate any feedback though, since it's my first patch to Django.

Mike

&lt;/pre&gt;</description>
    <dc:creator>Michael Lissner</dc:creator>
    <dc:date>2012-05-20T06:24:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35975">
    <title>DJango 1.3 - BundleError while rendering</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35975</link>
    <description>&lt;pre&gt;Hi, I'm new to Django and trying to get an existing application to work on 
my development machine.

When running the project, I get the following error:

TemplateSyntaxError at /

Caught BundleError while rendering: 'styles/libs/jquery-ui-timepicker-addon.css' not found (using staticfiles finders)

 Where is he searching for the file? All paths are set correctly in 
settings.py. 
The css is defined in assets.py:

stylesheets = Bundle( reset_defaults,
    'styles/libs/jquery-ui-timepicker-addon.css',
    main_styles,
    filters='cssmin',
    output='combined/styles/main.css' )


Can anyone give me an indication of where to search for this problem?
Any help would be greatly appreciated

Kind
regards
Y.

&lt;/pre&gt;</description>
    <dc:creator>Y.</dc:creator>
    <dc:date>2012-05-18T07:49:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35974">
    <title>Localflavor Test Case issues</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35974</link>
    <description>&lt;pre&gt;Hey,

I'm trying to add localflavor for Singapore, and am running into issues 
getting my test cases to pass.

When manually validate my test cases by running the validators from the 
django-admin shell, they pass all my test cases.  But when I run my test 
cases from the test runner, I get:

AssertionError: ValidationError not raised

and the test case test_postcode seems to be adding another invalid test, 
None:[u'This field is required.'], but I might be confused by this.

Any help in what I'm doing wrong would be appreciated.

My code is at 
git-9UaJU3cA/F/QT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org:yarbelk/django.git

&lt;/pre&gt;</description>
    <dc:creator>James Rivett-Carnac</dc:creator>
    <dc:date>2012-05-18T06:03:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35967">
    <title>Django git guidelines</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35967</link>
    <description>&lt;pre&gt;A heads up: I am working on Git and Github usage guidelines. There is
a ticket https://code.djangoproject.com/ticket/18307, and I have a
github branch with some initial work https://github.com/akaariai/django/tree/django_git_guidelines
(or for changeset https://github.com/akaariai/django/compare/django_git_guidelines)

The guidelines in short:
 - For trivial patches use pull requests directly
 - For non-trivial patches, create a trac ticket, announce your work
by linking to your github branch, and when your work is ready to be
pulled in, only then do a pull request
 - Aim for logically contained commits, commit messages of 50 char
summary line, 72 char paragraphs thereafter.
 - When upstream has changed use git rebase instead of git pull
 - When you do additional fixes to your work, use git rebase -i so
that your work still fullfills the logical commits requirement.

Lots of more details in the WIP branch. All feedback welcomed. Lets
keep the discussion of any high-level issues here on django-
developers, as&lt;/pre&gt;</description>
    <dc:creator>Anssi Kääriäinen</dc:creator>
    <dc:date>2012-05-18T08:43:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35961">
    <title>Django-mssql with the dream of passing the test suite</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35961</link>
    <description>&lt;pre&gt;A few weeks ago, I started down the path of updating django-mssql so that
it supports Django 1.4. I moved the project over to bitbucket (
http://bitbucket.org/Manfre/django-mssql/), docs are deployed to read the
docs (http://django-mssql.readthedocs.org), and have made it a policy of
deploying packages to PyPi.

Django 1.4 support is mostly there and so far is passing all testing for
the site responsible for the backend's existence (http://www.src.org). To
help avoid surprises and ensure life as a 3rd party database backend
maintainer is a lot less painful, I have set a goal of having django-mssql
pass the test suite. This is a non-trivial task that will require changes
to django and django-mssql. I've already submitted a few tickets that bring
me closer to my goal and it was advised that I send this message as a heads
up regarding my intentions to avoid tickets being closed with a "mssql
isn't officially supported by Django" comment.

If you review one of these tickets, please keep my goal in the back of yo&lt;/pre&gt;</description>
    <dc:creator>Michael Manfre</dc:creator>
    <dc:date>2012-05-16T20:27:00</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35956">
    <title>Possible session key creation regression in 1.4</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35956</link>
    <description>&lt;pre&gt;Hi all

One of our sites was recently upgraded to 1.4 and now some previously
working code is failing.

The code tries to access and utilize the session id from the user, but
if it tries to do this on the request the session is created on, the
session id is None. The equivalent session object in 1.3 always
presents a valid session id.

1.3.1:

(1, 3, 1, 'final', 0)
a8b409a6b29ac5a59022350445f8bfa4


1.4:

(1, 4, 0, 'final', 0)
None


This is using the DB backend, but perusing the changes to
contrib.session, I think all backends will be similarly affected.

So, is the session key being available part of the API, or is relying
on the session key existing incorrect?

Cheers

Tom

&lt;/pre&gt;</description>
    <dc:creator>Tom Evans</dc:creator>
    <dc:date>2012-05-16T15:09:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35953">
    <title>Django MEDIA url in storage.py</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35953</link>
    <description>&lt;pre&gt;Hi all,

I am developing an intranet portal using django 1.3.1. I noticed in my 
uploader app that the default storage redirects the saved files to the 
apache2 directory.
I found later that the reason of this is due to 
Django.core.files.storage.py in line 152, 154. It still uses 
settings.MEDIA_URL. The same thing for 1.4.
I fixed it changing it to STATIC_URL. please fix it in the future release.

regards,   

&lt;/pre&gt;</description>
    <dc:creator>hakim</dc:creator>
    <dc:date>2012-05-16T13:26:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35948">
    <title>New Release of IBM_DB_DJANGO (1.0.4)</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35948</link>
    <description>&lt;pre&gt;IBM_DB_DJANGO-1.0.4
-----------------------------------
IBM_DB_DJANGO adaptor enables access to IBM databases from Django
applications http://www.djangoproject.com/. The adaptor is developed
and maintained by IBM.

What's New?
--------------------
 - Added support for Django-1.4

 - Backward compatibilty - Same codebase works with older supported
version of Django

 - Added support to enable Django's USE_TZ feature

 - Added support for Django's bulk_create

 - Added support for 'SELECT FOR UPDATE'

 - Added module version string __version__


SVN access to the source
---------------------------------------
http://code.google.com/p/ibm-db/source/browse/trunk/IBM_DB/ibm_db_django/

Installation
----------------
$ easy_install ibm_db_django

Feedback/Suggestions/Issues
--------------------------------------------
You can provide us feedback/suggestions, or report a bug/defect, or
ask for help by using any of the following channels:
1. Mailing us at opendev-r/Jw6+rmf7HQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org
2. Opening a n&lt;/pre&gt;</description>
    <dc:creator>Rahul</dc:creator>
    <dc:date>2012-05-16T10:18:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35940">
    <title>Authentication page</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35940</link>
    <description>&lt;pre&gt;Hi all,
i'm new of Django world and i would like to create  for my web site an 
autentication page (login, logout, sign up, change user , etc..)
How can found a tutorial to do that? Anyone can suggest me ho build that?
Thanks

Francesco

&lt;/pre&gt;</description>
    <dc:creator>francescoboccacci-VGgt2q2+T+FeoWH0uzbU5w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2012-05-15T13:55:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35939">
    <title>#18277 : Passing additional context to startproject command</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35939</link>
    <description>&lt;pre&gt;Jezdez said he wanted to discuss the point of this feature.
I posted a very simple working patch (I only have a yellow belt in 
django/python)
As this was advertised as possible in the docs, I wanted to pass more 
variables to the project template rendering command (./manage.py 
startproject --template)

Example use case : in order to make a valid wsgi.py file, pass the 
virtualenv site-packages folder path 

Now for the discussion of is it a good idea : the command in itself 
empowers us to create our own templates
Big apps already use this kind of template-base-project : satchmo and 
mezzanine are two examples. I'm sure they could also benefit from this 
additional context feature.


Dominique
http://quinode.fr/

&lt;/pre&gt;</description>
    <dc:creator>Dominique Guardiola Falco</dc:creator>
    <dc:date>2012-05-15T13:53:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35936">
    <title>Incorrect serialization for 3d GEOSGeometry</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35936</link>
    <description>&lt;pre&gt;Hi folks


I discovered django.contrib.gis support for 3d geometries is pretty 
patchy. I realised that the database stuff only worked in postgis, etc, but 
it turns out even the serialisation methods on GEOSGeometry don't work 
properly.

Here's a small test script that demonstrates the problem: 
https://gist.github.com/2594905

And here's the output: https://gist.github.com/2594926

In summary, all these properties return 2d-only output for 3d geometries 
(the Z dimension gets stripped):

   - wkt
   - ewkt
   - hex
   - wkb
   - json
   - geojson
   
Yet these others produce correct 3d output:

   - ewkb
   - hexewkb
   - kml

Is there any reasoning behind this, or should I create a ticket and try to 
fix them?

I tried posting this to the geodjango list (here)&amp;lt;https://groups.google.com/forum/#!msg/geodjango/XQkkeDmsCDI/ZBYq1XZ6SngJ&amp;gt;, 
but I'm not sure if anyone actually reads those posts, as I haven't got a 
response in 10 days.

Thanks
Craig de Stigter

&lt;/pre&gt;</description>
    <dc:creator>Craig de Stigter</dc:creator>
    <dc:date>2012-05-15T12:02:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35928">
    <title>Subclass handle_uncaught_exception</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35928</link>
    <description>&lt;pre&gt;I have a custom database interface with (amongst other things) a lazy
rowgetter. Our database provides custom exception messages when, for instance,
a rate limit is exceeded.

Because of the "laziness" of the rowgetter, the except clause in my view
(shown below) is not triggered, and control falls to
core/handlers/base.py : handle_uncaught_exception.

    try:
        rota = self.model.xmlapi_get_location (**kwargs)
    except DBException, e:
        code, message = [epart.strip() for epart in e.msg.split(':')]
        return HttpResponse(message, status=code,
                            content_type="text/plain")

I've tried the following:

* The use of middleware using "process_exception" : DBException not raised
* handler500 in urls : DBException not available

Consequently I believe I need to either make my lazy rowgetter less lazy so
that it errors earlier, or subclass handle_uncaught_exception. If the latter is
feasible I'd be grateful for some advice on how to do so within my app.

Rory

p.s.
An earli&lt;/pre&gt;</description>
    <dc:creator>Rory Campbell-Lange</dc:creator>
    <dc:date>2012-05-14T11:36:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35926">
    <title>Help...........!!!</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35926</link>
    <description>&lt;pre&gt;Hi Django......


I Am implementing Django front end setup and Am using SQLite as
Database for my project.......Am new to djnago family .
Help me to implement

1.Determine all network interface connected to system
2.Determine all ENABLED interfaces
3.start monitoring all enabled interface.


Thank YO.....

&lt;/pre&gt;</description>
    <dc:creator>Ali Shaikh</dc:creator>
    <dc:date>2012-05-14T07:11:22</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35923">
    <title>Bug (in 1.4+) double slash in URL leads to incorrect ``request.build_absolute_uri()``</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35923</link>
    <description>&lt;pre&gt;A request to:

    http://www.example.com:8080//foo-bar-baz.html

leads to request.build_absolute_uri() returning:

    http://foo-bar.html

&lt;/pre&gt;</description>
    <dc:creator>Yo-Yo Ma</dc:creator>
    <dc:date>2012-05-14T01:55:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35919">
    <title>django.contrib.auth.models.get_hexdigest missing in 1.4</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35919</link>
    <description>&lt;pre&gt;Hi,

In the process of upgrading to Django 1.4, I've run into a little problem: one 
of our files uses django.contrib.auth.models.get_hexdigest, which is no longer 
present.

I searched, and could find no mention of this in release notes, tickets, or the 
developers group.

Was this, for some reason, not considered a public API?

Of course, I can copy the function from a 1.3 installation and use that, but I 
suspect that if it was removed, there was a good reason -- and I'd like to 
know what it was, before deciding to ignore it...

Thanks,
Shai.

&lt;/pre&gt;</description>
    <dc:creator>Shai Berger</dc:creator>
    <dc:date>2012-05-13T13:08:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.django.devel/35917">
    <title>Django 1.4 bug: Using cache_page and csrf_protect decorators results in a messy Set-Cookie response header.</title>
    <link>http://comments.gmane.org/gmane.comp.python.django.devel/35917</link>
    <description>&lt;pre&gt;

I'm using Django 1.4.
According to the Django csrf docs, I decorate my class-based view in the urls.py as follows:

cache_page(1800)(csrf_protect(MyView.as_view()))

I kept reloading MyView page url and Set-Cookie header would be recursive like this:

Set-Cookie: csrftoken="Set-Cookie: csrftoken=\"Set-Cookie: csrftoken=XeRCBpXuNpuRie17OqWrDIM3xKt9hV3Q\\073 expires=Sat\\054 11-May-2013 19:50:21 GMT\\073 Max-Age=31449600\\073 Path=/\""

I don't know what's a trigger to this behavior.
Has anyone found a problem like this? Please help.
Thanks. 




&lt;/pre&gt;</description>
    <dc:creator>Suteepat Damrongyingsupab</dc:creator>
    <dc:date>2012-05-12T20:13:48</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.python.django.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.python.django.devel</link>
  </textinput>
</rdf:RDF>

