Re: [Django] #28687: Add a 'Not Empty' option to admin's related filter

[Django]

#28687: Add a 'Not Empty' option to admin's related filter
-+-
 Reporter:  Brillgen Developers  |Owner:  Jake
 Type:   |  Barber
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  2.0
 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 Carlton Gibson):

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


Comment:

 OK, patch looks good.

 I have a small reservation about whether we want yet more API on
 ModelAdmin to add the `not_empty_value_display` option, rather than
 steering users to subclassing `FieldListFilter` themselves, but bar
 that...

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

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
-+
 Reporter:  Russell Keith-Magee  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  feature test models  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by direx):

 * cc: direx (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/066.2b1f76187c94c46919bc5c1493c31c03%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29464: Move collectstatic post processing messages to verbosity 2

[Django]

#29464: Move collectstatic post processing messages to verbosity 2
-+-
 Reporter:  David Szotten|Owner:  arthurspa
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.staticfiles  |  Version:  2.1
 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 arthurspa):

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

Re: [Django] #29481: Documentation should mention that cloning a QuerySet retains the underlying database

[Django]

#29481: Documentation should mention that cloning a QuerySet retains the 
underlying
database
-+-
 Reporter:  Marco Bonetti|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  using, database, | Triage Stage:  Accepted
  documentation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Simon Charette):

 I agree with Tim on this one. What behavior were you expecting Marco, to
 require calling `using()` before each `filter()` call?

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

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

Re: [Django] #29474: Simply BaseInlineFormset.save_new() with call to super()

[Django]

#29474: Simply BaseInlineFormset.save_new() with call to super()
-+-
 Reporter:  ljsjl|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"236bcfea429d6b0c6b3dcd102c09d3a4c75b84d8" 236bcfea]:
 {{{
 #!CommitTicketReference repository=""
 revision="236bcfea429d6b0c6b3dcd102c09d3a4c75b84d8"
 Fixed #29474 -- Simplified BaseInlineFormset.save_new().
 }}}

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

Re: [Django] #29474: Simply BaseInlineFormset.save_new() with call to super() (was: BaseInlineFormset.save_new() more complicated than it needs to be?)

[Django]

#29474: Simply BaseInlineFormset.save_new() with call to super()
-+-
 Reporter:  ljsjl|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  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):

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


Comment:

 The simplification looks possible since
 4c2f546b55c029334d22e69bb29db97f9356faa3.
 [https://github.com/django/django/pull/10034 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/063.e5dc9f74a11aba1f5cb1b02e8474a025%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29482: simplify KeyTransform to always use the 'nested_operator'

[Django]

#29482: simplify KeyTransform to always use the 'nested_operator'
+--
 Reporter:  David De Sousa  |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
+--

Comment (by Matthew Schinckel):

 Does it need something to do with array elements vs object keys? Or does
 the postgres nested operator already handle that?

 If you had a top-level (and non-nested) JSON array in a field, you'd
 probably want to stick to a simpler index/operator, I think.

 I haven't looked into this, it's just thoughts.

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

Re: [Django] #29472: Natural key not serializing for primary_key OneToOneField

[Django]

#29472: Natural key not serializing for primary_key OneToOneField
-+-
 Reporter:  Ferd Snidely |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:  2.0
  (Serialization)|
 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 Tim Graham):

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


Comment:

 Seems to be a duplicate of #24607 as the tests in the sample project pass
 after the commit for that ticket.

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

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

Re: [Django] #29454: Default size for django.core.files.uploadedfile is None and then len will raise error

[Django]

#29454: Default size for django.core.files.uploadedfile is None and then len 
will
raise error
-+-
 Reporter:  jxltom   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  File |  Version:  2.0
  uploads/storage|
 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 Tim Graham):

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


Comment:

 Closing, absent some use case for the fix.

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

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

Re: [Django] #29478: cached_property decorator doesn't work with mangled method names

[Django]

#29478: cached_property decorator doesn't work with mangled method names
-+
 Reporter:  Thomas Grainger  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  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 Tim Graham):

 * component:  Uncategorized => Utilities
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

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

Re: [Django] #29483: Confirm support for GDAL 2.3

[Django]

#29483: Confirm support for GDAL 2.3
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  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):

 * Attachment "29483-docs.diff" added.


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

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

[Django] #29483: Confirm support for GDAL 2.3

[Django]

#29483: Confirm support for GDAL 2.3
+
   Reporter:  Tim Graham|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  GIS   |Version:  2.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 I see a number of test failures with GDAL 2.3 (attached) but as in #28257,
 it might merely be a problem on my machine.

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

Re: [Django] #29483: Confirm support for GDAL 2.3

[Django]

#29483: Confirm support for GDAL 2.3
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  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):

 * Attachment "gdal-2.3-failures.txt" added.


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

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

Re: [Django] #29464: Move collectstatic post processing messages to verbosity 2

[Django]

#29464: Move collectstatic post processing messages to verbosity 2
--+
 Reporter:  David Szotten |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.staticfiles   |  Version:  2.1
 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 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/070.ef8e9c1137bf7257b45b290bc69026c1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29469: Misleading makemigrations "App count not be found" error message with nested apps (was: Makemigrations provides misleading error message.)

[Django]

#29469: Misleading makemigrations "App count not be found" error message with
nested apps
---+
 Reporter:  Matthew Schinckel  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  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.7d8bdac8ef935042b8497243c78c7134%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29481: Documentation should mention that cloning a QuerySet retains the underlying database

[Django]

#29481: Documentation should mention that cloning a QuerySet retains the 
underlying
database
-+-
 Reporter:  Marco Bonetti|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  using, database, | Triage Stage:  Accepted
  documentation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 Isn't this consistent with chaining any other queryset method? I don't see
 why the expected behavior of `using()` would be different or why it would
 deserve a special mention.

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

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

Re: [Django] #29473: Postgres JSONField escaping to infinity on each save

[Django]

#29473: Postgres JSONField escaping to infinity on each save
-+-
 Reporter:  Laurynas Riliskis|Owner:  (none)
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  2.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  postgress| Triage Stage:
  JSONFields |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * status:  new => closed
 * resolution:   => 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/068.96178e0041359dce154f13f4b82533b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29482: simplify KeyTransform to always use the 'nested_operator'

[Django]

#29482: simplify KeyTransform to always use the 'nested_operator'
+--
 Reporter:  David De Sousa  |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
+--

Comment (by Simon Charette):

 From my understanding the `->` and `->>` operators are used instead of
 their `#` variant when the key lookup depth is 1 for readability purposes.

 Is there a reason you can't create your non-nested attribute lookups using
 the `->` and `->>` operators instead? Are you suggesting we favor the `#`
 syntax because a functional index on `data#>'{a,b}'` would be used when
 doing a `data#>'{a}'` lookup?

 I'm asking because changing it at this point is likely to break any
 previously created functional index created using these operators for the
 same reason you are asking them to be changed here. I assume this is
 something that would eventually be fixed in PostgreSQL.

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

Re: [Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
-+-
 Reporter:  Bartosz Grabski  |Owner:  Bartosz
 |  Grabski
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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
-+-

Comment (by Claude Paroz):

 I think you could just unit test the write_pot_file method with some
 content like:
 {{{
 # SOME DESCRIPTIVE TITLE.
 # Copyright (C) YEAR THE PACKAGE\'S COPYRIGHT HOLDER
 # This file is distributed under the same license as the PACKAGE package.
 # FIRST AUTHOR , YEAR.
 #
 #, fuzzy
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2018-06-07 17:21+0200\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME \n"
 "Language-Team: LANGUAGE \n"
 "Language: \n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=CHARSET\n"
 "Content-Transfer-Encoding: 8bit\n"

 #: django/contrib/gis/apps.py:8
 msgid "GIS"
 msgstr ""

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

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

[Django] #29482: simplify KeyTransform to always use the 'nested_operator'

[Django]

#29482: simplify KeyTransform to always use the 'nested_operator'
--+
   Reporter:  David De Sousa  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |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   |
--+
 Currently, the `KeyTransform` and `KeyTextTransform` classes in the JSONB
 Field lookups are making a distinction in the way the query is being
 generated based on the depth of the key inside the JSON, using a different
 operator depending on if the key is in the root of the json or not.

 This is an issue specially if you create indexes based on jsonb
 traversals, for some reason if you create an index with the path operators
 (#> or #>>) and then query with the "regular" operators (-> or ->>) the
 indexes are not always used.

 I've tested removing the use of the `operator` and basically just leaving
 the return in
 
https://github.com/django/django/blob/2.0.6/django/contrib/postgres/fields/jsonb.py#L105
 as the only return in the function and it works for me, I'd be happy to
 create a PR but I don't know if that distinction is there for a reason.

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

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

Re: [Django] #29481: Documentation should mention that cloning a QuerySet retains the underlying database

[Django]

#29481: Documentation should mention that cloning a QuerySet retains the 
underlying
database
-+-
 Reporter:  Marco Bonetti|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  using, database, | Triage Stage:  Accepted
  documentation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * type:  Uncategorized => Cleanup/optimization
 * easy:  0 => 1
 * 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/061.683ac1c6605b145284d6030854072539%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29481: Documentation should mention that cloning a QuerySet retains the underlying database (was: Documentation sould mention that cloning a QuerySet retains the underlying database)

[Django]

#29481: Documentation should mention that cloning a QuerySet retains the 
underlying
database
-+-
 Reporter:  Marco Bonetti|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:  using, database, | Triage Stage:
  documentation  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

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

[Django] #29481: Documentation sould mention that cloning a QuerySet retains the underlying database

[Django]

#29481: Documentation sould mention that cloning a QuerySet retains the 
underlying
database
-+-
   Reporter:  Marco  |  Owner:  nobody
  Bonetti|
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  2.1
  Documentation  |   Keywords:  using, database,
   Severity:  Normal |  documentation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 For example, in the following code…

 {{{
 qs1 = Entry.objects.using('backup')
 qs2 = qs1.filter(…)
 qs3 = qs2.filter(…)
 }}}

 … it is not obvious that qs2 and qs3 will "inherit" the underlying
 database defined in qs1's using() method.

 The current
 [https://docs.djangoproject.com/en/2.1/ref/models/querysets/#using
 documentation on using()] fails to mention this.

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

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

Re: [Django] #28462: ModelAdmin.list_editable unusably slow and memory intensive with large datasets

[Django]

#28462: ModelAdmin.list_editable unusably slow and memory intensive with large
datasets
-+-
 Reporter:  Ben Cole |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  1.10
 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
-+-

Comment (by Tim Graham ):

 In [changeset:"56c5c1599a884f6d985c68c54d106db50381e02e" 56c5c159]:
 {{{
 #!CommitTicketReference repository=""
 revision="56c5c1599a884f6d985c68c54d106db50381e02e"
 [1.11.x] Fixed #28462 -- Decreased memory usage with
 ModelAdmin.list_editable.

 Regression in 917cc288a38f3c114a5440f0749b7e5e1086eb36.

 Backport of b18650a2634890aa758abae2f33875daa13a9ba3 from master
 }}}

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

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

Re: [Django] #29480: mysql constraints are sometimes retrieved out of the order that they are defined in

[Django]

#29480: mysql constraints are sometimes retrieved out of the order that they are
defined in
-+--
 Reporter:  Thomas Grainger  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--

Comment (by Thomas Grainger):

 To be clear this is not a problem with the order of the constraints
 themselves just the columns in those constraints:
 
https://github.com/graingert/django/blob/43cc0fb511f989e1eb15137624b72c1e21a0cdd9/django/db/backends/mysql/introspection.py#L169

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

[Django] #29480: mysql constraints are sometimes retrieved out of the order that they are defined in

[Django]

#29480: mysql constraints are sometimes retrieved out of the order that they are
defined in
---+
   Reporter:  Thomas Grainger  |  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  Uncategorized|Version:  2.0
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+
 See https://github.com/django/django/pull/9941

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

Re: [Django] #29479: 'caches' is not declared in __all__

[Django]

#29479: 'caches' is not declared in __all__
-+-
 Reporter:  Victor Borisov   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  2.0
 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 Tim Graham):

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


Comment:

 In 0914a2003b1ad50f1d641709da86c14826bf063b:

 Added 'caches' to `django.core.cache.__all__`.

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

[Django] #29479: 'caches' is not declared in __all__

[Django]

#29479: 'caches' is not declared in __all__
+
   Reporter:  Quazer|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Cache system)   |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 |
+
 There is an example in the documentation:

 {{{
 from django.core.cache import caches
 }}}

 [https://docs.djangoproject.com/en/2.0/topics/cache/#django.core.cache.caches]

 but 'caches' is not declared in {{{__all__}}}, may be insert it in?

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

Re: [Django] #28808: Allow customizing the fallback language

[Django]

#28808: Allow customizing the fallback language
-+-
 Reporter:  Denis Anuschewski|Owner:  Claude
 |  Paroz
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translation, | Triage Stage:
  internationalization, request  |  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ramiro Morales):

 * has_patch:  0 => 1
 * stage:  Accepted => Unreviewed


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

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

[Django] #29478: cached_property decorator doesn't work with mangled method names

[Django]

#29478: cached_property decorator doesn't work with mangled method names
---+
   Reporter:  Thomas Grainger  |  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  Uncategorized|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|
---+
 {{{
 import itertools

 from django.utils.functional import cached_property

 count = itertools.count()
 count2 = itertools.count()
 count3 = itertools.count()


 class Foo:
 @cached_property
 def __foo(self):
 return next(count)

 @cached_property
 def foo2(self):
 return next(count2)

 @property
 def foo3(self):
 return next(count3)

 def run(self):
 print('foo', self.__foo)
 print('foo', self.__foo)
 print('foo', self.__foo)
 print('foo', self.__foo)
 print('foo2', self.foo2)
 print('foo2', self.foo2)
 print('foo2', self.foo2)
 print('foo2', self.foo2)
 print('foo2', self.foo2)
 print('foo3', self.foo3)
 print('foo3', self.foo3)
 print('foo3', self.foo3)
 print('foo3', self.foo3)
 print('foo3', self.foo3)


 Foo().run()


 """
 python cached_property_test.py
 foo 0
 foo 1
 foo 2
 foo 3
 foo2 0
 foo2 0
 foo2 0
 foo2 0
 foo2 0
 foo3 0
 foo3 1
 foo3 2
 foo3 3
 foo3 4
 """
 }}}


 Odd it's not been reported before:
 https://code.djangoproject.com/search?q=cached_property+mangled

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

Re: [Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
-+-
 Reporter:  Bartosz Grabski  |Owner:  Bartosz
 |  Grabski
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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 Ramiro Morales):

 * Attachment "29452-test.diff" added.

 Test case

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

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

Re: [Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
-+-
 Reporter:  Bartosz Grabski  |Owner:  Bartosz
 |  Grabski
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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 Ramiro Morales):

 * Attachment "29452-test.diff" added.

 Test case

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

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

Re: [Django] #29452: makemessages command doesn't set .pot file charset properly

[Django]

#29452: makemessages command doesn't set .pot file charset properly
-+-
 Reporter:  Bartosz Grabski  |Owner:  Bartosz
 |  Grabski
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  1.11
  Internationalization   |
 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
-+-

Comment (by Ramiro Morales):

 I'm the one who introduced this bug in
 6ab0d1358fc78077064aab88a4fb0a47ca116391. ''Mea culpa''.

 I can contribute a test case (also attached):
 {{{
 #!diff
 diff --git a/tests/i18n/commands/templates/test.html
 b/tests/i18n/commands/templates/test.html
 index cac034e..3868dc1 100644
 --- a/tests/i18n/commands/templates/test.html
 +++ b/tests/i18n/commands/templates/test.html
 @@ -105,3 +105,5 @@ Plural for a `trans` and `blocktrans` collision case
  {% endblocktrans %}

  {% trans "Non-breaking space :" %}
 +
 +{% trans "Nón-ÁSCÍÏ text" %}
 diff --git a/tests/i18n/test_extraction.py b/tests/i18n/test_extraction.py
 index d9ce3b4..e7557fc 100644
 --- a/tests/i18n/test_extraction.py
 +++ b/tests/i18n/test_extraction.py
 @@ -394,6 +394,14 @@ class BasicExtractorTests(ExtractorTests):
  po_contents = fp.read()
  self.assertMsgStr("Größe", po_contents)

 +def test_pot_charset_header_is_utf8(self):
 +self.assertFalse(os.path.exists(self.POT_FILE))
 +management.call_command('makemessages', locale=[LOCALE],
 verbosity=0, keep_pot=True)
 +self.assertTrue(os.path.exists(self.POT_FILE))
 +with open(self.POT_FILE, 'r', encoding='utf-8') as fp:
 +contents = fp.read()
 +self.assertIn(r'; charset=UTF-8\n"', contents)
 +

  class JavascriptExtractorTests(ExtractorTests):

 }}}

 Problem is I can't reproduce the error condition.

 In the added test case:
 * There is a translatable literal with non-ASCII characters (in a template
 file)
 * The intermediate POT file is created (and preserved for examination)
 * When the POT file is created, the header `"Content-Type: text/plain;
 charset=?\n"` is verified and it already has the `UFT-8` value for the
 charset.

 Am I missing something? How it comes the created POT file has a `"Content-
 Type: text/plain; charset=CHARSET\n"` header?
 * Is the fact tha OP is running on Windows?
 * Does this happen when extracting literal from .py files? Javascript?

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

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

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

[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
-+-

Comment (by Philipp Kuznetsov):

 I'm really sorry, of course in case of `in` exception message is `argument
 of type 'QuerySet' is not iterable`. This has nothing to do with `map` and
 ofc there's an obvious workaround with `exists()`. What I am afraid of is
 if there are more of this hidden cases where queryset's `__iter__` raises
 an exception and it's shadowed by the outer code exception.

 Replying to [comment:11 Simon Charette]:
 > Philipp, if you hit a similar exception that means `map` must be
 involved somehow.
 >
 > If you didn't call it yourself then it's likely caused by a usage of
 `map` internally in the queryset iteration code.
 >
 > In this case the ticket resolution still stands, Python 2 `map`'s
 shadowing of the underlying exception makes it impossible to determine its
 true nature and thus we cannot conclude Django is at fault. As mentioned
 previously this should all be solved on Python 3 where `map` doesn't
 exhibit this behaviour.
 >
 > By the way an `in` operation on a queryset you are disposing off is
 likely to trigger a `MemoryError` just like in the original report. I'd
 suggest you opt for something along
 `queryset.filter(pk=instance.pk).exists()` instead.

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

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