date:20111011

Re: [Django] #16763: code.djangoproject.com won't stop emailing me (doesn't abide by cc/reporter/etc)

2011-10-11 Thread Django

#16763: code.djangoproject.com won't stop emailing me (doesn't abide by
cc/reporter/etc)
-+-
 Reporter:  ferringb |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Djangoproject.com|  Version:
  Web site   |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Sidenote, your captcha challenge also looks to be busted (and no, I'm not
 filing a bug since I don't want the spam); my last message it complained
 (oddly momentarily) was marked as spam by the bayesian filter, explicitly
 requesting I fill out a captcha interface... without providing a captcha.
 Just saying. ;)

-- 
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] #16763: code.djangoproject.com won't stop emailing me (doesn't abide by cc/reporter/etc)

2011-10-11 Thread Django

#16763: code.djangoproject.com won't stop emailing me (doesn't abide by
cc/reporter/etc)
-+-
 Reporter:  ferringb |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Djangoproject.com|  Version:
  Web site   |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 As for "there is no global stop emailing me feature"; there is, user
 preferences allow it but you need to have a sane server side
 configuration.  Specifically turn always_notify_updater to false, and have
 people use CC like a sane tracker ;) .  Worst case, use the always notify
 list functionality- could just point that at a mailing list and have
 people manage their subscription to it via usual mailman UI (basically a
 variation on commit lists).  I rather strongly suggest either way you
 change the status quo- this auto-spamming means personally I'm rather
 disinclined to file any issues django wise unless it's intentionally using
 a crap/null account (which isn't particularly desirable).

 Either way, enough lecturing; I'd definitely appreciate it if you prune
 the username ferringb for both gmail and gentoo.org.

 G'luck in the future and such-

-- 
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] #11505: Django's TestCase should reset the cache

2011-10-11 Thread Django

#11505: Django's TestCase should reset the cache
-+-
 Reporter:  andrewfong   |Owner:
 Type:  New feature  |  andrewfong
Component:  Testing framework|   Status:  assigned
 Severity:  Normal   |  Version:  SVN
 Keywords:  cache testing flush  |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  1
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jsdalton):

 * needs_better_patch:  1 => 0


Comment:

 Adding a new patch for this, which extends the modified cache approach to
 cache middleware. I had noticed on some of my projects that certain tests
 were failing when using cache middleware, which turned out to be because
 the cache was returning the response and thus the context was not included
 in the response to the test client. Tests reproducing this error state as
 well as a fix are included in the latest patch. The full test suite passes
 as well (minus 5 unrelated failures that are on trunk right now).

 The failures to me are a good illustration of why this patch is important.
 The system should ideally be as clean as possible in between each test;
 cache values carrying over from test to test create problematic behavior
 when a full test suite is run.

 I might post again to the dev list if there's no movement on this. If
 anyone on the CC list here would like to review this patch and give any
 feedback please do so. At this point, all that's really required from what
 I can see is a few notes in the documentation.

-- 
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] #16986: Model.clean cannot report errors on individual fields

2011-10-11 Thread Django

Comment (by carljm):

Replying to [comment:3 davidfstr]:
> Regarding backward-compatibility, there is unfortunately very

[https://docs.djangoproject.com/en/dev/ref/exceptions/#django.core.exceptions.ValidationError
little documentation for ValidationError], so I must assume any advanced
users are depending on the exact implementation.
>
> So I've reverted to your implementation approach (which has minimal
impact) and updated the patch. I recognize it still needs a new test case
and documentation changes.

Actually, the fact that the internals of `ValidationError` are not
documented means that they are considered an implementation detail, and
can be changed without regard to backward-compatibility; only the
documented interface (which in this case I think is just instantiation
with a message string) need remain compatible. Anyone using undocumented
internal details can update their code if needed.

That said, I'm not sure initializing message_dict the way you suggest is
correct. `ValidationError` without a dict can be used from inside a
clean_field method to raise errors specific to that field, in which case
having a message_dict property auto-initialized using `__all__` seems
semantically wrong. Essentially `ValidationError` itself can in some cases
be agnostic as to which field its errors belong to, and that is determined
by context.

--
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] #16981: Trac user highlighting breaks if you use a h3 heading in comment

2011-10-11 Thread Django

#16981: Trac user highlighting breaks if you use a h3 heading in comment
-+-
 Reporter:  lukeplant|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Djangoproject.com|  Version:  1.3
  Web site   |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 [http://bit.ly/qayoeX burn fat]

-- 
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] #16986: Model.clean cannot report errors on individual fields

2011-10-11 Thread Django

#16986: Model.clean cannot report errors on individual fields
-+
 Reporter:  davidfstr|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by davidfstr):

 Regarding backward-compatibility, there is unfortunately very
 
[https://docs.djangoproject.com/en/dev/ref/exceptions/#django.core.exceptions.ValidationError
 little documentation for ValidationError], so I must assume any advanced
 users are depending on the exact implementation.

 So I've reverted to your implementation approach (which has minimal
 impact) and updated the patch. I recognize it still needs a new test case
 and documentation changes.

-- 
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] #16679: Speed up signals by caching the reveicers per sender

2011-10-11 Thread Django

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Suor):

 Yes, my solution is not suitable for inherited signals. And once we have
 those it should be discarded. But do we really need them? Implementing as
 little as possible is generally a good idea.

 And, about dynamic creation of model subclasses, I do pretty much of it.
 And in my experience, signals are usually connected in
 .contribute_to_class() call which is done for every new model class, thus
 no need for inherited signals here.

-- 
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] #16549: In Django models, save/delete preconditions would help in handling optimistic concurrency control problems (was: In Django models, modified-rows count would help in handling optim

2011-10-11 Thread Django

#16549: In Django models, save/delete preconditions would help in handling
optimistic concurrency control problems
-+-
 Reporter:  estebistec   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by estebistec):

 Updating summary to be more specific now that ticket 16891 directly
 confronts the rows-modified aspect of this.

 https://code.djangoproject.com/ticket/16891

-- 
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] #16891: Delete/update should return number of rows modified

2011-10-11 Thread Django

#16891: Delete/update should return number of rows modified
-+-
 Reporter:  estebistec   |Owner:
 Type:  New feature  |  estebistec
Component:  Database layer   |   Status:  new
  (models, ORM)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by estebistec):

 Finally got around to these simple changes:

 *
 
https://github.com/estebistec/django/commit/b48a87afc324f5546b6654fa7638e406b397c0d6
 *
 
https://github.com/estebistec/django/commit/28ace32980b370fd17ae35019bfe8d055c673684

 If the core devs approve of these changes I can get to work on creating
 the proper patch for SVN and add doc changes.

-- 
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] #13809: FileField open method is only accepting 'rb' modes

2011-10-11 Thread Django

#13809: FileField open method is only accepting 'rb' modes
--+
 Reporter:  canassa   |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  File uploads/storage  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by davidfstr):

 * cc: davidfstr (added)


Comment:

 I confirm this issue as still present in Django 1.3.

 In short, if you call {{{FieldFile.open(mode=NOT_RB)}}}, it will always
 open in mode {{{rb}}}. This is due to {{{FieldFile.open}}} calling the
 {{{self.file}}} property, which auto-opens in 'rb' mode.
 {{{FieldFile.open}}} attempts to subsequently call {{{open}}} on this new
 file, but that does not reopen the file again.

 My suggested workaround for:
 * {{{field_file.open(mode='w+b')}}}
 is:
 * {{{field_file.file = field_file.storage.open(field_file.name, 'w+b')}}}

-- 
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] #16986: Model.clean cannot report errors on individual fields

2011-10-11 Thread Django

#16986: Model.clean cannot report errors on individual fields
-+
 Reporter:  davidfstr|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by davidfstr):

 * cc: davidfstr (added)


Comment:

 (Hopefully the CC change will subscribe me to future updates)

 Agreed that it would be good to isolate {{{hasattr(..., "message_dict")}}}
 logic.

 I have a different approach though: make
 {{{ValidationError.message_dict}}} a property that self-initializes to
 '__all__': self.messages. I need to check whether this affects
 backward-compatibility though. Then I'll look at updating the patch.

-- 
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] r16961 - in django/trunk/docs: ref topics/http

2011-10-11 Thread noreply

Author: carljm
Date: 2011-10-11 15:21:14 -0700 (Tue, 11 Oct 2011)
New Revision: 16961

Modified:
   django/trunk/docs/ref/request-response.txt
   django/trunk/docs/ref/template-response.txt
   django/trunk/docs/topics/http/middleware.txt
Log:
Fixed #17035, #17036 -- Clarified documentation regarding TemplateResponse and 
middleware handling. Refs #16004. Thanks ptone.

Modified: django/trunk/docs/ref/request-response.txt
===
--- django/trunk/docs/ref/request-response.txt  2011-10-11 21:55:45 UTC (rev 
16960)
+++ django/trunk/docs/ref/request-response.txt  2011-10-11 22:21:14 UTC (rev 
16961)
@@ -758,3 +758,10 @@
 .. class:: HttpResponseServerError
 
 Acts just like :class:`HttpResponse` but uses a 500 status code.
+
+.. note::
+
+If a custom subclass of :class:`HttpResponse` implements a ``render``
+method, Django will treat it as emulating a
+:class:`~django.template.response.SimpleTemplateResponse`, and the
+``render`` method must itself return a valid response object.

Modified: django/trunk/docs/ref/template-response.txt
===
--- django/trunk/docs/ref/template-response.txt 2011-10-11 21:55:45 UTC (rev 
16960)
+++ django/trunk/docs/ref/template-response.txt 2011-10-11 22:21:14 UTC (rev 
16961)
@@ -126,7 +126,8 @@
 .. method:: SimpleTemplateResponse.render():
 
 Sets :attr:`response.content` to the result obtained by
-:attr:`SimpleTemplateResponse.rendered_content`.
+:attr:`SimpleTemplateResponse.rendered_content`, runs all post-rendering
+callbacks, and returns the resulting response object.
 
 :meth:`~SimpleTemplateResponse.render()` will only have an effect
 the first time it is called. On subsequent calls, it will return

Modified: django/trunk/docs/topics/http/middleware.txt
===
--- django/trunk/docs/topics/http/middleware.txt2011-10-11 21:55:45 UTC 
(rev 16960)
+++ django/trunk/docs/topics/http/middleware.txt2011-10-11 22:21:14 UTC 
(rev 16961)
@@ -121,22 +121,20 @@
 
 .. method:: process_template_response(self, request, response)
 
-``request`` is an :class:`~django.http.HttpRequest` object. ``response`` is the
-:class:`~django.template.response.SimpleTemplateResponse` subclass (e.g.
-:class:`~django.template.response.TemplateResponse`) object returned by a
-Django view.
+``request`` is an :class:`~django.http.HttpRequest` object. ``response`` is a
+subclass of :class:`~django.template.response.SimpleTemplateResponse` (e.g.
+:class:`~django.template.response.TemplateResponse`) or any response object
+that implements a ``render`` method.
 
-``process_template_response()`` must return an
-:class:`~django.template.response.SimpleTemplateResponse` (or its subclass)
-object. It could alter the given ``response`` by changing
-``response.template_name`` and ``response.context_data``, or it could
-create and return a brand-new
-:class:`~django.template.response.SimpleTemplateResponse` (or its subclass)
-instance.
+``process_template_response()`` must return a response object that implements a
+``render`` method. It could alter the given ``response`` by changing
+``response.template_name`` and ``response.context_data``, or it could create
+and return a brand-new
+:class:`~django.template.response.SimpleTemplateResponse` or equivalent.
 
 ``process_template_response()`` will only be called if the response
 instance has a ``render()`` method, indicating that it is a
-:class:`~django.template.response.TemplateResponse`.
+:class:`~django.template.response.TemplateResponse` or equivalent.
 
 You don't need to explicitly render responses -- responses will be
 automatically rendered once all template response middleware has been

-- 
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] #17035: clarify process_template_response API works with duck-typed TemplateResponse

2011-10-11 Thread Django

#17035: clarify process_template_response API works with duck-typed
TemplateResponse
-+-
 Reporter:  ptone|Owner:  ptone
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

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


Comment:

 In [16961]:
 {{{
 #!CommitTicketReference repository="" revision="16961"
 Fixed #17035, #17036 -- Clarified documentation regarding TemplateResponse
 and middleware handling. Refs #16004. Thanks ptone.
 }}}

-- 
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] #17036: Note that render is a special method name for HttpResponse objects

2011-10-11 Thread Django

#17036: Note that render is a special method name for HttpResponse objects
-+-
 Reporter:  ptone|Owner:  ptone
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by carljm):

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


Comment:

 In [16961]:
 {{{
 #!CommitTicketReference repository="" revision="16961"
 Fixed #17035, #17036 -- Clarified documentation regarding TemplateResponse
 and middleware handling. Refs #16004. Thanks ptone.
 }}}

-- 
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] #16004: csrf_protect does not send cookie if view returns TemplateResponse

2011-10-11 Thread Django

#16004: csrf_protect does not send cookie if view returns TemplateResponse
-+
 Reporter:  lukeplant|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.csrf |  Version:  1.3
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|
-+

Comment (by carljm):

 In [16961]:
 {{{
 #!CommitTicketReference repository="" revision="16961"
 Fixed #17035, #17036 -- Clarified documentation regarding TemplateResponse
 and middleware handling. Refs #16004. Thanks ptone.
 }}}

-- 
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] r16960 - django/trunk/tests/regressiontests/admin_inlines

2011-10-11 Thread noreply

Author: carljm
Date: 2011-10-11 14:55:45 -0700 (Tue, 11 Oct 2011)
New Revision: 16960

Modified:
   django/trunk/tests/regressiontests/admin_inlines/tests.py
Log:
Fixed some tests from r16934 to be auto-id-independent.

Modified: django/trunk/tests/regressiontests/admin_inlines/tests.py
===
--- django/trunk/tests/regressiontests/admin_inlines/tests.py   2011-10-11 
20:43:11 UTC (rev 16959)
+++ django/trunk/tests/regressiontests/admin_inlines/tests.py   2011-10-11 
21:55:45 UTC (rev 16960)
@@ -230,12 +230,14 @@
 self.user.user_permissions.add(permission)
 
 author = Author.objects.create(pk=1, name=u'The Author')
-author.books.create(name=u'The inline Book')
+book = author.books.create(name=u'The inline Book')
 self.author_change_url = '/admin/admin_inlines/author/%i/' % author.id
+self.book_id = book.id
 
 holder = Holder2.objects.create(dummy=13)
-Inner2.objects.create(dummy=42, holder=holder)
+inner2 = Inner2.objects.create(dummy=42, holder=holder)
 self.holder_change_url = '/admin/admin_inlines/holder2/%i/' % holder.id
+self.inner2_id = inner2.id
 
 self.assertEqual(
 self.client.login(username='admin', password='secret'),
@@ -308,7 +310,7 @@
 self.assertContains(response, 'Author-book relationships')
 self.assertContains(response, 'Add another Author-Book Relationship')
 self.assertContains(response, 'value="4" 
id="id_Author_books-TOTAL_FORMS"')
-self.assertContains(response, 'Inner2s')
 # Just the one form for existing instances
 self.assertContains(response, 'value="1" 
id="id_inner2_set-TOTAL_FORMS"')
-self.assertContains(response, 'Inner2s')
 # One form for existing instance and three extra for new
 self.assertContains(response, 'value="4" 
id="id_inner2_set-TOTAL_FORMS"')
-self.assertContains(response, 'Inner2s')
 # One form for existing instance only, no new
 self.assertContains(response, 'value="1" 
id="id_inner2_set-TOTAL_FORMS"')
-self.assertContains(response, 'Inner2s')
 # One form for existing instance only, three for new
 self.assertContains(response, 'value="4" 
id="id_inner2_set-TOTAL_FORMS"')
-self.assertContains(response, 'http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17028: diveintopython.org links now dead

2011-10-11 Thread Django

#17028: diveintopython.org links now dead
---+
 Reporter:  django@…   |Owner:  pyriku
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by pyriku):

 * owner:  nobody => pyriku
 * has_patch:  0 => 1


-- 
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] #17036: Note that render is a special method name for HttpResponse objects

2011-10-11 Thread Django

#17036: Note that render is a special method name for HttpResponse objects
-+-
 Reporter:  ptone|Owner:  ptone
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ptone):

 note, that perhaps the note could got elsewhere in the doc, this can be
 moved at will of course by the comitter

-- 
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] r16959 - django/trunk/django/template

2011-10-11 Thread noreply

Author: Alex
Date: 2011-10-11 13:43:11 -0700 (Tue, 11 Oct 2011)
New Revision: 16959

Modified:
   django/trunk/django/template/base.py
Log:
Simplify some code to have one loop, rather than two.

Modified: django/trunk/django/template/base.py
===
--- django/trunk/django/template/base.py2011-10-11 18:23:08 UTC (rev 
16958)
+++ django/trunk/django/template/base.py2011-10-11 20:43:11 UTC (rev 
16959)
@@ -814,10 +814,11 @@
 bits = []
 for node in self:
 if isinstance(node, Node):
-bits.append(self.render_node(node, context))
+bit = self.render_node(node, context)
 else:
-bits.append(node)
-return mark_safe(u''.join([force_unicode(b) for b in bits]))
+bit = node
+bits.append(force_unicode(bit))
+return mark_safe(u''.join(bits))
 
 def get_nodes_by_type(self, nodetype):
 "Return a list of all nodes of the given type"

-- 
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] #17036: Note that render is a special method name for HttpResponse objects

2011-10-11 Thread Django

#17036: Note that render is a special method name for HttpResponse objects
-+-
 Reporter:  ptone|Owner:  ptone
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ptone):

 * needs_better_patch:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 https://github.com/django/django/pull/64

-- 
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] #17036: Note that render is a special method name for HttpResponse objects

2011-10-11 Thread Django

#17036: Note that render is a special method name for HttpResponse objects
--+---
 Reporter:  ptone |  Owner:  ptone
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 While an edge case, it should be noted that any HttpResponse subclass that
 implements render() will be assumed to be attempting to emulate a
 TemplateResponse object with regard to template_response middleware.

-- 
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] #17035: clarify process_template_response API works with duck-typed TemplateResponse

2011-10-11 Thread Django

#17035: clarify process_template_response API works with duck-typed
TemplateResponse
-+-
 Reporter:  ptone|Owner:  ptone
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ptone):

 * needs_docs:   => 0
 * has_patch:  0 => 1
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 https://github.com/django/django/pull/63

-- 
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] #17035: clarify process_template_response API works with duck-typed TemplateResponse

2011-10-11 Thread Django

#17035: clarify process_template_response API works with duck-typed
TemplateResponse
--+---
 Reporter:  ptone |  Owner:  ptone
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 The API for the template response middleware was documented in a way that
 implied only a subclass of SimpleTemplateResponse was acceptable as the
 response object, but in fact duck typing is specifically and deliberately
 employed.

-- 
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] #10060: Multiple table annotation failure

2011-10-11 Thread Django

#10060: Multiple table annotation failure
-+
 Reporter:  svsharma@…   |Owner:
 Type:  Bug  |   Status:  new
Component:  ORM aggregation  |  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|UI/UX:  0
-+

Comment (by anonymous):

 Whoa, thought I was doing something wrong in my code until I searched and
 found this. Isn't this kind of a big deal? As in, with this bug, isn't
 Django's aggregation basically worthless for anyone who's not doing it on
 a single table, or did I miss something?

-- 
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] r16958 - django/trunk/docs/ref/models

2011-10-11 Thread noreply

Author: gabrielhurley
Date: 2011-10-11 11:23:08 -0700 (Tue, 11 Oct 2011)
New Revision: 16958

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Corrected a reST formatting problem in the queryset reference docs.


Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2011-10-11 17:36:05 UTC (rev 
16957)
+++ django/trunk/docs/ref/models/querysets.txt  2011-10-11 18:23:08 UTC (rev 
16958)
@@ -1307,10 +1307,10 @@
 This has a number of caveats though:
 
 * The model's ``save()`` method will not be called, and the ``pre_save`` and
-``post_save`` signals will not be sent.
+  ``post_save`` signals will not be sent.
 * It does not work with child models in a multi-table inheritance scenario.
 * If the model's primary key is an :class:`~django.db.models.AutoField` it
-does not retrieve and set the primary key attribute, as ``save()`` does.
+  does not retrieve and set the primary key attribute, as ``save()`` does.
 
 count
 ~

-- 
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] r16957 - in django/trunk/django: template utils

2011-10-11 Thread noreply

Author: Alex
Date: 2011-10-11 10:36:05 -0700 (Tue, 11 Oct 2011)
New Revision: 16957

Modified:
   django/trunk/django/template/base.py
   django/trunk/django/utils/encoding.py
Log:
Change some string literals to be unicode, because:

* It's the most micro of optimizations (forget I even said it)
* It makes significantly more sense semantically, given these are functions 
which return unicode.

Modified: django/trunk/django/template/base.py
===
--- django/trunk/django/template/base.py2011-10-10 22:19:59 UTC (rev 
16956)
+++ django/trunk/django/template/base.py2011-10-11 17:36:05 UTC (rev 
16957)
@@ -817,7 +817,7 @@
 bits.append(self.render_node(node, context))
 else:
 bits.append(node)
-return mark_safe(''.join([force_unicode(b) for b in bits]))
+return mark_safe(u''.join([force_unicode(b) for b in bits]))
 
 def get_nodes_by_type(self, nodetype):
 "Return a list of all nodes of the given type"

Modified: django/trunk/django/utils/encoding.py
===
--- django/trunk/django/utils/encoding.py   2011-10-10 22:19:59 UTC (rev 
16956)
+++ django/trunk/django/utils/encoding.py   2011-10-11 17:36:05 UTC (rev 
16957)
@@ -81,7 +81,7 @@
 # without raising a further exception. We do an
 # approximation to what the Exception's standard str()
 # output should be.
-s = ' '.join([force_unicode(arg, encoding, strings_only,
+s = u' '.join([force_unicode(arg, encoding, strings_only,
 errors) for arg in s])
 elif not isinstance(s, unicode):
 # Note: We use .decode() here, instead of unicode(s, encoding,
@@ -97,7 +97,7 @@
 # working unicode method. Try to handle this without raising a
 # further exception by individually forcing the exception args
 # to unicode.
-s = ' '.join([force_unicode(arg, encoding, strings_only,
+s = u' '.join([force_unicode(arg, encoding, strings_only,
 errors) for arg in s])
 return s
 

-- 
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] #16307: Unable to expand (resolve) template variable attribute when the variable is a python class

2011-10-11 Thread Django

#16307: Unable to expand (resolve) template variable attribute when the 
variable is
a python class
-+
 Reporter:  sorin|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by carljm):

 * status:  reopened => closed
 * resolution:   => wontfix


Comment:

 I do find this a tough call, but in the end I come down with Luke. If I
 were designing the template language from scratch I might do things
 differently, but the benefit here just isn't sufficient or evident enough
 to warrant the backwards-compatibility problems.

-- 
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] #16050: media directory still lives on in /django/contrib/admin

2011-10-11 Thread Django

#16050: media directory still lives on in /django/contrib/admin
--+
 Reporter:  EvilDMP   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by carljm):

 Replying to [comment:5 anonymous]:
 > If you are using Apache to proxy to the Django admin interface (to
 enable the admin interface to be served under a different HTTPS host, for
 example), what do you suggest doing now that ADMIN_MEDIA_PREFIX has been
 removed?
 >
 > e.g. https://secure.example.org/net-admin/ proxies internally to
 http://example.net/admin/ (and /admin/ is restricted to internal IPs
 only). STATIC_URL is set to /static/ so that it works fine for everything
 on the front end, but this then does not work as
 secure.example.org/static/ does not exist. If STATIC_URL is set to an
 absolute value of http://example.net/static/, then the admin will
 correctly give mixed HTTPS/HTTP warnings. There appear to be a lot of
 templates that would need overriding, so that doesn't seem like a good way
 to go. We use this set up on a number of sites, so it would be good if
 there was a simple way it could be continued.

 Seems like the solution is to set up your front-end proxy to also proxy
 the admin static assets under https://secure.example.org/net-
 admin/static/admin/.

 In any case, this question should be discussed on the django-users mailing
 list, not on a closed ticket.

-- 
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] #17026: Message storage backends section missing "just use x" (was: Docs section missing "just use x")

2011-10-11 Thread Django

#17026: Message storage backends section missing "just use x"
--+
 Reporter:  coolRR|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Indeed, this section is a bit confusing, mostly because it describes
 complex backwards-compatibility code. It could use a better structure.

-- 
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] #16679: Speed up signals by caching the reveicers per sender

2011-10-11 Thread Django

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 As I see it, your approach is the right one, at least as long as we don't
 want to support inherited signals. There are some problems when trying to
 make inherited signals work, though.

 The problem for inherited signals is that at the time the signal is
 registered, we don't necessarily know all of the sender's subclasses. And,
 when a model is created by the apploading code, we don't know the signals
 yet. So, we would need to update the signal datastructures when a new
 signal is connected, disconnected or a new subclass is registered in the
 app cache. In the two first cases, we should check all the subclasses of
 the sender, and in the last case we would need to check the parents of the
 sender.

 My approach to that problem is that when a signal is sent, we cache the
 found results. When a receiver is connected or disconnected we flush all
 the caches. This would make it perhaps easier to support inherited
 signals, as there is just one point when we need to check the parents and
 cache the results based on that. On the other hand, my version is very bad
 if you do dynamically connect / disconnect signals, as the caches would
 get flushed all the time and the caching would just increase the overhead,
 not reduce it. I don't know if dynamical connect is a common use case.

 Of course, there is no decision if we actually do want to support
 inherited signals. They would be useful, as one would usually want to have
 `BaseModel` pre_save/post_save sent when `InheritedModel` is saved.

-- 
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] #11857: TemporaryFile class is missing the closed - attribute

2011-10-11 Thread Django

#11857: TemporaryFile class is missing the closed - attribute
--+
 Reporter:  andi100   |Owner:  petar
 Type:  Bug   |   Status:  assigned
Component:  File uploads/storage  |  Version:
 Severity:  Normal|   Resolution:
 Keywords:  TemporaryFile closed  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by anonymous):

 The patch works fine for me.

 Environment  - Windows 2008 server, Apache + mod_wsgi, Django 1.3

-- 
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] #17034: 'Invalid literal for int' using admin site called with invalid parameters for inherited models

2011-10-11 Thread Django

#17034: 'Invalid literal for int' using admin site called with invalid 
parameters
for inherited models
---+
 Reporter:  ralphje|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When using the admin site, gibberish can be entered as the lookup
 parameter, at least with the change_view and the delete_view, which causes
 an error. The trace that is sent to me is as follows:

 {{{
 ERROR (internal IP): Internal Server Error:
 /admin/customers/customer/blahblah/

 Traceback (most recent call last):

  File "/./django-1.3/django/core/handlers/base.py", line 111, in
 get_response
response = callback(request, *callback_args, **callback_kwargs)

  File "/./django-1.3/django/contrib/admin/options.py", line 307, in
 wrapper
return self.admin_site.admin_view(view)(*args, **kwargs)

  File "/./django-1.3/django/utils/decorators.py", line 93, in
 _wrapped_view
response = view_func(request, *args, **kwargs)

  File "/./django-1.3/django/views/decorators/cache.py", line 79, in
 _wrapped_view_func
response = view_func(request, *args, **kwargs)

  File "/./django-1.3/django/contrib/admin/sites.py", line 197, in
 inner
return view(request, *args, **kwargs)

  File "/./django-1.3/django/utils/decorators.py", line 28, in _wrapper
return bound_func(*args, **kwargs)

  File "/./django-1.3/django/utils/decorators.py", line 93, in
 _wrapped_view
response = view_func(request, *args, **kwargs)

  File "/./django-1.3/django/utils/decorators.py", line 24, in
 bound_func
return func(self, *args2, **kwargs2)

  File "/./django-1.3/django/db/transaction.py", line 217, in inner
res = func(*args, **kwargs)

  File "/./django-1.3/django/contrib/admin/options.py", line 947, in
 change_view
obj = self.get_object(request, unquote(object_id))

  File "/./django-1.3/django/contrib/admin/options.py", line 451, in
 get_object
return queryset.get(pk=object_id)

  File "/./django-1.3/django/db/models/query.py", line 341, in get
clone = self.filter(*args, **kwargs)

  File "/./django-1.3/django/db/models/query.py", line 550, in filter
return self._filter_or_exclude(False, *args, **kwargs)

  File "/./django-1.3/django/db/models/query.py", line 568, in
 _filter_or_exclude
clone.query.add_q(Q(*args, **kwargs))

  File "/./django-1.3/django/db/models/sql/query.py", line 1194, in
 add_q
can_reuse=used_aliases, force_having=force_having)

  File "/./django-1.3/django/db/models/sql/query.py", line 1129, in
 add_filter
connector)

  File "/./django-1.3/django/db/models/sql/where.py", line 67, in add
value = obj.prepare(lookup_type, value)

  File "/./django-1.3/django/db/models/sql/where.py", line 316, in
 prepare
return self.field.get_prep_lookup(lookup_type, value)

  File "/./django-1.3/django/db/models/fields/related.py", line 136, in
 get_prep_lookup
return self._pk_trace(value, 'get_prep_lookup', lookup_type)

  File "/./django-1.3/django/db/models/fields/related.py", line 209, in
 _pk_trace
v = getattr(field, prep_func)(lookup_type, v, **kwargs)

  File "/./django-1.3/django/db/models/fields/__init__.py", line 292,
 in get_prep_lookup
return self.get_prep_value(value)

  File "/./django-1.3/django/db/models/fields/__init__.py", line 479,
 in get_prep_value
return int(value)

 ValueError: invalid literal for int() with base 10: 'blahblah'
 }}}

 It seems that this error only occurs when using a inherited object. The
 Customer object in my project is defined as follows:

 {{{
 class Customer(Contact):
 language = models.CharField(_('language'), max_length=5,
 choices=languages, default='nl')
 (etc)

 objects = ContactManager()
 }}}

 Other inherited objects seem to have the same issue.

 This issue is quite low-priority, as only the admin site is affected and
 this only results in error mails to be sent when an user fails with its
 url. It's not a security leak.

-- 
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] #16307: Unable to expand (resolve) template variable attribute when the variable is a python class

2011-10-11 Thread Django

#16307: Unable to expand (resolve) template variable attribute when the 
variable is
a python class
-+
 Reporter:  sorin|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by rico):

 I think that expecting to initialize a class inside the template just
 because is looks like a callable is wrong.

 It's simple to work around this issue by initializing the class before
 passing to the template, but I can't do the opposite, to use a class I'll
 have to use a wrapper or some sort of data structure.

 But I know it's a tough decision and I'll leave to the core developers.
 Changing this behaviour could be a breaker for anyone using the example
 above.

-- 
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] #16679: Speed up signals by caching the reveicers per sender

2011-10-11 Thread Django

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Suor):

 Supplied updated patch which should be faster for no signals case

-- 
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] #16679: Speed up signals by caching the reveicers per sender

2011-10-11 Thread Django

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Suor):

 My patch is designed for large amount of signals. Adding some special
 casing for empty receivers should make it almost as fast as cached signals
 without actually caching anything. Still storing receivers in proper
 structure seems cleaner approach than caching.

 To make signals even faster we should drop weakrefs, they seem more
 confusing than 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.

Re: [Django] #16360: Add a standard entrypoint for WSGI to project template

2011-10-11 Thread Django

#16360: Add a standard entrypoint for WSGI to project template
--+
 Reporter:  jezdez|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by tinodb):

 * cc: tinodb (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] #4574: add CSS classes to rendered calendar

2011-10-11 Thread Django

#4574: add CSS classes to rendered calendar
-+-
 Reporter:  calvin@… |Owner:  xian
 Type:   |   Status:  reopened
  Cleanup/optimization   |  Version:  newforms-
Component:  contrib.admin|  admin
 Severity:  Normal   |   Resolution:
 Keywords:  nfa-someday  | Triage Stage:  Accepted
  javascript admin   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  1
Easy pickings:  1|
-+-
Changes (by julien):

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


Comment:

 Reverting spam closing.

-- 
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] #16679: Speed up signals by caching the reveicers per sender

2011-10-11 Thread Django

#16679: Speed up signals by caching the reveicers per sender
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I quickly tried your patch, but didn't see performance improvement in this
 case:

 {{{
 class A(models.Model):
 pass

 class B(models.Model):
 pass

 def recv1(*args, **kwargs):
 pass

 signals.pre_init.connect(recv1, sender=B, weak=False)
 signals.post_init.connect(recv1, sender=B, weak=False)

 for i in range(0, 1000):
 A(i)

 }}}

 Note that the connected signals for B are slowing down A `__init__`. This
 is the case where the cached signals (fast-signals2.diff) give the best
 performance increase.

-- 
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] #16128: cascade delete does not work for proxy models

2011-10-11 Thread Django

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I wonder if the right way would be to fix Model `__eq__` and Model
 `__hash__` to make proxy models equal to their "concrete" target? There is
 discussion about the equality operator in #16458.

-- 
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] #4574: add CSS classes to rendered calendar

2011-10-11 Thread Django

#4574: add CSS classes to rendered calendar
-+-
 Reporter:  calvin@… |Owner:  xian
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  newforms-
Component:  contrib.admin|  admin
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  nfa-someday  | Triage Stage:  Accepted
  javascript admin   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  1
Easy pickings:  1|
-+-
Changes (by anonymous):

 * needs_tests:  0 => 1


-- 
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] #4574: add CSS classes to rendered calendar

2011-10-11 Thread Django

#4574: add CSS classes to rendered calendar
-+-
 Reporter:  calvin@… |Owner:  xian
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  newforms-
Component:  contrib.admin|  admin
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  nfa-someday  | Triage Stage:  Accepted
  javascript admin   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  1|
-+-
Changes (by anonymous):

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


-- 
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] #17033: Flatpage app urls redirect to 404 template if custom handler404 is set and DEBUG = False

2011-10-11 Thread Django

#17033: Flatpage app urls redirect to 404 template if custom handler404 is set 
and
DEBUG = False
---+---
 Reporter:  kamelok|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:  handler404, flatpages
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 It appears only if `DEBUG = False`, any url that is not in urls.py (and
 Flatpage app urls are not) redirect to 404.
 If `DEBUG = True` - Flatpage app work as expected.
 If remove handler404 from urls - also Flatpages app work as expected.

 '''core.views.py'''

 {{{
 def custom_404_view(request):
 return render_to_response("404.html", {'event':
 Event.objects.get(pk=1)}, context_instance=RequestContext(request))

 def custom_500_view(request):
 return render_to_response("500.html", {},
 context_instance=RequestContext(request))

 }}}

 '''urls.py'''

 {{{
 # Handlers for 404 and 500
 handler404 = 'core.views.custom_404_view'
 handler500 = 'core.views.custom_500_view'
 }}}

-- 
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] #16050: media directory still lives on in /django/contrib/admin

2011-10-11 Thread Django

#16050: media directory still lives on in /django/contrib/admin
--+
 Reporter:  EvilDMP   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  1.3
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by anonymous):

 If you are using Apache to proxy to the Django admin interface (to enable
 the admin interface to be served under a different HTTPS host, for
 example), what do you suggest doing now that ADMIN_MEDIA_PREFIX has been
 removed?

 e.g. https://secure.example.org/net-admin/ proxies internally to
 http://example.net/admin/ (and /admin/ is restricted to internal IPs
 only). STATIC_URL is set to /static/ so that it works fine for everything
 on the front end, but this then does not work as
 secure.example.org/static/ does not exist. If STATIC_URL is set to an
 absolute value of http://example.net/static/, then the admin will
 correctly give mixed HTTPS/HTTP warnings. There appear to be a lot of
 templates that would need overriding, so that doesn't seem like a good way
 to go. We use this set up on a number of sites, so it would be good if
 there was a simple way it could be continued.

-- 
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] #16360: Add a standard entrypoint for WSGI to project template

2011-10-11 Thread Django

#16360: Add a standard entrypoint for WSGI to project template
--+
 Reporter:  jezdez|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by cataliniacob):

 * cc: iacobcatalin@… (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] #15372: manage.py adds to sys.path and forcibly imports the parent dir of the settings module

2011-10-11 Thread Django

#15372: manage.py adds to sys.path and forcibly imports the parent dir of the
settings module
-+-
 Reporter:  Jorge Vargas |Owner:  russellm
     |   Status:  reopened
 Type:  Bug  |  Version:  SVN
Component:  Core (Other) |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by cataliniacob):

 * cc: iacobcatalin@… (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] #16128: cascade delete does not work for proxy models

2011-10-11 Thread Django

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by thibault@…):

 I noticed that in the case of a ForeignKey to a proxy model, the
 constraint key is not created in MySql. I think it could be related, but
 tell me if anyone thinks I should open a new bug.

 {{{#!python
 class Parent(models.Model):
 name = models.CharField(max_length=25)

 class Father(Parent):
 class Meta:
 proxy = True

 def __unicode__(self):
 return "I'm your father, luke"

 class Child(models.Model):
 name = models.CharField(max_length=25)
 parent = models.ForeignKey(Parent, related_name='child_parent_set')
 father = models.ForeignKey(Father, related_name='child_father_set')
 }}}

 {{{#!sql
 mysql> SHOW CREATE TABLE tata_child;
 | tata_child | CREATE TABLE `tata_child` (
   `id` int(11) NOT NULL AUTO_INCREMENT,
   `name` varchar(25) NOT NULL,
   `parent_id` int(11) NOT NULL,
   `father_id` int(11) NOT NULL,
   PRIMARY KEY (`id`),
   KEY `tata_child_63f17a16` (`parent_id`),
   KEY `tata_child_656bfb9c` (`father_id`),
   CONSTRAINT `parent_id_refs_id_875b6ff2` FOREIGN KEY (`parent_id`)
 REFERENCES `tata_parent` (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=latin1
 }}}

-- 
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] #17025: sql/where.py WhereNode refactoring

2011-10-11 Thread Django

#17025: sql/where.py WhereNode refactoring
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:  orm cleanup  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by guettli):

 * cc: hv@… (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] #12467: More helpful error message when loading fixture with invalid date

2011-10-11 Thread Django

#12467: More helpful error message when loading fixture with invalid date
--+
 Reporter:  knutin|Owner:  raulcd
 Type:  New feature   |   Status:  assigned
Component:  Core (Serialization)  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by julien):

 That's a good question. One way would be to purposely trigger exceptions
 while the module is loaded to gather all the various error messages from
 `datetime.datetime()`, but that feels dirty... This is also dangerous as
 there's no guarantee that the messages will be the same on every version
 of Python.

 The most complete way would be for Django to do the same tests as
 `datetime.datetime()` and then provide its own messages. However, this
 wouldn't be very robust and would be annoying to maintain.

 Perhaps the safest way is to simply not give any granular error message
 and just say that it's an invalid date, as suggested in the new patch
 attached.

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

48 matches

Mail list logo