Re: [Django] #25869: add support for GEOSWKTWriter_setRoundingPrecision and GEOSWKTWriter_setTrim

[Django]

#25869: add support for GEOSWKTWriter_setRoundingPrecision and
GEOSWKTWriter_setTrim
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by sir-sigurd):

 * owner:  nobody => sir-sigurd
 * needs_docs:   => 0
 * status:  new => assigned
 * needs_tests:   => 0
 * needs_better_patch:   => 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/068.100ff029a2d389456d3e9ccb48fa892d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25869: add support for GEOSWKTWriter_setRoundingPrecision and GEOSWKTWriter_setTrim

[Django]

#25869: add support for GEOSWKTWriter_setRoundingPrecision and
GEOSWKTWriter_setTrim
-+
 Reporter:  sir-sigurd   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  GIS  |Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  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/053.3c81dba8e4a4e0efba065f8f9f03e837%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25547: refresh_from_db leaves FieldFile with reference to db_instance

[Django]

#25547: refresh_from_db leaves FieldFile with reference to db_instance
-+-
 Reporter:  vinnyrose|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  refresh_from_db, | Triage Stage:  Accepted
  fieldfile  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Uran198):

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

Re: [Django] #25547: refresh_from_db leaves FieldFile with reference to db_instance

[Django]

#25547: refresh_from_db leaves FieldFile with reference to db_instance
-+-
 Reporter:  vinnyrose|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  refresh_from_db, | Triage Stage:  Accepted
  fieldfile  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Uran198):

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

Re: [Django] #25677: compilemessages throws an exception and does not report msgformat errors correctly

[Django]

#25677: compilemessages throws an exception and does not report msgformat errors
correctly
-+-
 Reporter:  gavinwahl|Owner:  Claude
 |  Paroz 
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 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 timgraham):

 [https://github.com/django/django/pull/5772 Skipping the test] for older
 versions of gettext seems to work. This doesn't solve the other issues on
 Windows.

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

Re: [Django] #25866: Django migrations not picking up max_length change on FileField

[Django]

#25866: Django migrations not picking up max_length change on FileField
--+
 Reporter:  gabn88|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  1.7
 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 timgraham):

 * component:  Database layer (models, ORM) => Migrations
 * type:  Bug => Cleanup/optimization
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 I can reproduce the issue -- the choice of database shouldn't matter as
 it's an issue with the autodetector. I'm not sure how/if it can be fixed
 though. Any fields that use the default `max_length` won't have that data
 written to the migration file, so if the default is changed, Django has no
 way of knowing about this. We might have to document the limitation. I
 thought that adding an explicit `max_length` to any fields in existing
 migration files would be a workaround, but unless I made an error in my
 testing, this doesn't work although I didn't track down the reason why.

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

Re: [Django] #25868: Importing django.test.utils.get_runner fails on Django 1.9 with Python 3.3

[Django]

#25868: Importing django.test.utils.get_runner fails on Django 1.9 with Python 
3.3
---+--
 Reporter:  sobotklp   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.9
 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 timgraham):

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


Comment:

 From the 1.9 release notes:

Django 1.9 requires Python 2.7, 3.4, or 3.5. We highly recommend and
 only officially support the latest release of each series. Since Django
 1.8, we’ve dropped support for Python 3.2 and 3.3.

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

[Django] #25868: Importing django.test.utils.get_runner fails on Django 1.9 with Python 3.3

[Django]

#25868: Importing django.test.utils.get_runner fails on Django 1.9 with Python 
3.3
---+
 Reporter:  sobotklp   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The following code:
 {{{
 from django.test.utils import get_runner
 }}}

 Errors out with the following traceback in Django 1.9 with Python 3.3:

 {{{
 Traceback (most recent call last):
   File "runtests.py", line 116, in 
 runtests(failfast=options.failfast, verbosity=options.verbosity,
 coverage=options.coverage, *args)
   File "runtests.py", line 92, in runtests
 from django.test.utils import get_runner
   File "/usr/local/lib/python3.3/site-packages/django/test/__init__.py",
 line 5, in 
 from django.test.client import Client, RequestFactory
   File "/usr/local/lib/python3.3/site-packages/django/test/client.py",
 line 12, in 
 from django.apps import apps
   File "/usr/local/lib/python3.3/site-packages/django/apps/__init__.py",
 line 1, in 
 from .config import AppConfig
   File "/usr/local/lib/python3.3/site-packages/django/apps/config.py",
 line 6, in 
 from django.utils.module_loading import module_has_submodule
   File "/usr/local/lib/python3.3/site-
 packages/django/utils/module_loading.py", line 67, in 
 from importlib.util import find_spec as importlib_find
 ImportError: cannot import name find_spec
 }}}

 Apparently importlib.util.find_spec appeared in Python 3.4 and thus fails
 to import in Python 3.2 and 3.3:
 https://docs.python.org/3/library/importlib.html#importlib.util.find_spec

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

Re: [Django] #25866: Django migrations not picking up max_length change on FileField

[Django]

#25866: Django migrations not picking up max_length change on FileField
-+-
 Reporter:  gabn88   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by emre):

 in which database do you try 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/064.126d65a5a50c49a39bbe91287a0e8656%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25867: Nested ArrayField cause error in system check on 1.9

[Django]

#25867: Nested ArrayField cause error in system check on 1.9
--+-
 Reporter:  mpre  |Owner:  charettes
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.9
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by charettes):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #25867: Nested ArrayField cause error in system check on 1.9

[Django]

#25867: Nested ArrayField cause error in system check on 1.9
--+-
 Reporter:  mpre  |Owner:  charettes
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.9
 Severity:  Release blocker   |   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 charettes):

 * status:  new => assigned
 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:   => charettes
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I have a patch in mind.

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

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

[Django] #25867: Nested ArrayField cause error in system check on 1.9

[Django]

#25867: Nested ArrayField cause error in system check on 1.9
--+-
 Reporter:  mpre  |  Owner:
 Type:  Bug   | Status:  new
Component:  contrib.postgres  |Version:  1.9
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 Nested ArrayField generates an error during check errors in 1.9, but works
 on 1.8.7

 Using a nested ArrayField from the docs will cause the error in 1.9:

 To recreate, in a fresh project add the following models.py:

 {{{#!python
 from django.contrib.postgres.fields import ArrayField
 from django.db import models

 class Board(models.Model):
 pieces = ArrayField(ArrayField(models.IntegerField()))
 }}}

 When you runserver the system check fails:

 {{{#!python
 Unhandled exception in thread started by 
 Traceback (most recent call last):
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/utils/autoreload.py", line 226, in wrapper
 fn(*args, **kwargs)
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/core/management/commands/runserver.py", line 116, in
 inner_run
 self.check(display_num_errors=True)
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 426, in check
 include_deployment_checks=include_deployment_checks,
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/core/checks/registry.py", line 75, in run_checks
 new_errors = check(app_configs=app_configs)
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/core/checks/model_checks.py", line 28, in check_all_models
 errors.extend(model.check(**kwargs))
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 1170, in check
 errors.extend(cls._check_fields(**kwargs))
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 1247, in _check_fields
 errors.extend(field.check(**kwargs))
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/contrib/postgres/fields/array.py", line 49, in check
 base_errors = self.base_field.check()
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/contrib/postgres/fields/array.py", line 49, in check
 base_errors = self.base_field.check()
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/db/models/fields/__init__.py", line 1820, in check
 errors = super(IntegerField, self).check(**kwargs)
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/db/models/fields/__init__.py", line 208, in check
 errors.extend(self._check_backend_specific_checks(**kwargs))
   File "/home/vagrant/.virtualenvs/djangotest/local/lib/python2.7/site-
 packages/django/db/models/fields/__init__.py", line 314, in
 _check_backend_specific_checks
 app_label = self.model._meta.app_label
 AttributeError: 'IntegerField' object has no attribute 'model'
 }}}

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

Re: [Django] #25740: document GEOSGeomerty operators

[Django]

#25740: document GEOSGeomerty operators
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 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:"479ba5add23c119387baa60d5dce3a4e17d1b15b" 479ba5a]:
 {{{
 #!CommitTicketReference repository=""
 revision="479ba5add23c119387baa60d5dce3a4e17d1b15b"
 Fixed #25740 -- Documented GEOSGeometry operators.
 }}}

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

Re: [Django] #25740: document GEOSGeomerty operators

[Django]

#25740: document GEOSGeomerty operators
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.8
 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
-+-

Comment (by Tim Graham ):

 In [changeset:"458e7dbc54d007154625266a099bca2eae2a318b" 458e7dbc]:
 {{{
 #!CommitTicketReference repository=""
 revision="458e7dbc54d007154625266a099bca2eae2a318b"
 [1.9.x] Fixed #25740 -- Documented GEOSGeometry operators.

 Backport of 479ba5add23c119387baa60d5dce3a4e17d1b15b 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/068.ed91f417f822af925afa42c9bc850560%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25840: cache.get_or_set() works incorrectly with DummyCache backend

[Django]

#25840: cache.get_or_set() works incorrectly with DummyCache backend
-+-
 Reporter:  oleksiyivanenko  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  get_or_set   | Triage Stage:  Accepted
  dummycache |
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:"9733ff5f991356ac98d499f24f2241141863a555" 9733ff5]:
 {{{
 #!CommitTicketReference repository=""
 revision="9733ff5f991356ac98d499f24f2241141863a555"
 [1.9.x] Fixed #25840 -- Fixed BaseCache.get_or_set() on the DummyCache
 backend.

 This also fixes a possible data eviction race condition between
 setting and getting a key. Another thread could remove the key
 before get_and_set() accesses it again. In this case, now the
 default value will be returned instead of None.

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

Re: [Django] #25840: cache.get_or_set() works incorrectly with DummyCache backend

[Django]

#25840: cache.get_or_set() works incorrectly with DummyCache backend
-+-
 Reporter:  oleksiyivanenko  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  get_or_set   | Triage Stage:  Accepted
  dummycache |
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:"8e838d9c869083597dc9e161ae2fe37acaa90de9" 8e838d9]:
 {{{
 #!CommitTicketReference repository=""
 revision="8e838d9c869083597dc9e161ae2fe37acaa90de9"
 Fixed #25840 -- Fixed BaseCache.get_or_set() on the DummyCache backend.

 This also fixes a possible data eviction race condition between
 setting and getting a key. Another thread could remove the key
 before get_and_set() accesses it again. In this case, now the
 default value will be returned instead of None.
 }}}

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

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

Re: [Django] #25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9

[Django]

#25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9
---+--
 Reporter:  stephanm   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.9
 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
---+--

Comment (by aaugustin):

 This is the expected behavior. You need to setup Django before importing
 models.

 To avoid the extra `if __name__ == '__main__'` I think we should make
 `django.setup()` idempotent.

 I'll write to the DevelopersMailingList about this idea.

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

Re: [Django] #25866: Django migrations not picking up max_length change on FileField

[Django]

#25866: Django migrations not picking up max_length change on FileField
-+-
 Reporter:  gabn88   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by gabn88:

Old description:

> I have subclassed a FileField (call it S3storage) which first had no
> max_length
>
> Now I changed max_length to 1000. Then running ./manage.py makemigrations
> it does not seems to be picked up.
>
> The only thing I did was:
> {{
> class S3FileField(models.FileField):
> def __init__(self, *args, **kwargs):
> super(S3PrivateFileField, self).__init__(*args, **kwargs)
> self.storage.default_acl = "private"
> }}

New description:

 I have subclassed a FileField (call it S3storage) which first had no
 max_length

 Now I changed max_length to 1000. Then running ./manage.py makemigrations
 it does not seems to be picked up.

 The only thing I did was:
 {{{
 class S3FileField(models.FileField):
 def __init__(self, *args, **kwargs):
 super(S3PrivateFileField, self).__init__(*args, **kwargs)
 self.storage.default_acl = "private"
 }}}

--

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

Re: [Django] #25866: Django migrations not picking up max_length change on FileField

[Django]

#25866: Django migrations not picking up max_length change on FileField
-+-
 Reporter:  gabn88   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by gabn88):

 Ah, sorry! It works like I posted. But I wanted to do:


 {{{
 class S3PrivateFileField(models.FileField):
 def __init__(self, *args, **kwargs):
 if not kwargs.get('max_length',None):
 kwargs.update({'max_length':1000})
 super(S3PrivateFileField, self).__init__(*args, **kwargs)
 self.storage.default_acl = "private"
 }}}

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

Re: [Django] #25866: Django migrations not picking up max_length change on FileField

[Django]

#25866: Django migrations not picking up max_length change on FileField
-+-
 Reporter:  gabn88   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by gabn88:

Old description:

> I have subclassed a FileField (call it S3storage) which first had no
> max_length
>
> Now I changed max_length to 1000. Then running ./manage.py makemigrations
> it does not seems to be picked up.
>
> The only thing I did was:
>
> class S3FileField(models.FileField):
> def __init__(self, *args, **kwargs):
> super(S3PrivateFileField, self).__init__(*args, **kwargs)
> self.storage.default_acl = "private"

New description:

 I have subclassed a FileField (call it S3storage) which first had no
 max_length

 Now I changed max_length to 1000. Then running ./manage.py makemigrations
 it does not seems to be picked up.

 The only thing I did was:
 {{
 class S3FileField(models.FileField):
 def __init__(self, *args, **kwargs):
 super(S3PrivateFileField, self).__init__(*args, **kwargs)
 self.storage.default_acl = "private"
 }}

--

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

Re: [Django] #25866: Django migrations not picking up max_length change on FileField

[Django]

#25866: Django migrations not picking up max_length change on FileField
-+-
 Reporter:  gabn88   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by bmispelon):

 Hi,

 What you're describing seems to work for me (Django detects the change and
 writes a migration).

 Could you show the full code of your model and custom field?

 Thanks.

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

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

Re: [Django] #25866: Django migrations not picking up max_length change on FileField

[Django]

#25866: Django migrations not picking up max_length change on FileField
-+-
 Reporter:  gabn88   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by gabn88):

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


Old description:

> I have a FileField which first had no max_length
>
> Now I changed max_length to 1000. Then running ./manage.py makemigrations
> it does not seems to be picked up

New description:

 I have subclassed a FileField (call it S3storage) which first had no
 max_length

 Now I changed max_length to 1000. Then running ./manage.py makemigrations
 it does not seems to be picked up.

 The only thing I did was:

 class S3FileField(models.FileField):
 def __init__(self, *args, **kwargs):
 super(S3PrivateFileField, self).__init__(*args, **kwargs)
 self.storage.default_acl = "private"

--

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

[Django] #25866: Django migrations not picking up max_length change on FileField

[Django]

#25866: Django migrations not picking up max_length change on FileField
--+
 Reporter:  gabn88|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 I have a FileField which first had no max_length

 Now I changed max_length to 1000. Then running ./manage.py makemigrations
 it does not seems to be picked up

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

Re: [Django] #25865: OSMGeoAdmin should require GDAL only if model has fields with SRID that differs from map srid

[Django]

#25865: OSMGeoAdmin should require GDAL only if model has fields with SRID that
differs from map srid
---+--
 Reporter:  sir-sigurd |Owner:  sir-sigurd
 Type:  Uncategorized  |   Status:  assigned
Component:  GIS|  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by sir-sigurd):

 * has_patch:  0 => 1


Comment:

 PR -- https://github.com/django/django/pull/5770

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

Re: [Django] #25845: False timezone offset warnings in admin if a custom base template doesn't set data-admin-utc-offset

[Django]

#25845: False timezone offset warnings in admin if a custom base template 
doesn't
set data-admin-utc-offset
---+
 Reporter:  Strayer|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.9
 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 emre):

 PR provided on github:
 https://github.com/django/django/pull/5769

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

Re: [Django] #25853: add support for GeoHash GIS function on SpatiaLite backend

[Django]

#25853: add support for GeoHash GIS function on SpatiaLite backend
-+-
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"25f5b5c19dc23c6c09877c9c652a934e9669573d" 25f5b5c1]:
 {{{
 #!CommitTicketReference repository=""
 revision="25f5b5c19dc23c6c09877c9c652a934e9669573d"
 Fixed #25853 -- Added support for GeoHash function on SpatiaLite.
 }}}

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

Re: [Django] #13774: Add model Field.rel_db_type() method

[Django]

#13774: Add model Field.rel_db_type() method
-+-
 Reporter:  Suor |Owner:  Suor
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db, ForeignKey,  | Triage Stage:  Accepted
  related fields |
Has patch:  1|  Needs documentation:  1
  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:"b61eab18f71f3afb36b3e8cb208a145046b3d8f6" b61eab18]:
 {{{
 #!CommitTicketReference repository=""
 revision="b61eab18f71f3afb36b3e8cb208a145046b3d8f6"
 Fixed #13774 -- Added models.Field.rel_db_type().
 }}}

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

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

Re: [Django] #25855: Improve runserver migration notification output.

[Django]

#25855: Improve runserver migration notification output.
-+-
 Reporter:  kezabelle|Owner:  emre
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 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 emre):

 * owner:  nobody => emre
 * status:  new => assigned


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

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

Re: [Django] #25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9

[Django]

#25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9
---+--
 Reporter:  stephanm   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.9
 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 timgraham):

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

Re: [Django] #25734: Nodata value not excluded when computing GDALBand min/max values

[Django]

#25734: Nodata value not excluded when computing GDALBand min/max values
-+-
 Reporter:  yellowcap|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  raster gdal gis  | 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 timgraham):

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


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

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

Re: [Django] #25734: Nodata value not excluded when computing GDALBand min/max values

[Django]

#25734: Nodata value not excluded when computing GDALBand min/max values
-+-
 Reporter:  yellowcap|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis  | 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:"0e7d59df3ed6988cd5a45e26414c013ad40c7402" 0e7d59d]:
 {{{
 #!CommitTicketReference repository=""
 revision="0e7d59df3ed6988cd5a45e26414c013ad40c7402"
 Refs #25734 -- Relaxed GDALRaster statistics test to use
 assertAlmostEqual.

 Some versions of GDAL give slightly different results.
 }}}

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

Re: [Django] #25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9

[Django]

#25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9
---+--
 Reporter:  stephanm   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.9
 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 stephanm):

 I tried but I didn't get it :-(

 Actually I use the following workaround:
 {{{#!py
 # at the beginning of the file before the first import:
 if __name__ == "__main__":
 import django
 django.setup()
 # now the imports ...
 from myapp.models import MyModel1 # here is the exception
 ...
 if __name__ == "__main__":
 # skipped here ...
 #import django
 #django.setup()
 # my code follows
 }}}

 I can live with this so you can close the ticket it if you like,
 if I find a way to reproduce it in a simple "example" I will open it
 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/066.0470383a1d136f1fbd957d089f44d0b1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25860: Test setup error: Cannot operate on a closed database

[Django]

#25860: Test setup error: Cannot operate on a closed database
---+--
 Reporter:  jonashaag  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  regression | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by jonashaag):

 From the Python docs:

  If an exception is raised during a setUpClass then the tests in the class
 are not run **and the tearDownClass is not run**. Skipped classes will not
 have setUpClass or tearDownClass run. If the exception is a SkipTest
 exception then the class will be reported as having been skipped instead
 of as an error.

 Looks like nothing's wrong with Django 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/067.0c05b27834fcd95cc49c5aa412d997e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9

[Django]

#25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9
---+--
 Reporter:  stephanm   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.9
 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 bmispelon):

 Hi,

 We can't really reproduce your issue without the definition of your
 models.
 Is there a way you could provide them (ideally, a simplified version that
 still reproduces the issue).

 Thanks.

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

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

Re: [Django] #25860: Test setup error: Cannot operate on a closed database

[Django]

#25860: Test setup error: Cannot operate on a closed database
---+--
 Reporter:  jonashaag  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  regression | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by jonashaag):

 I agree with carljm.

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

Re: [Django] #25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9

[Django]

#25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9
---+--
 Reporter:  stephanm   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.9
 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 stephanm):

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


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

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

[Django] #25865: OSMGeoAdmin should require GDAL only if model has fields with SRID that differs from map srid

[Django]

#25865: OSMGeoAdmin should require GDAL only if model has fields with SRID that
differs from map srid
---+
 Reporter:  sir-sigurd |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  GIS|Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  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/053.52e7590fb0e58ed229cb6d1ccab6dc8e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25865: OSMGeoAdmin should require GDAL only if model has fields with SRID that differs from map srid

[Django]

#25865: OSMGeoAdmin should require GDAL only if model has fields with SRID that
differs from map srid
---+--
 Reporter:  sir-sigurd |Owner:  sir-sigurd
 Type:  Uncategorized  |   Status:  assigned
Component:  GIS|  Version:  1.9
 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 sir-sigurd):

 * status:  new => assigned
 * needs_docs:   => 0
 * owner:  nobody => sir-sigurd
 * needs_tests:   => 0
 * needs_better_patch:   => 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/068.1401b2e2c2f01d4db8444af8d93bb894%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9

[Django]

#25864: AppRegistryNotReady exception since update from 1.8.7 to 1.9
---+
 Reporter:  stephanm   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hi,

 I have a script which worked in django 1.8
 but does no more in django 1.9, I get the exception:
 {{{django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet}}}

 Unfortunately I didn't find a hint in the release notes

 {{{#!py
 from myapp.models import MyModel1 # here is the exception
 ...
 if __name__ == "__main__":

 import django
 django.setup()
 # my code follows
 }}}

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

Re: [Django] #25862: AttributeError: 'FileSystemStorage' object has no attribute 'location'

[Django]

#25862: AttributeError: 'FileSystemStorage' object has no attribute 'location'
--+--
 Reporter:  codingjoe |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by codingjoe):

 * resolution:  worksforme => fixed


Comment:

 I found the bug. It's the lazy object implementation of the default
 storage. It doesn't work in python 2 using multiprocessing.

 This little snippet allows to produce the error.
 {{{
 def has_location(storage):
 return hasattr(storage, 'location')


 def test_multiprocessing_lazy_objects(image_upload_file):
 SimpleModel.objects.create(image=image_upload_file)
 obj = SimpleModel.objects.last()
 storage = obj.image.storage

 p = Pool(2)
 assert all(p.map(has_location, [default_storage, storage]))
 }}}

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

Re: [Django] #25862: AttributeError: 'FileSystemStorage' object has no attribute 'location'

[Django]

#25862: AttributeError: 'FileSystemStorage' object has no attribute 'location'
--+--
 Reporter:  codingjoe |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by codingjoe):

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


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

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

Re: [Django] #25855: Improve runserver migration notification output.

[Django]

#25855: Improve runserver migration notification output.
-+-
 Reporter:  kezabelle|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 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 emre):

 * Attachment "0001-Fixed-25855-Added-more-accurate-info-to-migration.diff"
 added.

 Patch for ticket #25855

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

Re: [Django] #25699: Allow using test client session handling with custom session apps

[Django]

#25699: Allow using test client session handling with custom session apps
-+-
 Reporter:  sergeykolosov|Owner:
 |  sergeykolosov
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by javins):

 * cc: walt@… (added)


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

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

Re: [Django] #25862: AttributeError: 'FileSystemStorage' object has no attribute 'location'

[Django]

#25862: AttributeError: 'FileSystemStorage' object has no attribute 'location'
--+--
 Reporter:  codingjoe |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  worksforme
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by codingjoe):

 Let me try to convince you then. I just [changed](https://travis-
 ci.org/codingjoe/django-stdimage/jobs/94828152) it to the
 [documented](https://docs.djangoproject.com/en/1.8/topics/files/#storage-
 objects) `default_storage` helper, which is nothing other than
 `DefaultStorage()`.

 I also just added a little test, that tests only storage.location. That
 works, that doesn't mean there isn't a problem tho.
 See the tests don't even execute the case with a default storage.
 It uses the `FieldFile`'s storage.

 Besides all that, I don't do any wizardry with the storages, nor in the
 settings. It must strike you, that there is a different behavior on python
 2.7 and  3.*

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

Re: [Django] #25677: compilemessages throws an exception and does not report msgformat errors correctly

[Django]

#25677: compilemessages throws an exception and does not report msgformat errors
correctly
-+-
 Reporter:  gavinwahl|Owner:  Claude
 |  Paroz 
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 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 claudep):

 I was able to reproduce that on Linux with gettext 0.18.1. I guess that
 python-brace-format is a "recent" gettext addition. A solution might be to
 simply skip `test_msgfmt_error_including_non_ascii` with older gettext
 versions. Not sure if that fixes all failures.

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

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

Re: [Django] #25855: Improve runserver migration notification output.

[Django]

#25855: Improve runserver migration notification output.
-+-
 Reporter:  kezabelle|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  master
  commands)  |
 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 emre):

 * Attachment "0001-Fixed-25855-Added-more-accurate-info-to-migration.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.47282dc5ce07f1ab7b71933d27dfadb7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25677: compilemessages throws an exception and does not report msgformat errors correctly

[Django]

#25677: compilemessages throws an exception and does not report msgformat errors
correctly
-+-
 Reporter:  gavinwahl|Owner:  Claude
 |  Paroz 
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 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 claudep):

 Are you able to install a more recent gettext on Windows to see if it's
 gettext-related?

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

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

Re: [Django] #25862: AttributeError: 'FileSystemStorage' object has no attribute 'location'

[Django]

#25862: AttributeError: 'FileSystemStorage' object has no attribute 'location'
--+--
 Reporter:  codingjoe |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:  worksforme
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by claudep):

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


Comment:

 Creating a storage instance as a function parameter ((`DefaultStorage()`
 for render_variations) looks a bit suspicious to me. I'm not convinced the
 problem is on Django's side.

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

Re: [Django] #25734: Nodata value not excluded when computing GDALBand min/max values

[Django]

#25734: Nodata value not excluded when computing GDALBand min/max values
-+-
 Reporter:  yellowcap|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis  | 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 yellowcap):

 No that's fine, its good to go for me as well.

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

Re: [Django] #25863: RenameModel migration does not rename indexes, subsequent index creation fails

[Django]

#25863: RenameModel migration does not rename indexes, subsequent index creation
fails
-+--
 Reporter:  jbaum-cmcrc  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.9
 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 jbaum-cmcrc):

 Hmm, I'm sure it's a regression, but (on checking more carefully) it's not
 demonstrated by my steps-to-reproduce...

 I have a project where the tests pass in 1.8 and fail with this error in
 1.9.

 However, now that I check more carefully, following my steps-to-reproduce
 in 1.8 also gives the error.

 I'll have to have another check on the regression aspect on Monday.

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

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