Re: [Django] #12990: New Field Type: JSONField

[Django]

#12990: New Field Type: JSONField
-+-
 Reporter:  paltman  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.2-alpha
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by wizpig64):

 * cc: wizpig64@… (removed)


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12990: New Field Type: JSONField

[Django]

#12990: New Field Type: JSONField
-+-
 Reporter:  paltman  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.2-alpha
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by davidfstr):

 * cc: davidfstr@… (removed)


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12747: Custom HTTP status reason phrases are not supported

[Django]

#12747: Custom HTTP status reason phrases are not supported
-+-
 Reporter:  Gustavo  |Owner:  gisle
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  http status, http| Triage Stage:  Accepted
  status reason, http status reason  |  Needs documentation:  0
  phrase |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Paul McNett ):

 This is hackish, quickly written, and tested for only 10 minutes or so but
 I implemented custom status codes by monkeypatching the
 django.core.handlers.wsgi.STATUS_CODE_TEXT dict like:

 {{{
 #!python
 import django.core.handlers.wsgi as wsgi

 class NextDict(dict):
 def __init__(self, *args, **kwargs):
 self._nextdict = {}
 super(NextDict, self).__init__(*args, **kwargs)

 def set_next(self, key, value):
 """
 The next time this key is queried, return the passed value.
 After that, use the default.
 """
 self._nextdict[key] = value

 def __getitem__(self, key):
 if key in self._nextdict:
 v = self._nextdict[key]
 del(self._nextdict[key])
 return v
 return super(NextDict, self).__getitem__(key)

 wsgi.STATUS_CODE_TEXT = NextDict(wsgi.STATUS_CODE_TEXT)
 }}}

 And then when I want my response to have a custom message for it's status
 code:

 {{{
 #!python
 class MyView(request):
 wsgi.STATUS_CODE_TEXT.set_next(200, "hello")
 return HttpResponse("hello again")
 }}}

 I googled for similar ideas and didn't find anyone doing this, so I
 thought it may give someone some ideas to develop this into a plugin or
 something. It wouldn't add overhead to the default (and reasonable)
 implementation, but would help some of us satisfy our requirements easily
 and without adding too much extra overhead...

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #8638: Provide setting to disable e-mail sending

[Django]

#8638: Provide setting to disable e-mail sending
---+-
 Reporter:  telenieko  |Owner:  telenieko
 Type:  Uncategorized  |   Status:  closed
Component:  Core (Mail)|  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 anonymous):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 This can now be done by selecting the dummy email backend:
 https://docs.djangoproject.com/en/dev/topics/email/#dummy-backend

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20241: QuerySets with callable filter args have said args evaluated only once

[Django]

#20241: QuerySets with callable filter args have said args evaluated only once
-+-
 Reporter:   |Owner:  nobody
  christopher.m.pike@…   |   Status:  new
 Type:  Bug  |  Version:  1.5
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by michael.c.urbanski@…):

 I was under the impression that callables in QuerySets, like callables in
 fields, were called as they were used.  Why pass in a callable if it's
 only evaluated once?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20247: qualify folders for .py files on tutorial

[Django]

#20247: qualify folders for .py files on tutorial
--+---
 Reporter:  gsavix|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:  docs tutorial 1 and 2
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 when following tutorial part 1 and part 2 because missing of folder
 qualify in some .py files, we need checking mysite/ and polls/ folders for
 understand what is correct place for update or create .py files.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20209: fields is empty after post with RadioWidget

[Django]

#20209: fields is empty after post with RadioWidget
---+--
 Reporter:  strelnikovdmitrij  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  master
 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
 * resolution:   => worksforme


Comment:

 Hello again,

 I'm still having trouble indentifying the issue you're talking about.

 After your comment, I updated the code to this:
 {{{
 #!python
 # view
 def update_applicant(request, pk):
 instance = get_object_or_404(Applicant, pk=pk)
 form = ApplicantForm(request.POST or None, instance=instance)
 if form.is_valid():
 applicant = form.save()
 return HttpResponse(applicant.get_gender_display()) # No issue
 here
 return render(request,
 'bug20209/applicant_form.html',
 {'form': form, 'object': instance}
 )

 # form
 class ApplicantForm(forms.ModelForm):
 foo = forms.CharField(required=True) # to trigger validation error

 class Meta:
 fields = ('gender',)
 model = Applicant
 widgets = {
 'gender': forms.RadioSelect,
 }
 }}}

 But the code still behaves as intended: the RadioSelect widget correctly
 displays the instance's gender (or whatever was selected in the case of an
 invalid form).

 I'm closing this again. If you can produce a minimal example reproducing
 your issue, please do reopen.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17657: ModelForm does not respect ModelMultipleChoiceField's to_field_name attribute

[Django]

#17657: ModelForm does not respect ModelMultipleChoiceField's to_field_name
attribute
+
 Reporter:  andreyfedoseev  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by valtron2000@…):

 * cc: valtron2000@… (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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20241: QuerySets with callable filter args have said args evaluated only once

[Django]

#20241: QuerySets with callable filter args have said args evaluated only once
-+-
 Reporter:   |Owner:  nobody
  christopher.m.pike@…   |   Status:  new
 Type:  Bug  |  Version:  1.5
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by bmispelon):

 * severity:  Release blocker => Normal
 * cc: bmispelon@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I can reproduce this issue.

 Using the following code, you can see that the callable arguments are
 indeed only evaluated once (when the urls.py file is read for the first
 time):

 {{{
 #!python
 from django.conf.urls import patterns, include, url
 from django.views.generic import ListView
 from django.utils import timezone

 from .models import Poll


 def foo():
 print('called')
 return timezone.now()


 urlpatterns = patterns('',
 url('^$', ListView.as_view(
 queryset=Poll.objects.filter(pub_date__lte=foo),
 )),
 )
 }}}

 However, unlike what it described on the linked SO post, I find that the
 issue is present on master, 1.5, and 1.4 so I don't think it's a
 regression.

 This feature (passing callable arguments to `filter`) is only mentionned
 in the 5th part of the tutorial and it's not documented anywhere else (see
 #11629).

 I'm not sure if this is a bug or intended behavior.

 I the issue here lies with the documentation and I would suggest re-
 writing that part of the tutorial.

 With normal pyhton code, anything sitting at the top-level of a module is
 evaluated when the file is read.
 In the case of querysets, they do magic things to delay their evaluation
 which makes the code kind-of work but I don't think it's a good habit to
 teach.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12091: [PATCH] Support for WSGI applications within Django

[Django]

#12091: [PATCH] Support for WSGI applications within Django
---+
 Reporter:  Gustavo|Owner:  Gustavo
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  WSGI   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by aaugustin):

 Discussion on django-developers: https://groups.google.com/d/msg/django-
 developers/137ZyyBNq5c/C6v7LUdZYNUJ

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20242: Django queryset 'in' operator fails on first call

[Django]

#20242: Django queryset 'in' operator fails on first call
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bmispelon):

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


Comment:

 Thanks for the detailed report.

 I can reproduce the issue and I'll add that as you implied, it seems to be
 related to `prefetch_related` since the problem does not appear when you
 use `all()` instead of `prefetch_related('projects')`.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20211: BoundField.label_tag now always escapes its `contents` parameter.

[Django]

#20211: BoundField.label_tag now always escapes its `contents` parameter.
-+-
 Reporter:  bmispelon|Owner:  bmispelon
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.5
 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
-+-

Comment (by bmispelon):

 After a comment from claudep, I removed the accidental fix for the
 regression.

 The regression will be fixed with #20221 by fixing `conditional_escape`
 which is the root cause of this bug.

 I've also added some more test for when a field as no id, which triggers a
 different code path in `label_tag` which wasn't tested 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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 709ee8: [1.5.x] Fixed #20243 - Clarified when RelatedManag...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 709ee83cd3ccbaeabcfcbb9391bb72d1bcaf01d3
  
https://github.com/django/django/commit/709ee83cd3ccbaeabcfcbb9391bb72d1bcaf01d3
  Author: Tim Graham 
  Date:   2013-04-11 (Thu, 11 Apr 2013)

  Changed paths:
M docs/ref/models/relations.txt

  Log Message:
  ---
  [1.5.x] Fixed #20243 - Clarified when RelatedManager.remove() exists.

Backport of 712a792713 from master



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20243: Related object reference - remove() method

[Django]

#20243: Related object reference - remove() method
---+
 Reporter:  john@… |  Owner:  nobody
 Type:  Bug| Status:  closed
Component:  Documentation  |Version:  1.5
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+

Comment (by Tim Graham ):

 In [changeset:"709ee83cd3ccbaeabcfcbb9391bb72d1bcaf01d3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="709ee83cd3ccbaeabcfcbb9391bb72d1bcaf01d3"
 [1.5.x] Fixed #20243 - Clarified when RelatedManager.remove() exists.

 Backport of 712a792713 from master
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 712a79: Fixed #20243 - Clarified when RelatedManager.remov...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 712a7927139e3abf9532d73bc88d35e0ebb3a022
  
https://github.com/django/django/commit/712a7927139e3abf9532d73bc88d35e0ebb3a022
  Author: Tim Graham 
  Date:   2013-04-11 (Thu, 11 Apr 2013)

  Changed paths:
M docs/ref/models/relations.txt

  Log Message:
  ---
  Fixed #20243 - Clarified when RelatedManager.remove() exists.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20243: Related object reference - remove() method

[Django]

#20243: Related object reference - remove() method
---+
 Reporter:  john@… |  Owner:  nobody
 Type:  Bug| Status:  closed
Component:  Documentation  |Version:  1.5
 Severity:  Normal | Resolution:  fixed
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  1
UI/UX:  0  |
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"712a7927139e3abf9532d73bc88d35e0ebb3a022"]:
 {{{
 #!CommitTicketReference repository=""
 revision="712a7927139e3abf9532d73bc88d35e0ebb3a022"
 Fixed #20243 - Clarified when RelatedManager.remove() exists.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 932318: [1.5.x] Removed incorrect phrase from DecimalField...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 93231851f8dd4e1882f601de9086d7aaf46b93a9
  
https://github.com/django/django/commit/93231851f8dd4e1882f601de9086d7aaf46b93a9
  Author: Andrew Badr 
  Date:   2013-04-11 (Thu, 11 Apr 2013)

  Changed paths:
M docs/ref/models/fields.txt

  Log Message:
  ---
  [1.5.x] Removed incorrect phrase from DecimalField docs

Backport of 408da7b457 from master



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 408da7: remove confusing phrase from DecimalField docs

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 408da7b4578ee6616d7a72fda9591364f254e9a6
  
https://github.com/django/django/commit/408da7b4578ee6616d7a72fda9591364f254e9a6
  Author: Andrew Badr 
  Date:   2013-04-11 (Thu, 11 Apr 2013)

  Changed paths:
M docs/ref/models/fields.txt

  Log Message:
  ---
  remove confusing phrase from DecimalField docs

The phrase "if it exists" was used in reference to the `decimal_places`
argument to `DecimalField`, when in fact that field is required.


  Commit: 9a62fc3f938dcc266a367a4537b516b67c48131b
  
https://github.com/django/django/commit/9a62fc3f938dcc266a367a4537b516b67c48131b
  Author: Tim Graham 
  Date:   2013-04-11 (Thu, 11 Apr 2013)

  Changed paths:
M docs/ref/models/fields.txt

  Log Message:
  ---
  Merge pull request #1008 from reverie/patch-2

Removed incorrect phrase from DecimalField docs.


Compare: https://github.com/django/django/compare/ddfc68379f47...9a62fc3f938d

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20245: STATIC_URL without trailing slash leads to confusingly broken URLs

[Django]

#20245: STATIC_URL without trailing slash leads to confusingly broken URLs
-+-
 Reporter:  hjkelly  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.5
Component:  contrib.staticfiles  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  staticfiles, static  |  Needs documentation:  0
  files, storage, url|  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by bmispelon):

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


Comment:

 I agree that this behavior is confusing, but it's sort of documented:
 https://docs.djangoproject.com/en/dev/ref/settings/#static-url mentions
 that this settings must end with a slash.

 However, I don't think the `{% static %}` tag or `FileSystemStorage` are
 good places to put code that basically validates settings.

 There used to be a comment for `MEDIA_URL` that warned you to use a
 trailing slash [1] and personally, I'd be favorable to put something like
 this back for `STATIC_URL`.

 The fact that that staticfiles view seems to serve the file wihtout a
 problem might itself be a bug I think. Note that there's a
 `django.contrib.staticfiles.utils.check_config` function where it might
 makes sense to check that `STATIC_URL` ends with the required trailing
 slash.

 [1]
 
https://github.com/django/django/blob/21ea58b8ccf95798271157876d59d46dcc745b0d/django/conf/project_template/project_name/settings.py#L51-L52

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20246: Use non-breakable space between amount and units

[Django]

#20246: Use non-breakable space between amount and units
--+
 Reporter:  vzima |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  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 claudep):

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


Comment:

 At first glance, I'd be in favour of that suggestion.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #2131: HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: HttpResponseSendFile for serving static files handler-specific sendfile
mechanism
-+-
 Reporter:   |Owner:  nobody
  ymasuda[at]ethercube.com   |   Status:  new
 Type:  New feature  |  Version:  master
Component:  HTTP handling|   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|
-+-
Changes (by chris.cahoon@…):

 * cc: chris.cahoon@… (removed)


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20246: Use non-breakable space between amount and units

[Django]

#20246: Use non-breakable space between amount and units
--+
 Reporter:  vzima |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Template system   |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Template filters which returns units should return strings with non-
 breakable space `'\xa0'` between amount and units. It increases
 legibility.

 Affected filters:
  * `filesizeformat`
  * `timesince`
  * `timeuntil`

 Reference:
  *
 http://en.wikipedia.org/wiki/Space_%28punctuation%29#Spaces_and_unit_symbols

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #2131: HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: HttpResponseSendFile for serving static files handler-specific sendfile
mechanism
-+-
 Reporter:   |Owner:  nobody
  ymasuda[at]ethercube.com   |   Status:  new
 Type:  New feature  |  Version:  master
Component:  HTTP handling|   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|
-+-
Changes (by sfllaw):

 * cc: sfllaw@… (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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

[Django]

#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  sfllaw
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by ivan_virabyan):

 As I understand there is currently no way to determine which values were
 added to many2many field in the 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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20245: STATIC_URL without trailing slash leads to confusingly broken URLs

[Django]

#20245: STATIC_URL without trailing slash leads to confusingly broken URLs
-+-
 Reporter:  hjkelly  |  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |Version:  1.5
Component:  contrib.staticfiles  |   Keywords:  staticfiles, static
 Severity:  Normal   |  files, storage, url
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 I've been working on a project that had its STATIC_URL misconfigured: no
 trailing slash. Normally, that'd be easy to diagnose, but the way it
 manifested itself was actually pretty confusing.

 Settings example (snippet):
 {{{
 STATIC_URL = '/staticfiles-cache'
 }}}

 Template example:
 {{{
 {% load staticfiles %}
 
 }}}

 Output:
 {{{
 
 }}}

 As you can see, the STATIC_URL is totally lost. It'd be a lot easier to
 debug if the URL came out as /staticfiles-cachejs/script.min.js, but when
 I first saw this, it left me dumbfounded.

 What's more, the correct URL (/staticfiles-cache/js/script.min.js)
 resolves correctly. It appears the URL resolution or the staticfiles view
 I'm using
 
([https://docs.djangoproject.com/en/1.5/ref/contrib/staticfiles/#django.contrib.staticfiles.urls.staticfiles_urlpatterns
 django.contrib.staticfiles.urls.staticfiles_urlpatterns]) doesn't need the
 trailing slash.

 The reason is because the template tag indirectly uses
 [http://docs.python.org/2/library/urlparse.html#urlparse.urljoin
 urlparse.urljoin] or
 
[http://docs.python.org/3.3/library/urllib.parse.html?highlight=urlparse#urllib.parse.urljoin
 urllib.parse.urljoin]. From what I can tell, that method is designed to
 take one URL as an example (in this case, STATIC_URL) and use it to make
 an absolute URL out of a second argument (in this case,
 'js/script.min.js'). Because it interprets the first argument's
 staticfiles-cache as a file name rather than a directory, it removes that
 slug and appends the second argument at the root.

 I think that behavior makes sense, but I want to do something to make this
 less confusing. My initial thought is to check the output (either in
 django.core.files.storage.FileSystemStorage.url or in the template tag
 itself) to make sure it starts with the base URL (or in the template tag,
 STATICFILES_URL directly).

 Can I get everyone's input on this approach? Am I barking up the wrong
 tree entirely? If not, should I do it in FileSystemStorage, or only in the
 static template tag? If to the template tag specifically, should I set up
 similar things in other areas (i.e. media URLs)?

 I'm more than willing to implement this, but it'd be my first
 contribution, so I don't want to be presumptuous about whether or not this
 is a valuable fix.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20237: Unable to test pure binary with assertContains

[Django]

#20237: Unable to test pure binary with assertContains
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:  regression   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Unfortunately, there is still an issue when the `assertContains` text
 parameter itself is made up of non-ascii binary content. I'll upload a
 complementary patch.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #11765: models.DateField(null=True, blank=True) accepts None, but not the empty string ''

[Django]

#11765: models.DateField(null=True, blank=True)  accepts None, but not the empty
string ''
-+-
 Reporter:  shmengie |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Brendan):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 I agree, I just fixed my problem by adding
 {{{#!python
 def clean(self):
 cleaned_data = super(MyForm, self).clean()
 if not cleaned_data['my_date']:
 cleaned_data['my_date'] = None
 return cleaned_data
 }}}

 to my form. Without this I received the error
 {{{#!python
 ValidationError: [u"'' value has an invalid date format. It must be in
 -MM-DD format."]
 }}}

 even though I had blank=True, null=True set in my model and required=False
 set in my form.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20186: Overriding registration/logged_out.html template doesn't work

[Django]

#20186: Overriding registration/logged_out.html template doesn't work
-+-
 Reporter:  honyczek |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.5
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  templates, auth, | Triage Stage:
  login, logout  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by honyczek):

 Hi,

 some years ago i started my project and followed Django tutorial. Once I
 wanted to customize my login and logout pages, so I read
 https://docs.djangoproject.com/en/1.5/intro/tutorial02/#customize-the-
 admin-look-and-feel and copied admin templates login.html and
 logged_out.html to /templates/registration/. It worked
 until Django 1.5. Now the logged_out.html doesn't work. Maybe template
 path changed...

 So now I've opened Admin docs and there is described another way to
 override login and logout templates. So if the tutorial way is incorrect,
 it should be updated.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19918: select_for_update runs on db_for_read rather than db_for_write

[Django]

#19918: select_for_update runs on db_for_read rather than db_for_write
-+-
 Reporter:   |Owner:  kux
  alexandruioan.cucu@…   |   Status:  assigned
 Type:  Bug  |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by claudep):

 * stage:  Ready for checkin => Accepted


Comment:

 Sorry, but the "Ready for checkin" flag should be set by another reviewer,
 not by the patch author.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20244: PermissionsMixin should define related name of groups and user_permissions related name

[Django]

#20244: PermissionsMixin should define related name of groups and 
user_permissions
related name
--+
 Reporter:  bdauvergne|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.auth  |Version:  1.5
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 Third party expecting a group.user_set or permission.user_set reverse
 relationships are broken by custom user model whose class name is not
 'User'.

 An easy work around would be to add a related_name='user_set' to the
 definitions of those two fields.

 {{{
 diff --git a/django/contrib/auth/models.py b/django/contrib/auth/models.py
 index 5709d25..e0a2dba 100644
 --- a/django/contrib/auth/models.py
 +++ b/django/contrib/auth/models.py
 @@ -294,10 +294,12 @@ class PermissionsMixin(models.Model):
  groups = models.ManyToManyField(Group, verbose_name=_('groups'),
  blank=True, help_text=_('The groups this user belongs to. A user
 will '
  'get all permissions granted to each of '
 -'his/her group.'))
 +'his/her group.'),
 +related_name='user_set')
  user_permissions = models.ManyToManyField(Permission,
  verbose_name=_('user permissions'), blank=True,
 -help_text='Specific permissions for this user.')
 +help_text='Specific permissions for this user.',
 +related_name='user_set')

  class Meta:
  abstract = 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #12990: New Field Type: JSONField

[Django]

#12990: New Field Type: JSONField
-+-
 Reporter:  paltman  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.2-alpha
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 How disappointing. In my case, I want to store user-specific settings
 provided by the UI guys which are used purely for layout, styles, etc... I
 don't want to have to maintain normalised tables for a constantly-updating
 data structure which is only ever stored/retrieved as a whole.

 I keep finding this in Django (and Python in general) - great ideas get
 vetoed because "we don't dare trust a developer to use tools properly".

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20243: Related object reference - remove() method

[Django]

#20243: Related object reference - remove() method
---+
 Reporter:  john@… |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 The documentation for RelatedManager.remove() states:

 In order to prevent database inconsistency, this method only exists on
 ForeignKey objects where null=True.

 This statement is misleading as it can be taken to mean that the method
 only exists for ForeignKey objects for which null is true.  I think the
 statement should read:

 For ForeignKey objects, this method only exists if null=True.

 The comment about database inconsistency is only stating the obvious.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #16306: Form field documentation documents optional keyword arguments as field attributes.

[Django]

#16306: Form field documentation documents optional keyword arguments as  field
attributes.
-+-
 Reporter:  ShawnMilo|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  form field   | Triage Stage:  Accepted
  documentation  |  Needs documentation:  1
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bmispelon):

 * cc: bmispelon@… (added)


Comment:

 I took a closer look at this ticket and investigated several approaches
 (including the proposed patch)

 I came up with 3 approaches on this ticket (the 3rd one being
 SmileyChris's one), but all of them have some issue:

 1) move the creation of validators from `__init__()` to `run_validators()`
 This approach is the less intrusive one.
 It works quite well but breaks some tests in the test suite, which
 shows there are some potential backwards-compatibility issues.
 The root of these issues is code which expects the field instance's
 `validators` attribute to be populated before the field has been actually
 validated [1].
 There's also two possibilities with this approach, the difference
 being whether we append the validators inside `run_validators` (in which
 case a `MinValueValidator` would be placed after any custom one for
 example), or whether we prepend them (this is more compatible with the
 existing behavior).

 2) Use lazy values
 This sort of works, but there are two problems:
 * The validators need to be changed because they can now be passed
 a None value to validate against.
 * The error messages are broken because `"%d" % lazy_int` does not
 work (and as far as I know, that's not something that can be made to
 work).

 3) descriptors (proposed patch)
 This approach is quite elegant on paper, and while the patch looks
 good, I think the proposed solution can't work because of some new
 features that were added since the patch was proposed.

 It's a bit tricky to explain why, but let me try.

 Let's consider what happens when creating an `IntegerField` with a
 `max_value` argument:
 * `IntegerField(max_value=42)` calls `IntegerField.__init__`
 * The `__init__` needs to do two things: set `self.min_value` to
 42, and call `Field.__init__`.
 * Setting `self.min_value = 42` calls `ValidatorAttribute.__set__`
 * `ValidatorAttribute.__set__` requires the field's `validators`
 attributes (a list of validators) to exist.
 * This attribute is set in `Field.__init__`
 * This means that `IntegerField.__init__` needs to call
 `Field.__init__` before setting `self.min_value`
 * However ...
 * `Field.__init__` calls `self.widget_attrs()`, which allows the
 field to pass custom attributes to the widget.
 * `IntegerField.widget_attrs` checks the value of `self.min_value`
 ...
 * ... which hasn't been set for the reasons stated above.

 It might be possible to add some more descriptors to make the whole
 thing work.
 For example, I tried making `Field.widget` into a property that would
 only call `widget_attrs` when being accessed.
 This however failed with a weird error message and it started getting
 hard to trace the problem with all the different layers of descriptors.
 All things considered, I'm not sure that adding all these additional
 layers is worth it.

 I think approach 1 is the best one, even at the cost of minor backwards-
 compatibility.
 `Field.validators` is not really documented and the documentation has no
 examples
 of directly manipulating it.

 Additionally, other fields have attributes which could use a similar fix:
 * CharField.max_length
 * charField.min_length
 * DecimalField.max_digits
 * DecimalField.decimal_places
 * RegexField.regex (current solution is based on @property)


 [1]
 
https://github.com/django/django/blob/master/tests/forms_tests/tests/forms.py#L822

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20242: Django queryset 'in' operator fails on first call

[Django]

#20242: Django queryset 'in' operator fails on first call
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.5
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When using the 'in' operator on a queryset, the first time the call is
 made it fails. If 'prefetch_related' is removed and 'all' is used instead
 then the problem is gone.

 {{{
 from django.db import models


 class Category(models.Model):
 name = models.CharField(max_length=100)


 class Project(models.Model):
 categories = models.ManyToManyField(Category, related_name='projects')


 category_list = Category.objects.prefetch_related('projects')


 print category_list # [, ]
 print category_list[0] in category_list # False
 print category_list[0] in category_list # 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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] ddfc68: Changed a deprecated warn() call in libgeos

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ddfc68379f47af18b90068f17e9a1f7e7cbfb505
  
https://github.com/django/django/commit/ddfc68379f47af18b90068f17e9a1f7e7cbfb505
  Author: Claude Paroz 
  Date:   2013-04-11 (Thu, 11 Apr 2013)

  Changed paths:
M django/contrib/gis/geos/libgeos.py

  Log Message:
  ---
  Changed a deprecated warn() call in libgeos



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20237: Unable to test pure binary with assertContains

[Django]

#20237: Unable to test pure binary with assertContains
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.5
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  regression   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"427b59495e7e2a1c58a46d278f6decec1d37938c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="427b59495e7e2a1c58a46d278f6decec1d37938c"
 [1.5.x] Fixed #20237 -- Reenabled assertContains with binary parameter

 Thanks Baptiste Mispelon for the review.
 Backport of fe01404bb9 from master.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 427b59: [1.5.x] Fixed #20237 -- Reenabled assertContains w...

[GitHub]

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 427b59495e7e2a1c58a46d278f6decec1d37938c
  
https://github.com/django/django/commit/427b59495e7e2a1c58a46d278f6decec1d37938c
  Author: Claude Paroz 
  Date:   2013-04-11 (Thu, 11 Apr 2013)

  Changed paths:
M django/test/testcases.py
M tests/regressiontests/test_client_regress/tests.py
M tests/regressiontests/test_client_regress/urls.py
M tests/regressiontests/test_client_regress/views.py

  Log Message:
  ---
  [1.5.x] Fixed #20237 -- Reenabled assertContains with binary parameter

Thanks Baptiste Mispelon for the review.
Backport of fe01404bb9 from master.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20237: Unable to test pure binary with assertContains

[Django]

#20237: Unable to test pure binary with assertContains
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.5
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  regression   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"fe01404bb9f276446fc42390242da25122f91663"]:
 {{{
 #!CommitTicketReference repository=""
 revision="fe01404bb9f276446fc42390242da25122f91663"
 Fixed #20237 -- Reenabled assertContains with binary parameter

 Thanks Baptiste Mispelon for the review.
 }}}

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] fe0140: Fixed #20237 -- Reenabled assertContains with bina...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fe01404bb9f276446fc42390242da25122f91663
  
https://github.com/django/django/commit/fe01404bb9f276446fc42390242da25122f91663
  Author: Claude Paroz 
  Date:   2013-04-11 (Thu, 11 Apr 2013)

  Changed paths:
M django/test/testcases.py
M tests/test_client_regress/tests.py
M tests/test_client_regress/urls.py
M tests/test_client_regress/views.py

  Log Message:
  ---
  Fixed #20237 -- Reenabled assertContains with binary parameter

Thanks Baptiste Mispelon for the review.



-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19918: select_for_update runs on db_for_read rather than db_for_write

[Django]

#19918: select_for_update runs on db_for_read rather than db_for_write
-+-
 Reporter:   |Owner:  kux
  alexandruioan.cucu@…   |   Status:  assigned
 Type:  Bug  |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kux):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17108: Link Trac's fields to their corresponding explanations in the Django doc

[Django]

#17108: Link Trac's fields to their corresponding explanations in the Django doc
-+
 Reporter:  julien   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  *.djangoproject.com  |  Version:  1.3
 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 claudep):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17108: Link Trac's fields to their corresponding explanations in the Django doc

[Django]

#17108: Link Trac's fields to their corresponding explanations in the Django doc
-+
 Reporter:  julien   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  *.djangoproject.com  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by aaugustin):

 Fixed in
 
[https://github.com/django/code.djangoproject.com/commit/cfb5b3b4c26c4d5b8d5455ef1e24e08201e514b7
 cfb5b3b4], thank you Julien.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.