date:20130606

Re: [Django] #20566: Store previous string in po files

2013-06-06 Thread Django

#20566: Store previous string in po files
--+
 Reporter:  nijel |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  1.5
 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 claudep):

 I don't see any backwards compatibility issue with `--previous`.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.8c0ce5035275cffdfcc01fd699e63470%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16568: require_debug_false does not work as intended (backward incompatible)

2013-06-06 Thread Django

#16568: require_debug_false does not work as intended (backward incompatible)
-+
 Reporter:  andreas_pelme|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 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 charettes):

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


Comment:

 Please don't reopen closed/fixed ticket with no apparent reason.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.6391c3f9aed1662048eeea4e9fda3071%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16568: require_debug_false does not work as intended (backward incompatible)

2013-06-06 Thread Django

#16568: require_debug_false does not work as intended (backward incompatible)
-+
 Reporter:  andreas_pelme|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Release blocker  |   Resolution:
 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 venu ):

 * cc: kulala.venu@… (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.75c7e3d0e7423a58cc0c7fb59e69725e%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16568: require_debug_false does not work as intended (backward incompatible)

2013-06-06 Thread Django

#16568: require_debug_false does not work as intended (backward incompatible)
-+
 Reporter:  andreas_pelme|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  master
 Severity:  Release blocker  |   Resolution:
 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 venu ):

 * status:  closed => new
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.621aea3497d8f18f113bd64d04e0d79c%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20566: Store previous string in po files

2013-06-06 Thread Django

#20566: Store previous string in po files
--+
 Reporter:  nijel |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  1.5
 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 wim@…):

 @claudep I think it is nice to provide backwards compatibility, though I
 don't find it necessary for myself.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.81536525c25a07d44d675945bf832061%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20569: Add cleaned_form to supersede cleaned_data

2013-06-06 Thread Django

#20569: Add cleaned_form to supersede cleaned_data
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by wim@…):

 +1 I agree that validate is a more proper name than is_valid,
 -0 but I am not in favor of dropping or replacing the cleaned_data
 dictionary.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.39b06edb665492d4e4eb922eead8c6ca%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11294: Django administration Model list always shows Decimal with decimal places

2013-06-06 Thread Django

#11294: Django administration Model list always shows Decimal with decimal 
places
---+
 Reporter:  jason@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  master
 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 oinopion):

 * cc: tomek@… (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.d53d51b39e89a84d77e67ce168c9fd00%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11294: Django administration Model list always shows Decimal with decimal places

2013-06-06 Thread Django

* version: 1.1-beta => master

Comment:

The problem here is two folds:

1. By default, admin will not localize input values. Not localized input
is rendered as `str(value)`, which is `Decimal.__str__`. List display uses
`display_for_field`, which localizes value if I18N is on.
2. When forced to localize (by settings `ModelForm._opts.localized_fields
= '__all__'`), decimal input still does not honour
`DecimalField.decimal_places` and is displayed differently from list.

Fix for 2. is easy, overriding `_format_value` in NumberInput to correctly
use `number_format` with `decimal_places`.
Fix for 1. is not easy, if not impossible, tickets #13032 and #13546
mention problems with localizing inputs by default. At least we can better
document current admin behaviour and include instructions to change it.
Better yet, would be to include another `ModelAdmin` option to control
`localized_fields` in generated `ModelForm` classes.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/076.13adeec272aa891317af24a9cd0b35da%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20546: New model – ApproximateDateField

2013-06-06 Thread Django

#20546: New model – ApproximateDateField
-+-
 Reporter:  vericule@…   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Indeed.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/078.99897b27644bc5e02e9317e804b23d4e%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20546: New model – ApproximateDateField

2013-06-06 Thread Django

Comment (by lukeplant):

There is no reason why this feature needs to live in Django core, and at
the moment I don't think there is a big demand for it.

If there is already a 3rd party solution, use that. If it is not
maintained, and there is only one, that is evidence there isn't a huge
amount of demand for this feature. Accepting this feature request will not
magically create some people willing to write and maintain this code, so
I'm going to have to WONTFIX, sorry.

Please bring this up on the DevelopersMailingList if you want to persuade
us that there is big demand for this feature and it needs to be in Django
itself.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/078.409322e1e835be44cad472d5e9f82ac0%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20086: UserCreationForm does not support custom models.

2013-06-06 Thread Django

#20086: UserCreationForm does not support custom models.
--+--
 Reporter:  efrinut@… |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by james@…):

 what benjaoming said.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.5c37b93a87568ee2f9ad3a4e7205d477%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20568: templatetag truncatewords_html split words on special caracters

2013-06-06 Thread Django

#20568: templatetag truncatewords_html split words on special caracters
---+--
 Reporter:  yann0@…|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  1.3
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by bmispelon):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => worksforme
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Hi,

 I cannot reproduce the issue you're describing.
 I tried the following code with both 1.3 and master but it seems to be
 working correctly for me:
 {{{
 >>> from django.template.defaultfilters import truncatewords_html
 >>> s = u"Depuis mars 2008, le programme RECYC-FRIGO d’Hydro-Québec vous
 permet de vous débarrasser d’un vieil appareil, réfrigérateur ou
 congélateur, facilement [...]"
 >>> truncatewords_html(s, 18)
 u'Depuis mars 2008, le programme RECYC-FRIGO d\u2019Hydro-Qu\xe9bec vous
 permet de vous d\xe9barrasser d\u2019un vieil appareil,
 r\xe9frig\xe9rateur ...'
 }}}

 I'm closing this ticket as `worksforme`.
 Could you please reopen it with an example of a piece of code that shows
 the issue you're having?

 Thanks.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/075.c6cdc51bed18be059a4839bf6bebbaf2%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20570: HttpRequest.REQUEST is still mentioned in the documentation

2013-06-06 Thread Django

#20570: HttpRequest.REQUEST is still mentioned in the documentation
-+-
 Reporter:  jeff.revesz@…|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.5
Component:  Documentation|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by anonymous):

 Sorry, turns out was not RequestFactory either. I was hand-generating a
 request like this:

 {{{
 r = HttpRequest()
 r.method = 'GET'
 r.GET = QueryDict('foo')
 }}}

 RequestFactory( ) still works fine, this was just an oversight on my part.
 Sorry to waste everyone's time!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/082.81b6f94b60b596b9ef6dc9043e1b0f1b%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20570: HttpRequest.REQUEST is still mentioned in the documentation

2013-06-06 Thread Django

#20570: HttpRequest.REQUEST is still mentioned in the documentation
-+-
 Reporter:  jeff.revesz@…|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.5
Component:  Documentation|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by bmispelon):

 Hi,

 It seems to be working fine for me:
 {{{
 >>> from django.test.client import RequestFactory
 >>> request = RequestFactory().get('/foo/?bar=baz')
 >>> request.GET
 
 >>> request.REQUEST
 MergeDict(, )

 }}}

 Can you provide some steps to reproduce your issue?

 Thanks.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/082.b73585296edeb402fdfe572a2edb474e%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20570: HttpRequest.REQUEST is still mentioned in the documentation

2013-06-06 Thread Django

#20570: HttpRequest.REQUEST is still mentioned in the documentation
-+-
 Reporter:  jeff.revesz@…|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.5
Component:  Documentation|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by anonymous):

 Ah, sorry! I think my problem was that I was using RequestFactory
 https://docs.djangoproject.com/en/1.5/topics/testing/advanced/ to generate
 the request. My best guess is that the RequestFactory class does not
 produce an HttpRequest with a REQUEST attribute.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/082.48f865e856d82af1130dbe6676af89b9%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20570: HttpRequest.REQUEST is still mentioned in the documentation

2013-06-06 Thread Django

#20570: HttpRequest.REQUEST is still mentioned in the documentation
-+-
 Reporter:  jeff.revesz@…|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.5
Component:  Documentation|   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timo):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 It does still exist. Your link is to the wiki, not the official
 documentation: https://docs.djangoproject.com/en/dev/ref/request-
 response/#django.http.HttpRequest.REQUEST

 That being said, there is a ticket to deprecate it, #18659.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/082.02423e330d31d736a2d2ab21730c21a1%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20570: HttpRequest.REQUEST is still mentioned in the documentation

2013-06-06 Thread Django

#20570: HttpRequest.REQUEST is still mentioned in the documentation
--+
 Reporter:  jeff.revesz@… |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.5
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 The documentation page https://docs.djangoproject.com/en/dev/ref/request-
 response/ still mentions HttpRequest.REQUEST as an alternative to
 HttpRequest.GET and HttpRequest.POST

 However I get an error when I try to access this attribute, and in
 addition it does not appear in the class documentation at
 https://code.djangoproject.com/wiki/HttpRequest which leads me to believe
 that this attribute no longer exists. It should be removed from the the
 request-response documentation page.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ef8db342a27b0812333e67e9f8064a2b%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20569: Add cleaned_form to supersede cleaned_data

2013-06-06 Thread Django

#20569: Add cleaned_form to supersede cleaned_data
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by davidswelt):

 * cc: davidswelt (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.a7a8c00d6cfb80b7a902496e1b9064f2%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20569: Add cleaned_form to supersede cleaned_data

2013-06-06 Thread Django

#20569: Add cleaned_form to supersede cleaned_data
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Forms  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 The cleaned_data dictionary is not very elegant:


 {{{
 if form.is_valid():
 subject = form.cleaned_data['subject']
 }}}


 First, is_valid needs to be called, and it is not obvious from the naming
 of the method and the fields that this is what populates cleaned_data.

 Second, the ORM gives us regular fields rather than dictionary entries
 accessed as strings.

 I suggest a cleaner interface (first iteration):


 {{{
 if form.is_valid():
 form.cleaning()
 subject = form.subject
 # to switch back to the original, use form.cleaning(False)
 }}}


 The fields could be defined as getter methods (@property), but since the
 form is a custom user class, it may be easier to just swap the values upon
 calling cleaning.

 cleaning(False) is probably a rare operation.

 The advantage of this is that client code is less likely to access the
 original data in lieu of the cleaned data.

 Also, is_valid does not suggest that anything but a check occurs.  To
 avoid the extra call to cleaning, one could do this:


 {{{
 if form.validate():
 subject = form.subject
 # to switch back to the original, use form.cleaning(False)

 }}}

 The change would be backward compatible, as is_valid() and .cleaned_data
 work as before.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.3090c74746a0ca44ccdd4c4965b5064b%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20569: Add cleaned_form to supersede cleaned_data

2013-06-06 Thread Django

#20569: Add cleaned_form to supersede cleaned_data
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by david.reitter@…):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6e502c62aae58fd001b05657df5b065a%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20567: Document BoundField.id_for_label and how to set the 'id' of a widget (was: Documenting form widget initial attrs)

2013-06-06 Thread Django

#20567: Document BoundField.id_for_label and how to set the 'id' of a widget
--+
 Reporter:  littlepig |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.5
 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 timo):

 * cc: timograham@… (added)
 * has_patch:  0 => 1


Comment:

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

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.80347cdfe33ec0e394bb7558cf1849ae%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20564: Querying (exclude) on a GenericRelation's DateTimeField through a related object fails

2013-06-06 Thread Django

#20564: Querying (exclude) on a GenericRelation's DateTimeField through a
related
object fails
-+-
Reporter: nferrari |Owner: nobody
Type: Bug | Status: closed
Component: Database layer | Version:
(models, ORM) | 1.6-alpha-1
Severity: Release blocker | Resolution: fixed
Keywords: contenttype exclude | Triage Stage: Accepted
Has patch: 0| Needs documentation: 0
Needs tests: 0| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+-

Comment (by nferrari):

I really do not understand the new logic. If we look only at the first
query, with C objects and relationship with A. I'm looking for every C
object having either no relation with any A object OR having a
relationship only with some A objects having a value on the flag
DateTimeField. Thus, I'm excluding every C object having a relation with
some A objects having no value in the flag field.

This query makes sense to me: C.objects.exclude(a__flag=None)

I tried this one too: C.objects.exclude(a__flag__istrue=True) ... but the
result is the same.

Does that make sense to you? Maybe I could find an example more explicit
than A, B and C objects...

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.df2324320f17f477b5f21c7a8a2e4e2d%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20568: templatetag truncatewords_html split words on special caracters

2013-06-06 Thread Django

#20568: templatetag truncatewords_html split words on special caracters
+
 Reporter:  yann0@… |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Utilities   |Version:  1.3
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I'm working with a Englsih / French website and when I use
 truncatewords_html with french texts with special caracters like "é,è,à,
 etc." (which is very common), it split words in half at thoses caracters.

 Example:
 Depuis mars 2008, le programme RECYC-FRIGO d’Hydro-Québec vous permet de
 vous débarrasser d’un vieil appareil, réfrigérateur ou congélateur,
 facilement [...]

 become:
 Depuis mars 2008, le programme RECYC-FRIGO d’Hydro-Québec vous permet de
 vous débarrasser d’un vieil appareil, r ...

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.4cc1453a3068e2882bf76ef2e3f1d724%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6785: QuerySet.get() should only attempt to fetch a limited number of rows (was: QuerySet.get(), nit-pick / optimize)

2013-06-06 Thread Django

#6785: QuerySet.get() should only attempt to fetch a limited number of rows
-+-
 Reporter:  deadwisdom   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  wontfix
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by timo):

 * cc: timograham@… (added)
 * needs_better_patch:  0 => 1
 * component:  Uncategorized => Database layer (models, ORM)
 * version:  queryset-refactor => master
 * keywords:  qs-rf =>
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Seems like there's consensus to re-open this:
 https://groups.google.com/d/topic/django-developers/PkzS9Wv6hIU/discussion

 Pull request (which needs improvement):
 https://github.com/django/django/pull/1139

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.28c5cf8781a6062ecfa5ecb8e6456079%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19875: Tutorial should have include ALLOWED_HOSTS setting

2013-06-06 Thread Django

#19875: Tutorial should have include ALLOWED_HOSTS setting
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  ALLOWED_HOSTS,   |  Needs documentation:  0
  tutorial   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by timo):

 Thanks, updated in a pull request. Moved the logic to the `handle()`
 method and also added a test. https://github.com/django/django/pull/1249

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.44ac61588a12f8cea08cbd680f648a3d%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20434: Have a template tag grammar instead of handling token/parser for every tag, and make it possible to introspect the grammar.

2013-06-06 Thread Django

#20434: Have a template tag grammar instead of handling token/parser for every 
tag,
and make it possible to introspect the grammar.
-+-
 Reporter:  jonathanslenders |Owner:
 Type:  New feature  |  jonathanslenders
Component:  Template system  |   Status:  assigned
 Severity:  Normal   |  Version:
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by jonathanslenders):

 After using "djangobench -t 200":

 {{{
 Running 'l10n_render' benchmark ...
 Min: 0.004818 -> 0.004467: 1.0786x faster
 Avg: 0.005679 -> 0.005978: 1.0527x slower
 Significant (t=-2.910514)
 Stddev: 0.00103 -> 0.00103: 1.0052x smaller (N = 200)

 Running 'template_compilation' benchmark ...
 Min: 0.48 -> 0.000130: 2.7114x slower
 Avg: 0.000560 -> 0.000572: 1.0203x slower
 Not significant
 Stddev: 0.00149 -> 0.00158: 1.0631x larger (N = 200)

 Running 'template_render' benchmark ...
 Min: 0.007676 -> 0.009130: 1.1894x slower
 Avg: 0.010612 -> 0.011010: 1.0375x slower
 Not significant
 Stddev: 0.00384 -> 0.00181: 2.1225x smaller (N = 200)

 Running 'template_render_simple' benchmark ...
 Min: 0.52 -> 0.79: 1.5229x slower
 Avg: 0.000346 -> 0.000179: 1.9358x faster
 Not significant
 Stddev: 0.00137 -> 0.00134: 1.0233x smaller (N = 200)
 }}}

 Not perfectly stable, but better. There was not really any other load on
 the machine.
 I guess there's no notable difference in performance, but feel free to run
 the benchmarks again.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.f2ff7e65dfb9a50d4ff5377e0caa06fb%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20567: Documenting form widget initial attrs

2013-06-06 Thread Django

#20567: Documenting form widget initial attrs
--+
 Reporter:  littlepig |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by timo):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => timo
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I'll work on this. Think it makes sense to also document
 `BoundField.id_for_label` as noted in #12856.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.42f1d015e9a2392ca5b3d6d0f1685989%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 80b151: Bumped verion numbers for 1.6a1.

2013-06-06 Thread GitHub

Branch: refs/heads/master
Home: https://github.com/django/django
Commit: 80b15113112d7852bc262af47c18cd02ff904492

https://github.com/django/django/commit/80b15113112d7852bc262af47c18cd02ff904492
Author: Jacob Kaplan-Moss
Date: 2013-06-06 (Thu, 06 Jun 2013)

Changed paths:
M django/__init__.py
M setup.py

Log Message:
---
Bumped verion numbers for 1.6a1.

Commit: 357d62d9f2972bf1bc21e5835c12c849143e06af

https://github.com/django/django/commit/357d62d9f2972bf1bc21e5835c12c849143e06af
Author: Jacob Kaplan-Moss
Date: 2013-06-06 (Thu, 06 Jun 2013)

Changed paths:
M docs/ref/utils.txt
M docs/topics/i18n/timezones.txt

Log Message:
---
Explained that timezone.now() always returns times in UTC.

The docs were ambiguous about the time zone for now(), leading people to
assume that it would be the current time zone rather that UTC.

Compare: https://github.com/django/django/compare/e2518fdf46a6...357d62d9f297

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/51b0b35d4c304_b74827ddc7942f%40hookshot-fe4-pe1-prd.aws.github.net.mail?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12856: Decide on public API/documentation for form.BoundField attributes

2013-06-06 Thread Django

#12856: Decide on public API/documentation for form.BoundField attributes
-+-
 Reporter:  mnbayazit|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  boundfield required  |  Needs documentation:  1
  is_hidden auto_id  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by timo):

 * component:  Forms => 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.a70baed80de891e9101a1fbe72386d2e%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20564: Querying (exclude) on a GenericRelation's DateTimeField through a related object fails

2013-06-06 Thread Django

#20564: Querying (exclude) on a GenericRelation's DateTimeField through a 
related
object fails
-+-
 Reporter:  nferrari |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.6-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  contenttype exclude  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I believe 1.5 just didn't handle these queries correctly. For example the
 queryset ` C.objects.filter(b__a__flag=None)` resulted in this SQL:
 {{{
 SELECT "generic_relations_regress_c"."id",
 "generic_relations_regress_c"."b_id" FROM "generic_relations_regress_c"
 INNER JOIN "generic_relations_regress_b" ON
 ("generic_relations_regress_c"."b_id" =
 "generic_relations_regress_b"."id")
 LEFT OUTER JOIN "generic_relations_regress_a" ON
 ("generic_relations_regress_b"."id" =
 "generic_relations_regress_a"."object_id")
 LEFT OUTER JOIN "django_content_type" ON
 ("generic_relations_regress_a"."content_type_id" =
 "django_content_type"."id")
 WHERE ("generic_relations_regress_a"."flag" IS NULL AND
 "django_content_type"."id" = 25 )
 ORDER BY "generic_relations_regress_c"."id" ASC
 }}}
 Note the LEFT OUTER JOIN + contenttype id restriction in WHERE clause.
 That just can't be correct (the LEFT OUTER JOIN doesn't work if it is
 constrained like that in WHERE clause).

 The 1.6 version is this:
 {{{
 SELECT "generic_relations_regress_c"."id",
 "generic_relations_regress_c"."b_id"
 FROM "generic_relations_regress_c"
 INNER JOIN "generic_relations_regress_b" ON (
 "generic_relations_regress_c"."b_id" = "generic_relations_regress_b"."id"
 )
 LEFT OUTER JOIN "generic_relations_regress_a" ON (
 "generic_relations_regress_b"."id" =
 "generic_relations_regress_a"."object_id"
  AND ("generic_relations_regress_a"."content_type_id" = 28))
 WHERE "generic_relations_regress_a"."flag" IS NULL ORDER BY
 "generic_relations_regress_c"."id" ASC
 }}}
 Note the content_type_id restriction in JOIN clause itself. This seems
 correct to me.

 Also, in the JSON you gave there aren't actually any flag != null objects.
 So, the query `C.objects.filter(a__flag=None)` will find every C object
 (either there is no A at all, or the a has flag=None), and thus
 `C.objects.exclude(a__flag=None)` can't find anything.

 So, I believe that you are getting incorrect results in 1.5. Of course,
 the results might be what you want, but they aren't what the queries
 should produce.

 I wonder if we should add release notes about ORM 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ca783d548545685a3129dc9b002dbf0d%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19875: Tutorial should have include ALLOWED_HOSTS setting

2013-06-06 Thread Django

#19875: Tutorial should have include ALLOWED_HOSTS setting
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  ALLOWED_HOSTS,   |  Needs documentation:  0
  tutorial   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by claudep):

 Small nitpick about `self.stderr.write/exit`, I think that this could be
 replaced by raising `CommandError` instead.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ef5783bae207c596e1a934b4ef7e2127%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20566: Store previous string in po files

2013-06-06 Thread Django

#20566: Store previous string in po files
--+
 Reporter:  nijel |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  1.5
 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 claudep):

 Will we really offer a management command option for each msgmerge option?
 What about switching on the `--previous` flag without adding yet another
 option?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.8b0ec093dcafa7df4b3a389c893e4973%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20564: Querying (exclude) on a GenericRelation's DateTimeField through a related object fails

2013-06-06 Thread Django

#20564: Querying (exclude) on a GenericRelation's DateTimeField through a 
related
object fails
-+-
 Reporter:  nferrari |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.6-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  contenttype exclude  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Thanks, I will investigate this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c458e3fc4196cea596ae20538005549d%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20564: Querying (exclude) on a GenericRelation's DateTimeField through a related object fails

2013-06-06 Thread Django

#20564: Querying (exclude) on a GenericRelation's DateTimeField through a 
related
object fails
-+-
 Reporter:  nferrari |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.6-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  contenttype exclude  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by nferrari):

 I'm pretty sure because I use the same database for both shells. I just
 switch from a 1.5 to a 1.6 (trunk) environment!
 I uploaded the content types dump, where you see A, B and C are
 respectively 7, 8 and 9.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.6d8cf501a418c5d72ae8093a8400697f%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20564: Querying (exclude) on a GenericRelation's DateTimeField through a related object fails

2013-06-06 Thread Django

#20564: Querying (exclude) on a GenericRelation's DateTimeField through a 
related
object fails
-+-
 Reporter:  nferrari |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.6-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  contenttype exclude  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Are you sure you have same contentype IDs in both 1.5 and 1.6 databases?
 This will cause differing results. For the same reason the dump isn't easy
 to use - I don't actually know what the content_type values refer to in
 the dump.

 The contenttype ID mismatch would explain the difference - every `a__flag`
 is None if the contenttype ids do not match.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.688eb83e0de75640b1b368f177183f70%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20429: Add QuerySet.update_or_create method (was: Implementation of update_or_create)

2013-06-06 Thread Django

#20429: Add QuerySet.update_or_create method
-+-
 Reporter:  tunixman |Owner:
 Type:  New feature  |  elektrrrus
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  master
 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
-+-
Changes (by timo):

 * cc: timograham@… (added)
 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0
 * needs_tests:  1 => 0


Comment:

 Updated pull request to address outstanding issues:
 https://github.com/django/django/pull/1248

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.269f32b3a1e37eabd43b28572e466897%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20564: Querying (exclude) on a GenericRelation's DateTimeField through a related object fails

2013-06-06 Thread Django

#20564: Querying (exclude) on a GenericRelation's DateTimeField through a 
related
object fails
-+-
 Reporter:  nferrari |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.6-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  contenttype exclude  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by nferrari):

 Ok I updated the models to have a name CharField each, and inserted a few
 objects (see dump.json).

 The 1.5 shell returned:

 {{{
 In [1]: from foobar.models import *

 In [2]: C.objects.exclude(a__flag=None).count()
 Out[2]: 5

 In [3]: C.objects.exclude(b__a__flag=None).count()
 Out[3]: 4
 }}}

 While the new environment shell gives:

 {{{
 >>> from foobar.models import *
 >>> C.objects.exclude(a__flag=None).count()
 0
 >>> C.objects.exclude(b__a__flag=None).count()
 0
 }}}

 Old results are expected, let me know if you need more information.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.03949196a451cc79418eb66b33def2ec%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20565: Generic view descriptions should give template examples

2013-06-06 Thread Django

#20565: Generic view descriptions should give template examples
-+
 Reporter:  david.reitter@…  |Owner:  batisteo
 Type:  New feature  |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by batisteo):

 * owner:  nobody => batisteo
 * cc: batisteo (added)
 * status:  new => assigned


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/081.8b7bd8a3f4a8478ffa8d88bf1c891093%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20562: Docs: How to use django ORM with multiprocessing

2013-06-06 Thread Django

#20562: Docs: How to use django ORM with multiprocessing
---+
 Reporter:  guettli|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.5
 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 guettli):

 My rule of thumb: "fork() before connection.cursor is created. If it is
 None, it is safe to fork()". The same goes for other connections (for
 example memcached).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d4c6488076613e461a81056fcbecf90b%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] e2518f: Fixed #12337 - Honor ModelForm.Meta.exclude when s...

2013-06-06 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e2518fdf46a687454066b8a75263c9019b1e965d
  
https://github.com/django/django/commit/e2518fdf46a687454066b8a75263c9019b1e965d
  Author: Stephen Burrows 
  Date:   2013-06-06 (Thu, 06 Jun 2013)

  Changed paths:
M django/forms/models.py
M tests/forms_tests/tests/tests.py

  Log Message:
  ---
  Fixed #12337 - Honor ModelForm.Meta.exclude when saving ManyToManyFields.

Thanks margieroginski for the report.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/51b09673e96e2_2960114dde4699b2%40hookshot-fe3-pe1-prd.aws.github.net.mail?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12337: save_m2m() does not honor save_instance's exclude argument

2013-06-06 Thread Django

#12337: save_m2m() does not honor save_instance's exclude argument
+
 Reporter:  margieroginski  |Owner:  melinath
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"e2518fdf46a687454066b8a75263c9019b1e965d"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e2518fdf46a687454066b8a75263c9019b1e965d"
 Fixed #12337 - Honor ModelForm.Meta.exclude when saving ManyToManyFields.

 Thanks margieroginski for the report.
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.f2a0d1eabbddb3389892c4d5ee471fdd%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20483: Reduce the set of apps seen by individual tests

2013-06-06 Thread Django

Comment (by akaariai):

I did some more hacking. This time I tried to use
override_settings(INSTALLED_APPS). The result is maybe a bit cleaner, but
then again, maybe not...

It is now evident that we can't get fully rid of global state. The problem
is table truncation and the need to cascade into applications not in
current available_apps set. For example you might have app1 and app2 that
don't know about each other, but both contain foreign key to auth.user.
Now when app1 does flush, it will flush also auth.user, and that flush
needs to cascade to app2. This is impossible to do unless we want to use
TRUNCATE CASCADE (which could cascade to unmanaged models etc), or we have
global installed apps and models available somewhere (likely in global
app-cache). So, end result doesn't look much cleaner. (Fundamental problem
here is that the database schema itself is global state that is extremely
hard to get rid of).

Patch at https://github.com/akaariai/django/tree/pull_1240. We might still
try how things look when instantiating multiple app-caches. But I am not
sure if that will result in anything truly cleaner.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.50f8411f4a7868d7d86eb7d5fe171b24%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20564: Querying (exclude) on a GenericRelation's DateTimeField through a related object fails

2013-06-06 Thread Django

#20564: Querying (exclude) on a GenericRelation's DateTimeField through a 
related
object fails
-+-
 Reporter:  nferrari |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.6-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  contenttype exclude  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Yes, please do.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ea435c9b77e9d192d7352dfd7e9bd12e%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20564: Querying (exclude) on a GenericRelation's DateTimeField through a related object fails

2013-06-06 Thread Django

#20564: Querying (exclude) on a GenericRelation's DateTimeField through a 
related
object fails
-+-
 Reporter:  nferrari |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.6-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  contenttype exclude  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by nferrari):

 I just tried, unfortunately it seems the result count() is very diffent.
 Would you like me to provide some detailed tests?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d936234569d1758d4a7284463e500d04%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16855: select_related doesn't chain as expected

2013-06-06 Thread Django

#16855: select_related doesn't chain as expected
-+-
 Reporter:  Leo  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mjtamlyn):

 I was thinking about this when I committed the fix for #19080 - I think it
 should be reasonable (and a good compromise solution to this issue) to
 have effectively two reset-mechanisms on this function. With depth gone
 after 1.6, there will be three ways of calling `select_related`:

 `select_related('foo', 'bar')` is the preferred usage, where you specify
 the fields. Subsequent calls of this form will append to each other.
 `select_related()` removes list and replaces with "all" (actually roughly
 the same as original depth=5).
 `select_related(None)` removes list completely.

 I think this will be pretty consistent with the existing behaviour (given
 multiple calls with names are pretty weird now), and also more consistent
 with other similar functions (like `prefetch_related`).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.f403bc21c7dfa0c1a8784a1ed821cb31%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16855: select_related doesn't chain as expected

2013-06-06 Thread Django

#16855: select_related doesn't chain as expected
-+-
 Reporter:  Leo  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by oinopion):

 Described `list_select_related` change was committed as fix for #19080
 
([https://github.com/django/django/commit/9ed971f4f1d2f05ecf7e2760556259eb2dca85f8
 9ed971f4]), though it does not deprecate the Boolean variant.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.d0425866bf95cb8781f7383fc44fd98b%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20502: AppResolutionOrderI18NTests fails if 'de' locale cached by previous test

2013-06-06 Thread Django

#20502: AppResolutionOrderI18NTests fails if 'de' locale cached by previous test
---+
 Reporter:  gcc|Owner:  claudep
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  fixed
 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 Claude Paroz ):

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


Comment:

 In [changeset:"b67f2ac8e6f8cdef237590ffb2c85fc30454ba75"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b67f2ac8e6f8cdef237590ffb2c85fc30454ba75"
 Fixed #20502 (again) -- More i18n cache flush in tests

 Thanks Timo Graham for noticing the failures.
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.6168fe7820eedeb2161f498df5ec39db%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] b67f2a: Fixed #20502 (again) -- More i18n cache flush in t...

2013-06-06 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b67f2ac8e6f8cdef237590ffb2c85fc30454ba75
  
https://github.com/django/django/commit/b67f2ac8e6f8cdef237590ffb2c85fc30454ba75
  Author: Claude Paroz 
  Date:   2013-06-06 (Thu, 06 Jun 2013)

  Changed paths:
M django/contrib/humanize/tests.py
M tests/forms_tests/tests/test_regressions.py
M tests/template_tests/tests.py

  Log Message:
  ---
  Fixed #20502 (again) -- More i18n cache flush in tests

Thanks Timo Graham for noticing the failures.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/51b080a929f55_49b212f7dd418789b%40hookshot-fe2-pe1-prd.aws.github.net.mail?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20564: Querying (exclude) on a GenericRelation's DateTimeField through a related object fails

2013-06-06 Thread Django

#20564: Querying (exclude) on a GenericRelation's DateTimeField through a 
related
object fails
-+-
 Reporter:  nferrari |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.6-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  contenttype exclude  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by nferrari):

 Thanks for your reactivity.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.249dc103ea8e3d3dc7176aa5c424af24%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20566: Store previous string in po files

2013-06-06 Thread Django

#20566: Store previous string in po files
--+
 Reporter:  nijel |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Internationalization  |  Version:  1.5
 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
--+
Changes (by ramiro):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.cc503f36a730c3f4aa79e735264633f6%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19875: Tutorial should have include ALLOWED_HOSTS setting

2013-06-06 Thread Django

#19875: Tutorial should have include ALLOWED_HOSTS setting
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.4
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  ALLOWED_HOSTS,   |  Needs documentation:  0
  tutorial   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by timo):

 New patch adds logic so `runserver` won't serve any requests if `DEBUG` is
 `False` and `ALLOWED_HOSTS` is empty (I'm unsure if this needs tests --
 `tests.admin_scripts.ManageRunserver` mocks the `run` method so I don't
 think anything in that method is actually tested).

 Also removed the note in the previous patch from `settings.py`.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.d7f6dc8add542eeb9dc42b9e8f376b56%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20122: Pluralize filter sometimes returns singular form instead of an empty string for invalid inputs

2013-06-06 Thread Django

#20122: Pluralize filter sometimes returns singular form instead of an empty 
string
for invalid inputs
-+-
 Reporter:  aaugustin|Owner:  littlepig
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by lrekucki):

 * needs_better_patch:  0 => 1
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.5dd4d7126b3e30d8fa5debaf9dc739a9%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20550: Add an option to preserve the database between test runs

2013-06-06 Thread Django

#20550: Add an option to preserve the database between test runs
---+--
 Reporter:  aaugustin  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by oinopion):

 I see another benefit of that: At {{ day_job }} we have database that
 can't be easily recreated by syncdb (it is used by other apps, too).
 Moreover, due to permissions we can't create and drop db on CI server. We
 currently we override `setup_database` and `teardown_database` to disable
 creation and deletion of test db altogether.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e9b922c9831ecb1470f23331dfb2945a%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20567: Documenting form widget initial attrs

2013-06-06 Thread Django

#20567: Documenting form widget initial attrs
--+
 Reporter:  littlepig |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.5
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 By the accepted answer on this [http://stackoverflow.com/questions/7910353
 /django-change-the-dom-id-at-form-field-level stackoverflow question], it
 seems it is possible to override the 'id' attribute of a widget without
 interfering with django's forms framework.

 I think this issue of initial values of attrs should be better documented
 on built-in widgets.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.1eb2c01b745c2182d95bf308b5734327%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20434: Have a template tag grammar instead of handling token/parser for every tag, and make it possible to introspect the grammar.

2013-06-06 Thread Django

#20434: Have a template tag grammar instead of handling token/parser for every
tag,
and make it possible to introspect the grammar.
-+-
Reporter: jonathanslenders |Owner:
Type: New feature | jonathanslenders
Component: Template system | Status: assigned
Severity: Normal | Version:
Keywords: | Resolution:
Has patch: 0| Triage Stage: Accepted
Needs tests: 0| Needs documentation: 0
Easy pickings: 0| Patch needs improvement: 0
|UI/UX: 0
-+-

Comment (by akaariai):

The test results seem somewhat random. Maybe there is some concurrent task
eating CPU randomly? Or maybe CPU throttling is causing problems, the
timing of the benchmarks surprisingly change if the CPU runs at basically
random speed...

The results show that there isn't likely any big change.

Try to see if you can stabilise the results. If the results wont
stabilise, I will try to benchmark this patch later on.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/074.5abd4ff62e7cc55c14c623970741f3d2%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20434: Have a template tag grammar instead of handling token/parser for every tag, and make it possible to introspect the grammar.

2013-06-06 Thread Django

#20434: Have a template tag grammar instead of handling token/parser for every 
tag,
and make it possible to introspect the grammar.
-+-
 Reporter:  jonathanslenders |Owner:
 Type:  New feature  |  jonathanslenders
Component:  Template system  |   Status:  assigned
 Severity:  Normal   |  Version:
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by jonathanslenders):

 @akaariai,

 I used this fork of djangobench, the latest version doesn't seem to work
 for django 1.5
 https://github.com/charettes/djangobench/tree/django-1.5

 This are the results. I'm not sure how to interpret them.

 {{{
 Running 'l10n_render' benchmark ...
 Min: 0.004574 -> 0.005087: 1.1122x slower
 Avg: 0.005782 -> 0.006625: 1.1459x slower
 Significant (t=-2.226464)
 Stddev: 0.00164 -> 0.00212: 1.2945x larger (N = 50)

 Running 'template_compilation' benchmark ...
 Min: 0.80 -> 0.000265: 3.3095x slower
 Avg: 0.000870 -> 0.000896: 1.0301x slower
 Not significant
 Stddev: 0.00305 -> 0.00291: 1.0499x smaller (N = 50)

 Running 'template_render' benchmark ...
 Min: 0.008402 -> 0.010302: 1.2261x slower
 Avg: 0.009809 -> 0.014170: 1.4446x slower
 Significant (t=-9.542369)Stddev: 0.00141 -> 0.00291: 2.0585x larger (N =
 50)

 Running 'template_render_simple' benchmark ...
 Min: 0.000113 -> 0.80: 1.4119x faster
 Avg: 0.000727 -> 0.000643: 1.1295x faster
 Not significant
 Stddev: 0.00410 -> 0.00366: 1.1216x smaller (N = 50)
 }}}

 Not sure whether the benchmarks test parsing or rendering, so feedback may
 be welcome.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.02fbc5f2c2c16cc79782614a627d1fe9%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19080: ChangeList.get_queryset() automatically applies select_related() in a very "brute" way

2013-06-06 Thread Django

#19080: ChangeList.get_queryset() automatically applies select_related() in a 
very
"brute" way
--+
 Reporter:  bberes|Owner:  oinopion
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:  performance   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Marc Tamlyn ):

 In [changeset:"9ed971f4f1d2f05ecf7e2760556259eb2dca85f8"]:
 {{{
 #!CommitTicketReference repository=""
 revision="9ed971f4f1d2f05ecf7e2760556259eb2dca85f8"
 Merge pull request #1245 from oinopion/list_select_related

 Fixed #19080 -- Fine-grained control over select_related in admin
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.77572365e1386d15828283f4458ebcfb%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19080: ChangeList.get_queryset() automatically applies select_related() in a very "brute" way

2013-06-06 Thread Django

#19080: ChangeList.get_queryset() automatically applies select_related() in a 
very
"brute" way
--+
 Reporter:  bberes|Owner:  oinopion
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admin |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 Keywords:  performance   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tomek Paczkowski ):

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


Comment:

 In [changeset:"0fd9f7c95f748764867dc148a2bacef807466d85"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0fd9f7c95f748764867dc148a2bacef807466d85"
 Fixed #19080 -- Fine-grained control over select_related in admin
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.dee6cf518a9c6369bf3d9f16cd7742a1%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 0fd9f7: Fixed #19080 -- Fine-grained control over select_r...

2013-06-06 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 0fd9f7c95f748764867dc148a2bacef807466d85
  
https://github.com/django/django/commit/0fd9f7c95f748764867dc148a2bacef807466d85
  Author: Tomek Paczkowski 
  Date:   2013-06-05 (Wed, 05 Jun 2013)

  Changed paths:
M django/contrib/admin/validation.py
M django/contrib/admin/views/main.py
M docs/ref/contrib/admin/index.txt
M tests/admin_changelist/admin.py
M tests/admin_changelist/tests.py
M tests/modeladmin/tests.py

  Log Message:
  ---
  Fixed #19080 -- Fine-grained control over select_related in admin


  Commit: 9ed971f4f1d2f05ecf7e2760556259eb2dca85f8
  
https://github.com/django/django/commit/9ed971f4f1d2f05ecf7e2760556259eb2dca85f8
  Author: Marc Tamlyn 
  Date:   2013-06-06 (Thu, 06 Jun 2013)

  Changed paths:
M django/contrib/admin/validation.py
M django/contrib/admin/views/main.py
M docs/ref/contrib/admin/index.txt
M tests/admin_changelist/admin.py
M tests/admin_changelist/tests.py
M tests/modeladmin/tests.py

  Log Message:
  ---
  Merge pull request #1245 from oinopion/list_select_related

Fixed #19080 -- Fine-grained control over select_related in admin


Compare: https://github.com/django/django/compare/31fd64ad8a98...9ed971f4f1d2

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/51b047db78573_b12fb7de01033c%40hookshot-fe4-pe1-prd.aws.github.net.mail?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20565: Generic view descriptions should give template examples

2013-06-06 Thread Django

#20565: Generic view descriptions should give template examples
-+
 Reporter:  david.reitter@…  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by bmispelon):

 * cc: bmispelon@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Comment:

 Seeing as we're already providing an example `views.py` and `urls.py` for
 most views, I think it makes sense to include an example template when it
 makes sense.

 The only example template I could find was in
 https://docs.djangoproject.com/en/1.5/topics/class-based-views/generic-
 display/#generic-views-of-objects.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/081.21a76b79e87b76321166156e089a33b8%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20562: Docs: How to use django ORM with multiprocessing

2013-06-06 Thread Django

#20562: Docs: How to use django ORM with multiprocessing
---+
 Reporter:  guettli|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.5
 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 akaariai):

 * stage:  Unreviewed => Accepted


Comment:

 I believe the only thing we can document is that "don't use fork()".
 Closing connection after fork() might be too late (who says that it is
 safe to close a connection from the child?). You need to do it before
 fork(). This might work. Or might not work. How about in-memory sqlite
 database, will that work? And so on...

 The problem isn't that we aren't willing to make fork() work, or document
 how you can use fork() with Django. The problem is that in general the
 libraries used by Django aren't fork() safe. We can't work around that.

 I am marking this as accepted. We should at least mention that you should
 not use fork(). In addition we should maybe recommend alternatives to
 fork(). I don't believe we should mention that "you can use fork() if you
 do the following things". It will be nearly impossible to actually
 guarantee that will be true.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.52b47b245bb4c0fc5542cbceeb334462%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20562: Docs: How to use django ORM with multiprocessing

2013-06-06 Thread Django

#20562: Docs: How to use django ORM with multiprocessing
---+--
 Reporter:  guettli|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by bmispelon):

 * cc: bmispelon@… (removed)
 * type:  New feature => Uncategorized
 * easy:  1 => 0
 * stage:  Accepted => Unreviewed


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.254528c5c27ab2420791f5262865fd30%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20562: Docs: How to use django ORM with multiprocessing

2013-06-06 Thread Django

#20562: Docs: How to use django ORM with multiprocessing
---+
 Reporter:  guettli|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by bmispelon):

 * cc: bmispelon@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Comment:

 Seeing as we're already providing an example `views.py` and `urls.py` for
 most views, I think it makes sense to include an example template when it
 makes sense.

 The only example template I could find was in
 https://docs.djangoproject.com/en/1.5/topics/class-based-views/generic-
 display/#generic-views-of-objects.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.d500729813ff7a11bae4e25150389897%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20566: Store previous string in po files

2013-06-06 Thread Django

#20566: Store previous string in po files
--+
 Reporter:  nijel |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Internationalization  |Version:  1.5
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 Currently while there is changed text to be translated, the string is only
 marked fuzzy not providing translators any information what has been
 changed. This can be improved by adding --previous parameter to msgmerge.

 There is pull request to implement this at
 https://github.com/django/django/pull/627

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.4aa2a42b734903f1bc5037994daa083e%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20483: Reduce the set of apps seen by individual tests

2013-06-06 Thread Django

Comment (by akaariai):

I think schema migrations will need a way to switch app-cache anyways.
Schema migrations will need to use different set of models, not just
"mask" some of them. So changing the app-cache is something we will likely
need in any case.

Swapping the app-cache isn't zero-risk business. Currently the app-cache
class is borg pattern (meaning every instance shares state). This must be
first changed so that we can create instances of the app-cache with
different state. Then we will also need app-cache swapping logic. To me
this is much higher risk than having some filtering capability in the app-
cache. In the current patch it is very likely that the app-cache itself
will not break if no "app mask" is set. If you remove the borg pattern
from app-cache who knows what might break in user apps (likely nothing,
but this is much harder to see)?

Another issue is the changes all around Django's code base. Those aren't
zero risk. I think we can get rid of almost all of those.

I tried the available_apps = self + ALWAYS_INSTALLED_APPS for every
TransactionTestCase, results for PostgreSQL and transactions +
transactions_regress is 54s, with Aymeric's patch from pull 1240 it is
5.6s, and on master it is 60s. Full test suite on master is around 4500s,
around 750 with self + ALWAYS_INSTALLED_APPS and 300s on pull 1240. In
addition there is one test that needs more than its own app
(proxy_model_inheritance.tests.ProxyModelInheritanceTests.test_table_exists()).
So, ALWAYS_INSTALLED_APPS is possible, but it doesn't give as good
performance as setting available_apps to smallest possible set and most of
all it doesn't solve any of the hard problems (app-cache changes or
changes in non-test code).

I will next try doing the following changes:
- all dependent apps need to be in the available_apps (that is, delete &
truncate cascades, too). This will get rid of the backends changes, and
changes in deletion.
- use of override_settings(INSTALLED_APPS=available_apps). This way we
should be able to get rid of changes in the signal listeners for
permissions, contenttypes and super user creation. Instead we can
disconnect the signal itself.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.e42c39266f2f6eacd435425bd0c591fa%40djangoproject.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

65 matches

Mail list logo