date:20180509

Re: [Django] #26600: map says a queryset is not iterable

2018-05-09 Thread Django

#26600: map says a queryset is not iterable
-+-
 Reporter:  ihucos   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  queryset iterator| Triage Stage:
  map|  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:   => wontfix


Comment:

 I think we can close as ''wontfix'' given `map` doesn't turn `__iter__()`
 exceptions into `TypeError` on Py3k and we don't support Py2k anymore.

 Thanks for the investigation Vitaliy.

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

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

Re: [Django] #29386: Meta Inheritance for default_permissions

2018-05-09 Thread Django

Comment (by Clayton Daley):

Thanks. I finally see the chain of references that would have brought me
to that conclusion. It sounds like Meta Inheritance is supported under
few, very specific conditions... something like:

- A is the parent of B
- A.Meta is the parent of B.Meta
- A.Meta is abstract

If a concise set of conditions could be described, would you be open to a
PR that threw `ImproperlyConfigured` under other conditions? This seems
like an ideal case for an exception because Meta Inheritance is a best
practice in some cases (i.e. abstract inheritance) and deliberately
ineffective in others (Multi-Table, Proxy). A reasonably informative
error message would eliminate the need to even go to the documentation.

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

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

Re: [Django] #29363: Use unittest assertWarns methods instead of warnings.catch_warnings/simplefilter/assertions in the test suite.

2018-05-09 Thread Django

#29363: Use unittest assertWarns methods instead of
warnings.catch_warnings/simplefilter/assertions in the test suite.
-+-
 Reporter:  Simon Charette   |Owner:  Morgan
 Type:   |  Aubert
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"704443acacf0dfbcb1c52df4b260585055754ce7" 704443ac]:
 {{{
 #!CommitTicketReference repository=""
 revision="704443acacf0dfbcb1c52df4b260585055754ce7"
 Fixed #29363 -- Added SimpleTestCase.assertWarnsMessage().
 }}}

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

Re: [Django] #26600: map says a queryset is not iterable

2018-05-09 Thread Django

#26600: map says a queryset is not iterable
-+-
 Reporter:  ihucos   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset iterator| Triage Stage:
  map|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 I'm going to reopen so we review the reproduce.

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

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

Re: [Django] #26600: map says a queryset is not iterable

2018-05-09 Thread Django

#26600: map says a queryset is not iterable
-+-
 Reporter:  ihucos   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  queryset iterator| Triage Stage:
  map|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Vitaliy):

 * version:  1.8 => 1.11


Comment:

 I found a way to reproduce the error.

 Class **A** is a simplified version of **QuerySet**
 {{{#!python
 class A(object):

 def __init__(self):
 self._result_cache = None

 def _fetch_all(self):
 if self._result_cache is None:
 self._result_cache = list(self.iterator())

 def iterator(self):
 for x in range(10):
 if x == 5:
 raise MemoryError  # the type of exception doesn't matter
 yield x

 def __iter__(self):
 self._fetch_all()
 return iter(self._result_cache)
 }}}

 {{{#!python
 In [2]: map(str, A())
 ---
 TypeError Traceback (most recent call
 last)
 /home/user/workspace/project/service/models.pyc in ()
 > 1 map(str, A())

 TypeError: argument 2 to map() must support iteration
 }}}

 When using python 3:
 {{{#!python
 In [6]: map(str, A())
 ---
 MemoryError   Traceback (most recent call
 last)
  in ()
 > 1 map(str, A())

  in __iter__(self)
  15
  16 def __iter__(self):
 ---> 17 self._fetch_all()
  18 return iter(self._result_cache)
  19

  in _fetch_all(self)
   6 def _fetch_all(self):
   7 if self._result_cache is None:
 > 8 self._result_cache = list(self.iterator())
   9
  10 def iterator(self):

  in iterator(self)
  11 for x in range(10):
  12 if x == 5:
 ---> 13 raise MemoryError
  14 yield x
  15

 MemoryError:
 }}}

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

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

Re: [Django] #29386: Meta Inheritance for default_permissions

2018-05-09 Thread Django

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

Comment:

That section if for abstract inheritance, one of the three types (the
others being multi-table and proxy). It's saying that when you inherit
from an abstract model Meta is inherited (and can be overridden.)

Your case is Proxy inheritance, which links to the multi-table rules for
inheritance (which I cited above). It's important not to conflate the
different types of inheritance.

I appreciate it's complex and not always as expected every time,
especially when the examples become more developed, as are yours.

This still seems to be expected behaviour. I'm going to close this as
such. If you have a concrete suggestion for the docs—there's always the
possibility of improvement—we'd be very happy to review a PR referencing
this 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/070.4123c6294106785c75a883ac746d1535%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29386: Meta Inheritance for default_permissions

2018-05-09 Thread Django

Comment (by Clayton Daley):

I only cited that section to point out that it describes a different
case... implicit inheritance of a parent's Meta Class. In that case, the
documentation is fine and I believe the behavior is expected.

I followed the Meta Inheritance section which states "If the child wants
to extend the parent’s Meta class, it can subclass it". I wanted to
extend it. I subclassed it. In this section, it states that only one
change is made... `abstract` is set to `False`. It does not state that
`default_permissions` are ignored. But they seem to be.

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

Re: [Django] #29386: Meta Inheritance for default_permissions

2018-05-09 Thread Django

#29386: Meta Inheritance for default_permissions
-+-
 Reporter:  Clayton Daley|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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 Carlton Gibson):

 Replying to [comment:4 Clayton Daley]:
 > The section you cited says "child class to inherit from its parent’s
 Meta class" ...

 Those words go " it doesn’t make sense for a child class to inherit from
 its parent’s Meta class". Don't you think the "it doesn't make sense" is
 clear enough?

 It follows "All the Meta options have already been applied to the parent
 class and applying them again would normally only lead to contradictory
 behavior".

 What else do you want it to say?

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

Re: [Django] #29386: Meta Inheritance for default_permissions

2018-05-09 Thread Django

#29386: Meta Inheritance for default_permissions
-+-
 Reporter:  Clayton Daley|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (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
-+-
Changes (by Clayton Daley):

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


Comment:

 The section you cited says "child class to inherit from its parent’s Meta
 class" which I interpret as the following:

 {{{
 class Parent(models.Model):
 class Meta:
 

 class Child(Parent):
 # no explicit meta definition
 }}}

 In my case, the Meta class is explicitly a subclass of the parent's Meta:

 {{{
 class Encounter(AbstractParentModel):
 class Meta(BreadMetaMixin, AbstractParentModel.Meta):
 pass

 class Admission(Encounter):
 class Meta(Encounter.Meta):  # EXPLICIT inheritance
 pass
 }}}

 So this should be covered by the Meta Inheritance documentation
 ([https://docs.djangoproject.com/en/2.0/topics/db/models/#meta-
 inheritance]).  This section specifically says:

 > If the child wants to extend the parent’s Meta class, it can subclass
 it... Django does make one adjustment to the Meta class of an abstract
 base class: before installing the Meta attribute, it sets abstract=False.

 It seems to me that it's also ignoring `default_permissions`.  At minimum,
 this is a documentation 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/070.832128351ec64ba4a1a289b05cccf54c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29389: Make Paginator reject non-integer page numbers of type float

2018-05-09 Thread Django

#29389: Make Paginator reject non-integer page numbers of type float
--+---
 Reporter:  Nicolas Noé   |Owner:  Nicolas Noé
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  2.0
 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 ):

 In [changeset:"2134e7d4391c2279f6cfddadc2a0c1195cec16e4" 2134e7d4]:
 {{{
 #!CommitTicketReference repository=""
 revision="2134e7d4391c2279f6cfddadc2a0c1195cec16e4"
 Refs #29389 -- Added Paginator test for float page number.
 }}}

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

Re: [Django] #29389: Make Paginator reject non-integer page numbers of type float

2018-05-09 Thread Django

#29389: Make Paginator reject non-integer page numbers of type float
--+---
 Reporter:  Nicolas Noé   |Owner:  Nicolas Noé
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  2.0
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+---
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"c629d4e9562e7b04b39ca5224af6fd08a3cb14bc" c629d4e9]:
 {{{
 #!CommitTicketReference repository=""
 revision="c629d4e9562e7b04b39ca5224af6fd08a3cb14bc"
 Fixed #29389 -- Made Paginator reject non-integer page numbers of type
 float.
 }}}

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

Re: [Django] #29390: trans_null.ngettext() should consider values of -1 as singular

2018-05-09 Thread Django

#29390: trans_null.ngettext() should consider values of -1 as singular
-+-
 Reporter:  Hasan Ramezani   |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:   |  Version:  2.0
  Internationalization   |
 Severity:  Normal   |   Resolution:  wontfix
 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 Carlton Gibson):

 * cc: Carlton Gibson (added)
 * status:  assigned => closed
 * resolution:   => wontfix


Comment:

 Hi Hasan. Thanks for the input.

 I'm inclined towards `wontfix` here. A couple of reasons:

 * As per Tim's point, I'm not at all convinced that `-1` is definitely
 singular. (Like "maybe" but I can't say either is wrong.)
 * As
 [https://github.com/django/django/pull/9932#pullrequestreview-118467505
 Simon commented on the PR] it breaks BC, and (per above) it's marginal at
 best, so not worth it.

 I'm going to close on that basis. If someone wants to make the case and
 re-open, I guess I'm happy to look again.

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

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

Re: [Django] #29385: Make ModelDetailView show model properties

2018-05-09 Thread Django

#29385: Make ModelDetailView show model properties
--+
 Reporter:  Bostjan Kaluza|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admindocs |  Version:  2.0
 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 Nat S Dunn):

 * cc: Nat S Dunn (added)


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

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

Re: [Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames() (was: Infinite loop in ExceptionReporter.get_traceback_frames)

2018-05-09 Thread Django

#29393: Infinite loop in ExceptionReporter.get_traceback_frames()
-+
 Reporter:  James Howe   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  2.0
 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.fd4e23cba571aa6e758f5c0ea1668d2c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29386: Meta Inheritance for default_permissions

2018-05-09 Thread Django

#29386: Meta Inheritance for default_permissions
-+-
 Reporter:  Clayton Daley|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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 Carlton Gibson):

 * component:  Uncategorized => Database layer (models, ORM)


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

Re: [Django] #29386: Meta Inheritance for default_permissions

2018-05-09 Thread Django

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

Comment:

This is expected behaviour.

The [https://docs.djangoproject.com/en/2.0/topics/db/models/#proxy-models
Proxy models docs] say:

> Proxy models inherit Meta attributes in the same way as regular models.

Here they link to the
[https://docs.djangoproject.com/en/2.0/topics/db/models/#meta-and-multi-
table-inheritance Meta and and multi-table inheritance section] which
says:

> ... it doesn’t make sense for a child class to inherit from its parent’s
Meta class... However, there are a few limited cases where the child
inherits behavior from the parent: if the child does not specify an
`ordering` attribute or a `get_latest_by attribute`, it will inherit these
from its parent.

`default_permissions` is not amongst the listed exceptions, so there is no
reason to expect it would be inherited.

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

Re: [Django] #29391: Postgres array lookups need to call get_db_prep_value to adapt values to their db representation (FieldGetDbPrepValueMixin)

2018-05-09 Thread Django

#29391: Postgres array lookups need to call get_db_prep_value to adapt values to
their db representation (FieldGetDbPrepValueMixin)
--+
 Reporter:  Gavin Wahl|Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  2.0
 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):

 * type:  Uncategorized => Bug
 * 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.6ade658a3c57ba7b4af217d95c0cafbb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames

2018-05-09 Thread Django

#29393: Infinite loop in ExceptionReporter.get_traceback_frames
-+--
 Reporter:  James Howe   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by James Howe):

 In a view, with `DEBUG = True`.
 {{{
 try:
 raise RuntimeError('outer') from RuntimeError('inner')
 except RuntimeError as exc:
 raise exc.__cause__
 }}}

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

Re: [Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames

2018-05-09 Thread Django

#29393: Infinite loop in ExceptionReporter.get_traceback_frames
-+--
 Reporter:  James Howe   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  2.0
 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):

 Can you please give code to reproduce the 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/067.ed3ff21d64fb73a428ba56bb92907ca0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29389: Make Paginator reject non-integer page numbers of type float

2018-05-09 Thread Django

#29389: Make Paginator reject non-integer page numbers of type float
--+---
 Reporter:  Nicolas Noé   |Owner:  Nicolas Noé
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  2.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+---
Changes (by Nicolas Noé):

 * has_patch:  0 => 1


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

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

Re: [Django] #29389: Make Paginator reject non-integer page numbers of type float

2018-05-09 Thread Django

#29389: Make Paginator reject non-integer page numbers of type float
--+---
 Reporter:  Nicolas Noé   |Owner:  Nicolas Noé
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  2.0
 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 Nicolas Noé):

 [https://github.com/django/django/pull/9935 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.69770269e9e121b61935bcd0c9088170%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29364: CommonMiddleware.get_full_path_with_slash should raise exception for POST / PUT / PATCH requests even if settings.DEBUG = False

2018-05-09 Thread Django

Comment (by Carlton Gibson):

I'd learn towards wontfix. I'd prefer to see a user land solution here
before altering the built-in behaviour.

Some thoughts:

* Disable `APPEND_SLASH`. This gives you your `404`. It may not actually
be desired behaviour.
* As per the CommonMiddleware docstring, subclass CommonMiddleware and
overriding the response_redirect_class attribute, returning the `307`
response. (Whether that's wise I can't say.)
* Otherwise subclassing CommonMiddleware to allow a more sophisticated
(conditional) handling.
* Adjust URL pattern to make trailing slash optional.
* (... and so on...)

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

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

Re: [Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames

2018-05-09 Thread Django

#29393: Infinite loop in ExceptionReporter.get_traceback_frames
-+--
 Reporter:  James Howe   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by James Howe):

 A possible workaround would be available if PEP 415
 (`__suppress_context__`) were respected.

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

[Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames

2018-05-09 Thread Django

#29393: Infinite loop in ExceptionReporter.get_traceback_frames
---+
   Reporter:  James Howe   |  Owner:  (none)
   Type:  Bug  | Status:  new
  Component:  Error reporting  |Version:  2.0
   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|
---+
 The following code generates a cause/context cycle
 (`exc_value.__cause__.__context__ is exc_value`):
 {{{
 except WrapperException as exc:
 raise exc.__cause__
 }}}

 The
 [https://github.com/django/django/blob/d79cf1e/django/views/debug.py#L397
 while exc_value] loop then never terminates.

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

Re: [Django] #29346: Add "intermediary" kwarg to ModelForm._save_m2m

2018-05-09 Thread Django

#29346: Add "intermediary" kwarg to ModelForm._save_m2m
---+--
 Reporter:  Douglas Denhartog  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Forms  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

 * status:  new => closed
 * needs_docs:  0 => 1
 * version:  2.0 => master
 * resolution:   => wontfix
 * needs_tests:  0 => 1


Comment:

 Hi Douglas. Thanks for the input.

 My initial response here is favour the existing API. Given that, and the
 lack of activity on the branch, I'm going to close this as `wontfix`.

 If you would like to add the test cases demonstrating the use-case, and
 maybe some docs, and open a PR on GitHub (against the `master` branch),
 then we can re-open/re-assess.
 (It's likely that we won't want an addition here — but if the use-case is
 compelling...)

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

Re: [Django] #29281: In some cases i18n set_language does not change url language

2018-05-09 Thread Django

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

Comment:

From Beda's description I recreated the issue: we set a language (once)
then try to reverse a URL from the old language when setting the language
again. This obviously fails.

Workarounds:

* keeping track of the old language and falling back to try that if the
lookup with the current language fails.
* Signalling across browser tabs that we already changed the language and
adjusting accordingly (???).

Both of these are out of scope for the in-built i18n. (The first would be
possible on a project basis — reimplementing e.g. `set_language` — if it
was deemed cost effective.)

I'm going to close this on that basis.

If a third option presents itself we could re-open/re-assess.

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

Re: [Django] #29281: In some cases i18n set_language does not change url language

2018-05-09 Thread Django

#29281: In some cases i18n set_language does not change url language
-+-
 Reporter:  Nikita Delyukov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.11
  Internationalization   |
 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 Carlton Gibson):

 * Attachment "29281-regression.patch" added.

 Failing test case: trying to reverse an `en` URL when the current language
 is already `nl`.

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

Re: [Django] #29379: Add autocomplete attribute to contrib.auth fields

2018-05-09 Thread Django

#29379: Add autocomplete attribute to contrib.auth fields
--+--
 Reporter:  CHI Cheng |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 This seems OK/good in theory. We're a bit ahead of the curve in terms of
 current browser support so there's a question about when (and whether)
 this gets adopted.

 [https://github.com/django/django/pull/9921 PR] has failures that need
 addressing.

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

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

2018-05-09 Thread Django

#29381: Move some parts of `django.contrib.auth.models` to
`django.contrib.auth.base_user` for reusability
---+--
 Reporter:  Sagar Chalise  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  2.0
 Severity:  Normal |   Resolution:  needsinfo
 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 Carlton Gibson):

 * cc: Carlton Gibson (added)
 * status:  new => closed
 * resolution:   => needsinfo


Old description:

> This is more of an idea than bug but most of the time when need to use
> authentication without using `contrib.auth` one needs to rewrite some of
> the parts that can be reused if it were in base_user when the interface
> is similar to django.contrib.auth.
> I am mostly talking about update_last_login function and AnonymousUser
> when custom user is derived from AbstractBaseUser.
>
> May be create AnonymousBaseUser with parts that are compatible to
> AbstractBaseUser in `base_user.py` and use that as base class for
> AnonymousUser. Also, update_last_login function can be moved to
> `base_user.py` so that it can be reused.

New description:

 
 This is more of an idea than bug but most of the time when need to use
 authentication without using `contrib.auth` one needs to rewrite some of
 the parts that can be reused if it were in base_user when the interface is
 similar to django.contrib.auth.
 I am mostly talking about update_last_login function and AnonymousUser
 when custom user is derived from AbstractBaseUser.

 May be create AnonymousBaseUser with parts that are compatible to
 AbstractBaseUser in `base_user.py` and use that as base class for
 AnonymousUser. Also, update_last_login function can be moved to
 `base_user.py` so that it can be reused.

--

Comment:

 Hi Sagar. Thanks for the input.

 I'm going to close this as `needsinfo` as is. The general idea is ''Yeah,
 possibly'' but it's too vague to be actionable in its current form.

 If you want to push this forwards then I would recommend an exploratory
 PR: make some (small) changes; what tests break?; what does it allow you
 to do?; etc. From there we've got something concrete to assess. Does that
 make sense?

 Please feel free to re-open this issue if you come up with something
 concrete along these lines!

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

Re: [Django] #29382: don't call objects with call instantly

2018-05-09 Thread Django

#29382: don't call objects with __call__ instantly
-+--
 Reporter:  alex |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Template system  |  Version:  1.11
 Severity:  Normal   |   Resolution:  duplicate
 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 Carlton Gibson):

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


Comment:

 Closing as duplicate of #29306 and/or #15791.

 (`wtforms` should be able to allow marking labels with
 `do_not_call_in_templates` to control the behaviour 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.dab2b7fff8b1b54c1b990f6ed86f2478%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29387: GenericRelation's on proxy models do not cascade deletion

2018-05-09 Thread Django

#29387: GenericRelation's on proxy models do not cascade deletion
---+--
 Reporter:  Mehmet Dogan   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  2.0
 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 Carlton Gibson):

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


Comment:

 I uploaded a regression test attempting to reproduce this. It already
 passes.

 If we can get a failing test case reproducing the issue then we could look
 into it. Pending that I'm going to close.

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

Re: [Django] #29387: GenericRelation's on proxy models do not cascade deletion

2018-05-09 Thread Django

#29387: GenericRelation's on proxy models do not cascade deletion
---+--
 Reporter:  Mehmet Dogan   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.0
 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 Carlton Gibson):

 * Attachment "29387-regression-test.patch" added.

 Regression test — already passes

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

Re: [Django] #20147: Provide an alternative to request.META for accessing HTTP headers

2018-05-09 Thread Django

#20147: Provide an alternative to request.META for accessing HTTP headers
---+---
 Reporter:  Luke Plant |Owner:  santiagobasulto
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by Asif Saifuddin Auvi):

 * has_patch:  0 => 1


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

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

Re: [Django] #29392: Command parsing does not handle options that conflict with `--settings`/`--pythonpath`

2018-05-09 Thread Django

* version: 2.0 => master
* type: Bug => New feature
* stage: Unreviewed => Accepted

Comment:

Hi Ryan. Thanks for the report. This seems reasonable.

Interestingly, with the patch, if you pass an abbreviation to second
parser you get the error you'd expect:

manage.py config: error: ambiguous option: --se could match --set,
--settings

> ...this option is only available in Python 3.5 and above.

Right. For that reason lets call this a New Feature and roll it into 2.1,
where we don't have to worry about compat. (This has existed for ≈forever
so I can't see the harm in holding off slightly.)

> Also, this might be considered a breaking change if users are expecting
to be able to use the abbreviated option names, but I don't know if that's
really a concern.

Yes, probably not a biggie but could you add a note to the Breaking
changes section in `2.1.txt`.

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

Re: [Django] #26600: map says a queryset is not iterable

Re: [Django] #29386: Meta Inheritance for default_permissions

Re: [Django] #29363: Use unittest assertWarns methods instead of warnings.catch_warnings/simplefilter/assertions in the test suite.

Re: [Django] #26600: map says a queryset is not iterable

Re: [Django] #26600: map says a queryset is not iterable

Re: [Django] #29386: Meta Inheritance for default_permissions

Re: [Django] #29386: Meta Inheritance for default_permissions

Re: [Django] #29386: Meta Inheritance for default_permissions

Re: [Django] #29386: Meta Inheritance for default_permissions

Re: [Django] #29389: Make Paginator reject non-integer page numbers of type float

Re: [Django] #29389: Make Paginator reject non-integer page numbers of type float

Re: [Django] #29390: trans_null.ngettext() should consider values of -1 as singular

Re: [Django] #29385: Make ModelDetailView show model properties

Re: [Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames() (was: Infinite loop in ExceptionReporter.get_traceback_frames)

Re: [Django] #29386: Meta Inheritance for default_permissions

Re: [Django] #29386: Meta Inheritance for default_permissions

Re: [Django] #29391: Postgres array lookups need to call get_db_prep_value to adapt values to their db representation (FieldGetDbPrepValueMixin)

Re: [Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames

Re: [Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames

Re: [Django] #29389: Make Paginator reject non-integer page numbers of type float

Re: [Django] #29389: Make Paginator reject non-integer page numbers of type float

Re: [Django] #29364: CommonMiddleware.get_full_path_with_slash should raise exception for POST / PUT / PATCH requests even if settings.DEBUG = False

Re: [Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames

[Django] #29393: Infinite loop in ExceptionReporter.get_traceback_frames

Re: [Django] #29346: Add "intermediary" kwarg to ModelForm._save_m2m

Re: [Django] #29281: In some cases i18n set_language does not change url language

Re: [Django] #29281: In some cases i18n set_language does not change url language

Re: [Django] #29379: Add autocomplete attribute to contrib.auth fields

Re: [Django] #29381: Move some parts of `django.contrib.auth.models` to `django.contrib.auth.base_user` for reusability

Re: [Django] #29382: don't call objects with call instantly

Re: [Django] #29387: GenericRelation's on proxy models do not cascade deletion

Re: [Django] #29387: GenericRelation's on proxy models do not cascade deletion

Re: [Django] #20147: Provide an alternative to request.META for accessing HTTP headers

Re: [Django] #29392: Command parsing does not handle options that conflict with `--settings`/`--pythonpath`

34 matches

Site Navigation

Mail list logo

Footer information