date:20170111

Re: [Django] #27713: Clarify NoReverseMatch error message when view is not found

2017-01-11 Thread Django

#27713: Clarify NoReverseMatch error message when view is not found
-+-
 Reporter:  Marten Kenbeek   |Owner:  Marten
 Type:   |  Kenbeek
  Cleanup/optimization   |   Status:  closed
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
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:"1358a67bf95cde86b09b689b4f10f2eeb642de31" 1358a67]:
 {{{
 #!CommitTicketReference repository=""
 revision="1358a67bf95cde86b09b689b4f10f2eeb642de31"
 Fixed #27713 -- Clarified NoReverseMatch error message when no view is
 found.
 }}}

--
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/062.8fef2c6ecc75188153f15b95da38ac75%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27706: Session key is not set when trying to log in, when another user's session cookie is sent with the login request

2017-01-11 Thread Django

#27706: Session key is not set when trying to log in, when another user's
session
cookie is sent with the login request
---+--
Reporter: Utku Gültopu |Owner: nobody
Type: Uncategorized | Status: closed
Component: contrib.auth | Version: 1.10
Severity: Normal | Resolution: invalid
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 Tim Graham):

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

Comment:

As far as I see, this is the behavior as of
393c0e24223c701edeb8ce7dc9d0f852f0c081ad. If you feel it should be
changed, feel free to explain in more detail. I think you could adapt your
little snippet to account for it. Otherwise, please ask "is it intended
behavior" (usage) questions on
[wiki:TicketClosingReasons/UseSupportChannels our support channels].
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/066.8a8f9cb80358d446cf909ea3abccf05d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27726: Template default_if_none filter is inconsistent between printed value and boolean context

2017-01-11 Thread Django

#27726: Template default_if_none filter is inconsistent between printed value 
and
boolean context
-+--
 Reporter:  Tim Martin   |Owner:  Tim Martin
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.10
 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 Tim Graham):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #27722: if a template context is an instance of get_template(), it will raise "TypeError: context must be a dict rather than RequestContext"

2017-01-11 Thread Django

#27722: if a template context is an instance of get_template(), it will raise
"TypeError: context must be a dict rather than RequestContext"
-+--
 Reporter:  Sayid Munawar|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Tim Graham):

 The question in my mind is whether or not to keep the fix for #27258
 (maybe it's too restrictive -- in your use case, I'm not sure if
 `django.Template.render()` with `RequestContext` will give any surprising
 behaviors) or maybe some change could be made to `{% include %}` to either
 raise a more descriptive error message or to allow the use case to keep
 working.

--
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.546f2d32dd727a6e86dd8cb9ff3378d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27722: if a template context is an instance of get_template(), it will raise "TypeError: context must be a dict rather than RequestContext"

2017-01-11 Thread Django

#27722: if a template context is an instance of get_template(), it will raise
"TypeError: context must be a dict rather than RequestContext"
-+--
 Reporter:  Sayid Munawar|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Sayid Munawar):

 Hi Tim, sorry to continue to discuss about this, from your last comment:
   It's allowed to call {% include %} with a
 `django.template.base.Template` but not
 `django.template.backends.django.Template`
 but `get_template()` will return
 `django.template.backends.django.Template`.

 further investigation using ipdb, i found that `make_context` will raise
 type_error since the `context` is already an instance of `RequestContext`
 in the 2nd iteration (see below):

 {{{
 >
 /Users/ayik/Repo/Django/django/django/template/backends/django.py(65)render()
  63 def render(self, context=None, request=None):
  64 import ipdb; ipdb.set_trace()
 ---> 65 context = make_context(context, request,
 autoescape=self.backend.engine.autoescape)
  66 try:
  67 return self.template.render(context)

 ipdb> type(context)
 
 ipdb> c
 >
 /Users/ayik/Repo/Django/django/django/template/backends/django.py(65)render()
  63 def render(self, context=None, request=None):
  64 import ipdb; ipdb.set_trace()
 ---> 65 context = make_context(context, request,
 autoescape=self.backend.engine.autoescape)
  66 try:
  67 return self.template.render(context)

 ipdb> type(context)
 
 ipdb>
 }}}

--
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.e073d848fe365a2dec1825bcdc4cbb82%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27722: if a template context is an instance of get_template(), it will raise "TypeError: context must be a dict rather than RequestContext"

2017-01-11 Thread Django

#27722: if a template context is an instance of get_template(), it will raise
"TypeError: context must be a dict rather than RequestContext"
-+--
 Reporter:  Sayid Munawar|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Description changed by Sayid Munawar:

Old description:

> This simple view:
> {{{
> class Ngopi(TemplateView):
> template_name = 'base.html'
>
> def get_context_data(self, **kwargs):
> context = super(Ngopi, self).get_context_data(**kwargs)
> context.update({
> 'menu': get_template('menu.html')
> })
> return context
> }}}
>
> with `base.html`:
> {{{
> 
> 
> Ngeteh
> {% include menu %}
> 
> 
> }}}
>
> and `menu.html`:
> {{{
> 
> Ngeteh
> Ngopi
> 
> }}}
>
> This situation will raise this exception:
> {{{
> Traceback (most recent call last):
>   File
> "/Users/ayik/Repo/Django/django/django/core/handlers/exception.py", line
> 38, in inner
> response = get_response(request)
>   File "/Users/ayik/Repo/Django/django/django/core/handlers/base.py",
> line 217, in _get_response
> response = self.process_exception_by_middleware(e, request)
>   File "/Users/ayik/Repo/Django/django/django/core/handlers/base.py",
> line 215, in _get_response
> response = response.render()
>   File "/Users/ayik/Repo/Django/django/django/template/response.py", line
> 107, in render
> self.content = self.rendered_content
>   File "/Users/ayik/Repo/Django/django/django/template/response.py", line
> 84, in rendered_content
> content = template.render(context, self._request)
>   File
> "/Users/ayik/Repo/Django/django/django/template/backends/django.py", line
> 66, in render
> return self.template.render(context)
>   File "/Users/ayik/Repo/Django/django/django/template/base.py", line
> 207, in render
> return self._render(context)
>   File "/Users/ayik/Repo/Django/django/django/template/base.py", line
> 199, in _render
> return self.nodelist.render(context)
>   File "/Users/ayik/Repo/Django/django/django/template/base.py", line
> 990, in render
> bit = node.render_annotated(context)
>   File "/Users/ayik/Repo/Django/django/django/template/base.py", line
> 957, in render_annotated
> return self.render(context)
>   File "/Users/ayik/Repo/Django/django/django/template/loader_tags.py",
> line 212, in render
> return template.render(context)
>   File
> "/Users/ayik/Repo/Django/django/django/template/backends/django.py", line
> 64, in render
> context = make_context(context, request,
> autoescape=self.backend.engine.autoescape)
>   File "/Users/ayik/Repo/Django/django/django/template/context.py", line
> 285, in make_context
> raise TypeError('context must be a dict rather than %s.' %
> context.__class__.__name__)
> TypeError: context must be a dict rather than RequestContext.
> }}}
>
> This is fine with django 1.10, but not master (mine is currently
> 1.11.dev20170109230310)
>
> a quick workaround is to edit
> [https://github.com/django/django/blob/ecb59cc6579402b68ddfd4499bf30edacf5963be/django/template/backends/django.py#L63
> django/template/backends/django.py Line 63] to be like this:
> {{{
> def render(self, context=None, request=None):
> if isinstance(context, dict):  # <-- my temporary workaround
> context = make_context(context, request,
> autoescape=self.backend.engine.autoescape)
> try:
> return self.template.render(context)
> except TemplateDoesNotExist as exc:
> reraise(exc, self.backend)
> }}}

New description:

 This simple view:
 {{{
 from django.views.generic import TemplateView
 from django.template.loader import get_template

 class Ngopi(TemplateView):
 template_name = 'base.html'

 def get_context_data(self, **kwargs):
 context = super(Ngopi, self).get_context_data(**kwargs)
 context.update({
 'menu': get_template('menu.html')
 })
 return context
 }}}

 with `base.html`:
 {{{
 
 
 Ngeteh
 {% include menu %}
 
 
 }}}

 and `menu.html`:
 {{{
 
 Ngeteh
 Ngopi
 
 }}}

 This situation will raise this exception:
 {{{
 Traceback (most recent call last):
   File "/Users/ayik/Repo/Django/django/django/core/handlers/exception.py",
 line 38, in inner
 response = get_respon

Re: [Django] #27721: Unhelpful error message when trying to run shell that can't be imported

2017-01-11 Thread Django

#27721: Unhelpful error message when trying to run shell that can't be imported
-+-
 Reporter:  Peter Inglesby   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  1 => 0
 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.358ae3809480da412c36592f8501847a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27726: Template default_if_none filter is inconsistent between printed value and boolean context

2017-01-11 Thread Django

#27726: Template default_if_none filter is inconsistent between printed value 
and
boolean context
-+--
 Reporter:  Tim Martin   |Owner:  Tim Martin
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.10
 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 Tim Martin):

 My original thought was to fix this in preparation for fixing #24977
 (since I'll need to regularise this behaviour anyway, and it would make it
 clearer to fix the bugs independently). However,  I don't think it's
 possible to do this without a hacky workaround. I'll close this when I've
 fixed #24977.

--
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.bb5cc57f10f3c061bf2f4b32487de618%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24977: Template variables with a value of None are considered to be == to non-existent properties

2017-01-11 Thread Django

#24977: Template variables with a value of None are considered to be == to non-
existent properties
-+-
 Reporter:  Daniel Quinn |Owner:  Tim
 Type:   |  Martin
  Cleanup/optimization   |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  string, if,  | Triage Stage:  Accepted
  equivalence|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Martin):

 * status:  new => assigned
 * owner:  nobody => Tim Martin


--
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/069.482b16fe3c6f3c324cd9841fbb17c08b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
---+--
 Reporter:  paulfab|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  request fails  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 You can try the channels linked at TicketClosingReasons/UseSupportChannels
 for ways to get help.

--
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.51504096ab4750913ef3a85f1984b4bf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
---+--
 Reporter:  paulfab|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  request fails  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by paulfab):

 The fact is that my application is very simple there is no monkey patch. I
 just wanted to know in what sense django shell is different than python
 shell,  ipython or bpython could be the reason, but it is not available on
 my system.

 Maybe Django has nothing to do with that, but that is his way to handle
 https that broke my request.


 Thanks anyway

--
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.3ceeb564451a55c8913c6cbc853b6763%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26355: Add support for PostgreSQL's array_append to ArrayField

2017-01-11 Thread Django

#26355: Add support for PostgreSQL's array_append to ArrayField
--+
 Reporter:  Paul Grau |Owner:  khorne
 Type:  New feature   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.9
 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 Tim Graham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #27726: Template default_if_none filter is inconsistent between printed value and boolean context

2017-01-11 Thread Django

#27726: Template default_if_none filter is inconsistent between printed value 
and
boolean context
-+--
 Reporter:  Tim Martin   |Owner:  Tim Martin
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.10
 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 Tim Martin):

 * owner:  nobody => Tim Martin
 * 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/067.f23e9d8ec3b3e11a7555bce5bef8e79c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27726: Template default_if_none filter is inconsistent between printed value and boolean context

2017-01-11 Thread Django

#27726: Template default_if_none filter is inconsistent between printed value 
and
boolean context
---+
   Reporter:  Tim Martin   |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Template system  |Version:  1.10
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 I have the template


 {{{
 x={{x}}
 y={{y}}
 x|default_if_none:y={{x|default_if_none:y}}
 {% if x|default_if_none:y %}
 x|default_if_none:y is apparently True
 {% endif %}
 }}}

 If `x` is unset (a missing variable in the template context) and `y` is
 set to `True`, then this prints:

 {{{
 x=
 y=True
 x|default_if_none:y =
 x|default_if_none:y is apparently True
 }}}

 This indicates that `x:default_if_none:y` evaluates to `True` in the
 boolean context, but doesn't print a value when evaluated directly.

--
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.77fe6d580dcc8b5220e9e9699978%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27713: Clarify NoReverseMatch error message when view is not found

2017-01-11 Thread Django

#27713: Clarify NoReverseMatch error message when view is not found
-+-
 Reporter:  Marten Kenbeek   |Owner:  Marten
 Type:   |  Kenbeek
  Cleanup/optimization   |   Status:  assigned
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.8ffcf9516b29269bf92a0b4f78f8cd4b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
---+--
 Reporter:  paulfab|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  request fails  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Simon Charette):

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


Comment:

 `manage.py shell` uses iPython or bpython if available in your
 environment. Is it the case here?

 Else it could be caused by some code your application monkey patches but
 as Tim pointed out nothing seems to indicate Django is at fault here.

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

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

Re: [Django] #27639: Add a chunk size argument to QuerySet.iterator()

2017-01-11 Thread Django

#27639: Add a chunk size argument to QuerySet.iterator()
-+-
 Reporter:  François Freitag |Owner:  François
 |  Freitag
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  cursors database | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by François Freitag):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/7836/ PR #7836]

--
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/073.237b2e69939d21da5d89755fda289276%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27722: if a template context is an instance of get_template(), it will raise "TypeError: context must be a dict rather than RequestContext"

2017-01-11 Thread Django

#27722: if a template context is an instance of get_template(), it will raise
"TypeError: context must be a dict rather than RequestContext"
-+--
Reporter: Sayid Munawar|Owner: nobody
Type: Bug | Status: closed
Component: Template system | Version: master
Severity: Normal | Resolution: wontfix
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 Tim Graham):

* cc: FunkyBob (added)

Comment:

Curtis, as the author of 5cdacbda034af928f5033c9afc7b50ee0b13f75c, I
wonder if you have any input here? I'm not happy that I broke backwards
compatibility (due to #27258) with such a cryptic error message here. At
least the `{% include %}` docs that say, "The variable may also be any
object with a `render()` method that accepts a context." might need some
clarification.

The use case is described in the [https://github.com/viewflow/django-
material/issues/222 django-material issue].

--
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.0cfe97892d3c2d05b55dfd65cf3c63d4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
---+--
 Reporter:  paulfab|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  request fails  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 Please tell us where the problem is rather than asking us to debug the
 issue. Looking at the traceback doesn't indicate why Django is at fault.

--
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.df50e44fd0bcbffa7f54153d04036717%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
---+--
 Reporter:  paulfab|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  request fails  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by paulfab):

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


--
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.dc330fc6772a8aafe03eea0a78d9a288%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
---+--
 Reporter:  paulfab|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  request fails  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by paulfab):

 Well
 I execute the same line :
 requests.post("https://slack.com/api/chat.postMessage";, data= {"channel":
 "maison"})
 In both the django shell 'python manage.py shell' and the python shell
 'python', and it only fails in the first one,
 so this is django shell 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/065.4315822298565f3c5e9412d05ec8f9ee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
---+--
 Reporter:  paulfab|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  request fails  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

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


Comment:

 You'll need to tell us where the issue is. I don't see anything obvious
 indicating that Django is at fault.

--
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.b9ab9ff2981de859d447a112c6647f78%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
---+--
 Reporter:  paulfab|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  request fails  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by paulfab:

Old description:

> When I execute :
> requests.post("https://slack.com/api/chat.postMessage";, data=
> {"channel": "maison"})
> it fails in the django shell (python manage.py shell) with the error :
>
> {{{
> InvalidCodepoint: Codepoint U+002A at position 1 of u'*' not allowed
> }}}
>

> but it doesnt fail in the python shell
> So this tells me it is probable something Django related
>
> Thanks
>

> complete trace of the error is :
>
> {{{
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 107, in
> post
> return request('post', url, data=data, json=json, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 53, in
> request
> return session.request(method=method, url=url, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 468,
> in request
> resp = self.send(prep, **send_kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 576,
> in send
> r = adapter.send(request, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 376,
> in send
> timeout=timeout
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/connectionpool.py", line 594, in urlopen
> chunked=chunked)
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/connectionpool.py", line 350, in _make_request
> self._validate_conn(conn)
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/connectionpool.py", line 833, in _validate_conn
> conn.connect()
>   File "/usr/local/lib/python2.7/dist-packages/urllib3/connection.py",
> line 324, in connect
> cert = self.sock.getpeercert()
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/contrib/pyopenssl.py", line 312, in getpeercert
> 'subjectAltName': get_subj_alt_name(x509)
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/contrib/pyopenssl.py", line 185, in get_subj_alt_name
> for name in ext.get_values_for_type(x509.DNSName)
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/contrib/pyopenssl.py", line 141, in _dnsname_to_stdlib
> name = idna.encode(name)
>   File "/usr/lib/python2.7/dist-packages/idna/core.py", line 354, in
> encode
> result.append(alabel(label))
>   File "/usr/lib/python2.7/dist-packages/idna/core.py", line 275, in
> alabel
> check_label(label)
>   File "/usr/lib/python2.7/dist-packages/idna/core.py", line 252, in
> check_label
> raise InvalidCodepoint('Codepoint {0} at position {1} of {2} not
> allowed'.format(_unot(cp_value), pos+1, repr(label)))
> InvalidCodepoint: Codepoint U+002A at position 1 of u'*' not allowed
> }}}

New description:

 When I execute :
 requests.post("https://slack.com/api/chat.postMessage";, data=  {"channel":
 "maison"})
 it fails in the django shell (python manage.py shell) with the error :

 {{{
 InvalidCodepoint: Codepoint U+002A at position 1 of u'*' not allowed
 }}}


 but it doesnt fail in the python shell
 So this tells me it is probable something Django related
 It was working before, and the only thing I changed is that I updated the
 SSL certificate of my server

 Thanks


 complete trace of the error is :

 {{{
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 107, in
 post
 return request('post', url, data=data, json=json, **kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 53, in
 request
 return session.request(method=method, url=url, **kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 468,
 in request
 resp = self.send(prep, **send_kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 576,
 in send
 r = adapter.send(request, **kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 376,
 in send
 timeout=timeout
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py",
 line 594, in urlopen
 chunked=chunked)
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py",
 line 350, in _make_request
 self._validate_conn(conn)
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connectionpoo

Re: [Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
---+--
 Reporter:  paulfab|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  request fails  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by paulfab:

Old description:

> When I execute :
> requests.post("https://slack.com/api/chat.postMessage";, data=
> {"channel": "maison"})
> it fails in the django shell (python manage.py shell) with the error :
> InvalidCodepoint: Codepoint U+002A at position 1 of u'*' not allowed
>
> but it doesnt fail in the python shell
> So this tells me it is probable something Django related
>
> Thanks
>

> complete trace of the error is :
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 107, in
> post
> return request('post', url, data=data, json=json, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 53, in
> request
> return session.request(method=method, url=url, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 468,
> in request
> resp = self.send(prep, **send_kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 576,
> in send
> r = adapter.send(request, **kwargs)
>   File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 376,
> in send
> timeout=timeout
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/connectionpool.py", line 594, in urlopen
> chunked=chunked)
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/connectionpool.py", line 350, in _make_request
> self._validate_conn(conn)
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/connectionpool.py", line 833, in _validate_conn
> conn.connect()
>   File "/usr/local/lib/python2.7/dist-packages/urllib3/connection.py",
> line 324, in connect
> cert = self.sock.getpeercert()
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/contrib/pyopenssl.py", line 312, in getpeercert
> 'subjectAltName': get_subj_alt_name(x509)
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/contrib/pyopenssl.py", line 185, in get_subj_alt_name
> for name in ext.get_values_for_type(x509.DNSName)
>   File "/usr/local/lib/python2.7/dist-
> packages/urllib3/contrib/pyopenssl.py", line 141, in _dnsname_to_stdlib
> name = idna.encode(name)
>   File "/usr/lib/python2.7/dist-packages/idna/core.py", line 354, in
> encode
> result.append(alabel(label))
>   File "/usr/lib/python2.7/dist-packages/idna/core.py", line 275, in
> alabel
> check_label(label)
>   File "/usr/lib/python2.7/dist-packages/idna/core.py", line 252, in
> check_label
> raise InvalidCodepoint('Codepoint {0} at position {1} of {2} not
> allowed'.format(_unot(cp_value), pos+1, repr(label)))
> InvalidCodepoint: Codepoint U+002A at position 1 of u'*' not allowed

New description:

 When I execute :
 requests.post("https://slack.com/api/chat.postMessage";, data=  {"channel":
 "maison"})
 it fails in the django shell (python manage.py shell) with the error :

 {{{
 InvalidCodepoint: Codepoint U+002A at position 1 of u'*' not allowed
 }}}


 but it doesnt fail in the python shell
 So this tells me it is probable something Django related

 Thanks


 complete trace of the error is :

 {{{
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 107, in
 post
 return request('post', url, data=data, json=json, **kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 53, in
 request
 return session.request(method=method, url=url, **kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 468,
 in request
 resp = self.send(prep, **send_kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 576,
 in send
 r = adapter.send(request, **kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 376,
 in send
 timeout=timeout
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py",
 line 594, in urlopen
 chunked=chunked)
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py",
 line 350, in _make_request
 self._validate_conn(conn)
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py",
 line 833, in _validate_conn
 conn.connect()
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connection.py",
 line

[Django] #27725: requests.post fail inside of django shell but not python shell

2017-01-11 Thread Django

#27725: requests.post fail inside of django shell but not python shell
-+---
   Reporter:  paulfab|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  1.10
   Severity:  Normal |   Keywords:  request fails
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
 When I execute :
 requests.post("https://slack.com/api/chat.postMessage";, data=  {"channel":
 "maison"})
 it fails in the django shell (python manage.py shell) with the error :
 InvalidCodepoint: Codepoint U+002A at position 1 of u'*' not allowed

 but it doesnt fail in the python shell
 So this tells me it is probable something Django related

 Thanks


 complete trace of the error is :
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 107, in
 post
 return request('post', url, data=data, json=json, **kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 53, in
 request
 return session.request(method=method, url=url, **kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 468,
 in request
 resp = self.send(prep, **send_kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 576,
 in send
 r = adapter.send(request, **kwargs)
   File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 376,
 in send
 timeout=timeout
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py",
 line 594, in urlopen
 chunked=chunked)
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py",
 line 350, in _make_request
 self._validate_conn(conn)
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py",
 line 833, in _validate_conn
 conn.connect()
   File "/usr/local/lib/python2.7/dist-packages/urllib3/connection.py",
 line 324, in connect
 cert = self.sock.getpeercert()
   File "/usr/local/lib/python2.7/dist-
 packages/urllib3/contrib/pyopenssl.py", line 312, in getpeercert
 'subjectAltName': get_subj_alt_name(x509)
   File "/usr/local/lib/python2.7/dist-
 packages/urllib3/contrib/pyopenssl.py", line 185, in get_subj_alt_name
 for name in ext.get_values_for_type(x509.DNSName)
   File "/usr/local/lib/python2.7/dist-
 packages/urllib3/contrib/pyopenssl.py", line 141, in _dnsname_to_stdlib
 name = idna.encode(name)
   File "/usr/lib/python2.7/dist-packages/idna/core.py", line 354, in
 encode
 result.append(alabel(label))
   File "/usr/lib/python2.7/dist-packages/idna/core.py", line 275, in
 alabel
 check_label(label)
   File "/usr/lib/python2.7/dist-packages/idna/core.py", line 252, in
 check_label
 raise InvalidCodepoint('Codepoint {0} at position {1} of {2} not
 allowed'.format(_unot(cp_value), pos+1, repr(label)))
 InvalidCodepoint: Codepoint U+002A at position 1 of u'*' not allowed

--
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/050.5c0fae9e9a0532267df57d9fd87eaade%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27719: Add queryset.alias() to mimic .annotate() for aggregations without loading data

2017-01-11 Thread Django

#27719: Add queryset.alias() to mimic .annotate() for aggregations without 
loading
data
-+-
 Reporter:  Marc Tamlyn  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Simon Charette):

 * stage:  Unreviewed => Accepted


Comment:

 That makes sense, thanks for the clarification.

--
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.f0076a9ab79d02646a35089e9e2b0b13%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27722: if a template context is an instance of get_template(), it will raise "TypeError: context must be a dict rather than RequestContext"

2017-01-11 Thread Django

#27722: if a template context is an instance of get_template(), it will raise
"TypeError: context must be a dict rather than RequestContext"
-+--
 Reporter:  Sayid Munawar|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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 Tim Graham):

 * resolution:  fixed => wontfix


--
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.bd35b623610b07ba6e8b34935d0eddc5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27722: if a template context is an instance of get_template(), it will raise "TypeError: context must be a dict rather than RequestContext"

2017-01-11 Thread Django

#27722: if a template context is an instance of get_template(), it will raise
"TypeError: context must be a dict rather than RequestContext"
-+--
 Reporter:  Sayid Munawar|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Sayid Munawar):

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


Comment:

 sorry Tim, my proposed change didn't mean to really fix the problem, just
 a workaround so that i can continue to code.

 using `context.update({'menu': 'menu.html'})` solved my problem. it just
 weird since it was working fine until 1.10

--
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.b1a2906ef92183de26fcb1dc248fda95%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27723: `type` is not propagated correctly to widgets in MultiWidgets

2017-01-11 Thread Django

#27723: `type` is not propagated correctly to widgets in MultiWidgets
-+
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   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 Tim Graham):

 * needs_better_patch:  0 => 1
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 In earlier versions of Django, passing `attrs` doesn't override the `type`
 in subwidgets. Solving #5851 to allow different `attrs` for different
 subwidgets might be a better solution.

--
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.98c27524d74cd169eaa18286736b037c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27719: Add queryset.alias() to mimic .annotate() for aggregations without loading data

2017-01-11 Thread Django

#27719: Add queryset.alias() to mimic .annotate() for aggregations without 
loading
data
-+-
 Reporter:  Marc Tamlyn  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Marc Tamlyn):

 Whilst support in all the places which can use an annotated name would
 solve this kind of performance problem, there are loads of ways you can
 use a field name after it's defined.

 `.filter(name__lookup=value)`
 `.order_by('name')`
 `.annotate(SomeOtherExpression('name'))`
 `.values('name')` (and related APIs)`
 `.distinct()`
 `.date()` (and `datetimes`)
 `.defer('name')` (and `only`)

 I know that some of these places already support expressions. For very
 complex expressions there's utility in being able to "name" the expression
 as some kind of virtual field. If you're within the same function then a
 python reference is usually sufficient (except for the `__lookup` case),
 but if you have for example a manager method which would annotate a
 certain field and you use it elsewhere then things get messy quickly.

--
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.1975361492470a897ad34ccb5527b95f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16614: Support server-side cursors for queryset iteration in database backends

2017-01-11 Thread Django

#16614: Support server-side cursors for queryset iteration in database backends
-+-
 Reporter:  Dan McGee|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  memory cursors   | Triage Stage:  Accepted
  database   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  1 => 0
 * stage:  Ready for checkin => Accepted


Comment:

 The ticket remains open for consideration of using server-side cursors on
 MySQL.

--
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.5525234d1538fe16f6d132664be5ea2f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16614: Support server-side cursors for queryset iteration in database backends

2017-01-11 Thread Django

#16614: Support server-side cursors for queryset iteration in database backends
-+-
 Reporter:  Dan McGee|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  memory cursors   | Triage Stage:  Ready for
  database   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"f3b7c059367a4e82bbfc7e4f0d42b10975e79f0c" f3b7c05]:
 {{{
 #!CommitTicketReference repository=""
 revision="f3b7c059367a4e82bbfc7e4f0d42b10975e79f0c"
 Refs #16614 -- Made QuerySet.iterator() use server-side cursors on
 PostgreSQL.

 Thanks to Josh Smeaton for the idea of implementing server-side cursors
 in PostgreSQL from the iterator method, and Anssi Kääriäinen and Kevin
 Turner for their previous work. Also Simon Charette and Tim Graham for
 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.64e4cb7dc20af679f02753cb026d600b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27719: Add queryset.alias() to mimic .annotate() for aggregations without loading data

2017-01-11 Thread Django

#27719: Add queryset.alias() to mimic .annotate() for aggregations without 
loading
data
-+-
 Reporter:  Marc Tamlyn  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Simon Charette):

 Could this be solved by allowing expressions to be passed to `filter()`
 instead? #25367.

--
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.c081fb46c62ec131a186195efb9f72ed%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash when referenced media changes

2017-01-11 Thread Django

#24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash
when referenced media changes
-+-
 Reporter:  Paul McLanahan   |Owner:  Paul
 |  McLanahan
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
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:"53bffe8d03f01bd3214a5404998cb965fb28cd0b" 53bffe8]:
 {{{
 #!CommitTicketReference repository=""
 revision="53bffe8d03f01bd3214a5404998cb965fb28cd0b"
 Fixed #24452 -- Fixed HashedFilesMixin correctness with nested paths.
 }}}

--
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.23691b9729a015b3e60c996f9477e893%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16575: Allow specifying custom "empty" values for SelectDateWidget (was: SelectDateWidget should have possibility to have more custom configurations)

2017-01-11 Thread Django

#16575: Allow specifying custom "empty" values for SelectDateWidget
--+-
 Reporter:  foobarrior|Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Forms |  Version:
 Severity:  Normal|   Resolution:  duplicate
 Keywords:  SelectDateWidget  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by Tim Graham):

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


Comment:

 Duplicate of #22684. Use `SelectDateWidget.empty_label` in Django 1.8+.

--
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.b15445b0e2262b1d133aa3abb448f380%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27724: SelectDateWidget clears date and month if year is not selected

2017-01-11 Thread Django

#27724: SelectDateWidget clears date and month if year is not selected
---+
 Reporter:  tpazderka  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.10
 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 Tim Graham):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #27721: Unhelpful error message when trying to run shell that can't be imported

2017-01-11 Thread Django

#27721: Unhelpful error message when trying to run shell that can't be imported
-+-
 Reporter:  Peter Inglesby   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  1.10
  commands)  |
 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 Tim Graham):

 * needs_better_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Core (Management commands)
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #27683: Change default transaction isolation level to READ COMMITTED on MySQL

2017-01-11 Thread Django

#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 Type:   |  Berger
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Tim Graham):

 Thanks. Here's the [https://groups.google.com/d/topic/django-
 developers/JiXalqmohUc/discussion django-developers thread].

--
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.2ac6af5386d88c4f97bc47e9889c05da%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27724: SelectDateWidget clears date and month if year is not selected

2017-01-11 Thread Django

#27724: SelectDateWidget clears date and month if year is not selected
---+--
 Reporter:  tpazderka  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.10
 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 tpazderka):

 Another option would be to modify `SelectDateWidget.date_re` to math the
 output from `value_from_datadict`

 {{{
 date_re = re.compile(r'(\d+)-(\d\d?)-(\d\d?)$')
 }}}

--
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.be86e35493762b583b3bb3bb70b70868%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27683: Change default transaction isolation level to READ COMMITTED on MySQL

2017-01-11 Thread Django

#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 Type:   |  Berger
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Shai Berger):

 The system check was suggested by Adam in comment:1, and I thought the
 analogy with strict-mode holds. I felt odd about there being both the
 check and the deprecation warning (and commented about it in the original
 PR) but yes, I felt that the fact they were both mostly silent (the check
 is only vocal in `migrate` by default) sort-of justifies keeping both.

--
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.a4e13d619943150473ebb4012354798d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27683: Change default transaction isolation level to READ COMMITTED on MySQL

2017-01-11 Thread Django

#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 Type:   |  Berger
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Tim Graham):

 Was your thinking that the system check is needed because the deprecation
 warning is silent by default or did you have another idea in mind?

--
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.148f0676fd1b0a6a2ce8a4def362930c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27722: if a template context is an instance of get_template(), it will raise "TypeError: context must be a dict rather than RequestContext"

2017-01-11 Thread Django

#27722: if a template context is an instance of get_template(), it will raise
"TypeError: context must be a dict rather than RequestContext"
-+--
 Reporter:  Sayid Munawar|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  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 Tim Graham):

 Does `get_template()` create some behavior difference as opposed to
 `context.update({'menu': 'menu.html'})`?

--
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.35e362b82d5fd1a4664c2cd6e2ee8f09%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27723: `type` is not propagated correctly to widgets in MultiWidgets

2017-01-11 Thread Django

#27723: `type` is not propagated correctly to widgets in MultiWidgets
-+--
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/7835 PR]

--
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.647978a39fc4bf5e1e2c8ddbd4fd02da%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27724: SelectDateWidget clears date and month if year is not selected

2017-01-11 Thread Django

#27724: SelectDateWidget clears date and month if year is not selected
--+
   Reporter:  tpazderka   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  1.10
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 If year is not selected in `SelectDateWidget`, then all the inputs are
 cleared as opposed to a state where date or month is missing.

 The issue is that `SelectDateWidget.value_from_datadict` does not return a
 value that would be matched by `SelectDateWidget.date_re`.

 The returns from `SelectDateWidget.value_from_datadict`  should probably
 be formatted as follows

 {{{
 #!python
 return '{:04d}-{:d}-{:d}'.format(y, m, d)
 }}}

--
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.b472a8eb3b1742ef1ff221656115f7ca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27683: Change default transaction isolation level to READ COMMITTED on MySQL

2017-01-11 Thread Django

#27683: Change default transaction isolation level to READ COMMITTED on MySQL
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 Type:   |  Berger
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Shai Berger):

 Replying to [comment:13 Tim Graham]:
 > With the current patch, would the system check ever trigger in Django
 2.1 when the default transaction level changes?

 No, it never would -- there will be no case where the user hasn't
 specified a preference and the isolation level would still be REPEATABLE
 READ.

--
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.1ece1cc6035afcb06b91681af61e76a8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27392: Remove "Tests that", "Ensures that", etc. from test docstings

2017-01-11 Thread Django

#27392: Remove "Tests that", "Ensures that", etc. from test docstings
--+
 Reporter:  Tim Graham|Owner:  (none)
 Type:  Cleanup/optimization  |   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 ablyx):

 * status:  assigned => new
 * owner:  ablyx => (none)


--
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.5bad92c87fb11a321d70adb6f2d421df%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27723: `type` is not propagated correctly to widgets in MultiWidgets

2017-01-11 Thread Django

#27723: `type` is not propagated correctly to widgets in MultiWidgets
-+--
 Reporter:  felixxm  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
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:  0|UI/UX:  0
-+--

Comment (by felixxm):

 It's a regression in #15667 that only affects 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6e376416810e202896b7888c70028b30%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

47 matches

Mail list logo