[Django] #23769: String with unicode is not passed to template from a view

[Django]

#23769: String with unicode is not passed to template from a view
-+---
 Reporter:  ajinabraham  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.7
 Severity:  Normal   |   Keywords:  unicode, encoding
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+---
 When a string that contains some unicode symbols is passed from a view to
 a template. The whole data get ignored and won't get rendered in the
 template.

 A quick fix is to decode to 'windows-1252' and then encode to 'utf8'
 example:
 # x is a string that contain unicode like "«»"
 x=x.decode("windows-1252").encode("utf8")

 It's better to be handled internally than a user doing it, else there
 should be some errors mentioning the issue rather than just ignoring the
 whole data.

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

Re: [Django] #23769: String with unicode is not passed to template from a view

[Django]

#23769: String with unicode is not passed to template from a view
---+--
 Reporter:  ajinabraham|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Template system|  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  unicode, encoding  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by ajinabraham):

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

[Django] #23768: Rewrite template_tag.tests.TemplateTests as individual test cases

[Django]

#23768: Rewrite template_tag.tests.TemplateTests as individual test cases
--+
 Reporter:  prestontimmons|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Template system   |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There are some downsides to the current format of the template tests:

 * It's impossible to use `--failfast`
 * All errors are lumped into a single failure. When working on the
 template code, a small problem can result in hundreds of errors worth of
 output.
 * When there is an error, the output isn't helpful since the test cases
 themselves are difficult to read.

 I think it would be an improvement if each template tag had it's own test
 case with each line as a separate test method.

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

Re: [Django] #15053: Make templates more reusable by Improving template loading algorithm to avoid extending infinite recursion

[Django]

#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+
 Reporter:  pmartin  |Owner:  unaizalakain
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 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 prestontimmons):

 I added a new pull request for this feature here:

 https://github.com/django/django/pull/3475/

 The approach I took is most similar to the one take by django-overextends,
 except this one doesn't unravel the cached loader.

 Any feedback is appreciated.

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

[Django] #23767: Add setting to toggle timezone warnings in Django admin (1.7+)

[Django]

#23767: Add setting to toggle timezone warnings in Django admin (1.7+)
---+
 Reporter:  fangsterr  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  1
---+
 Starting with Django 1.7, the admin interface automatically displays a
 warning if the browser timezone differs from the server timezone
 
(https://github.com/django/django/blob/master/django/contrib/admin/static/admin/js/admin/DateTimeShortcuts.js#L63).
 However, there are cases, especially with TimeFields, where the time is
 not stored based on server time, so it doesn't make sense to show the
 warning in those cases.

 Easy request:
 It'd be nice to have a setting that toggles the entire warning display
 on/off.

 Harder request:
 Per-field parameter to specify whether or not to display warning or not.

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

[Django] #23766: Documentation and tests for cursor.callproc()

[Django]

#23766: Documentation and tests for cursor.callproc()
-+-
   Reporter:  shaib  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |Version:  master
  Component:  Database   |   Keywords:
  layer (models, ORM)|  Has patch:  0
   Severity:  Normal |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 This is a spin off #23546 -- actually, a requirement for that ticket.

 Quoting my [https://groups.google.com/d/msg/django-
 developers/v3AhQhJFhGM/TScISVjLBQoJ message] to -developers on the subject
 (the thread trails off to discussions of higher-level interfaces, but the
 following seems to be in consensus):

 For a very long time -- as far as I'm aware, forever -- we've had, in our
 cursor classes, a `callproc()` method that follows the `callproc()`
 definition of [http://legacy.python.org/dev/peps/pep-0249/#callproc
 pep249]; this allows database stored procedures to be called.

 Recently [...] we found that
   1. `cursor.callproc()` is not documented
   2. `cursor.callproc()` is not tested (except for one Oracle-specific
 test that uses it to test something else)

 Which means, essentially, that it is treated as an intenal API.

 I see no reason that we shouldn't make it public.

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

Re: [Django] #23761: Mysql validator crashes with None db_type return. - Backport of master fix to 1.7

[Django]

#23761: Mysql validator crashes with None db_type return. - Backport of master 
fix
to 1.7
--+
 Reporter:  adepue|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (System checks)  |  Version:  1.7
 Severity:  Release blocker   |   Resolution:
 Keywords:  mysql db_type | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by adepue):

 PR is updated to include mention in release notes as well as a regression
 test.
 Updated PR here:
 https://github.com/django/django/pull/3472

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

Re: [Django] #19159: loaddata reports DeserializationError instead of MemoryError

[Django]

#19159: loaddata reports DeserializationError instead of MemoryError
--+
 Reporter:  django@…  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Serialization)  |  Version:  1.4
 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 berkerpeksag):

 `json.Deserializer` now uses `six.reraise` (see #18003). I think there are
 two questions that needs to be answered here:

 1. Should `DeserializationError` wrap `MemoryError`? If not, we need a
 patch to catch `MemoryError` explicitly.
 2. If yes, the ticket's title and description should be updated.

 See also #12007.

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

[Django] #23765: Get rid of system check 1_6.W002

[Django]

#23765: Get rid of system check 1_6.W002
--+
 Reporter:  marfire   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Core (System checks)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 System check `1_6.W001` was recently removed (#23469); `1_6.W002` has the
 same problems, and more, so I propose it be removed as well.

 There is a serious false positive problem here (where I define a false
 positive as something that makes you take time to think and care about
 something you don't need to think or care about). For this warning to
 actually help you, you must meet the following conditions: you haven't
 read the release notes; you're upgrading from a pre-1.6 version; you're
 using `BooleanFields` without a default; and you're nevertheless relying
 on the default value to be `False`. I don't have any hard numbers, of
 course, but I suspect this represents a small and dwindling proportion of
 users.

 Another problem with this is that the most straightforward solution (and
 the one hinted at by the warning message) is to go around and add defaults
 to all your `BooleanFields`. That is, in general, a mistake. Unless you
 actually want there to be a default, adding one harms your ability to
 detect bugs through model and form validation.

 Since `1_6.W001` is being removed in 1.8, that seems reasonable here as
 well. In both cases, though, it seems like these warnings should have been
 added to the `SILENCED_SYSTEM_CHECKS` setting in the default project
 template for new projects. That could certainly be done in the next 1.7
 release.

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

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

Re: [Django] #18716: Add a new ``docs`` management command that loads up the docs in a webbrowser

[Django]

#18716: Add a new ``docs`` management command that loads up the docs in a
webbrowser
-+-
 Reporter:  Alex |Owner:  roguelynn
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by berkerpeksag):

 Is this still wanted? This can be implemented as a custom management
 command in your project. I don't think it's worth adding it to Django
 Core.

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

[Django] #23764: sessions.backends.cache.SessionStore does not respect settings.SESSION_SERIALIZER

[Django]

#23764: sessions.backends.cache.SessionStore does not respect
settings.SESSION_SERIALIZER
--+--
 Reporter:  coagulant |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  contrib.sessions  |Version:  1.7
 Severity:  Normal|   Keywords:  pickle json sessions
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 According to [https://docs.djangoproject.com/en/1.6/topics/http/sessions
 /#session-serialization Session serialization docs], `SESSION_SERIALIZER`
 setting, introduced in 1.5.3, allows to customize how session data is
 stored. `JSONSerializer` is used as default since 1.6.

 All session backends honor this setting, except for
 `sessions.backends.cache.SessionStore`, which still uses pickle as
 serialization format (not directly, but via cache backend).
 It should be documented that cache store ignores this setting or
 SessionStore should be modified to support it.

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

Re: [Django] #23741: [System Check for migrations] Check presence of all foreign keys

[Django]

#23741: [System Check for migrations] Check presence of all foreign keys
--+
 Reporter:  notsqrt   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  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
--+

Comment (by timgraham):

 Sounds reasonable -- do you think you can work up a patch with tests?

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

Re: [Django] #23741: [System Check for migrations] Check presence of all foreign keys

[Django]

#23741: [System Check for migrations] Check presence of all foreign keys
--+
 Reporter:  notsqrt   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  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
--+

Comment (by notsqrt):

 Using Error is a little too strict, Warning should be enough.

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

Re: [Django] #21429: BaseCommand should use logging instead of custom output wrappers

[Django]

#21429: BaseCommand should use logging instead of custom output wrappers
-+-
 Reporter:  Nical|Owner:
 Type:  New feature  |  berkerpeksag
Component:  Core (Management |   Status:  assigned
  commands)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  command output   | Triage Stage:  Accepted
  logger |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by berkerpeksag):

 > Or did you intend to deprecate self.stdout/self.stderr?

 Yes, but I couldn't find a simple way to deprecate them yesterday. Today,
 here is my approach:
 
https://github.com/berkerpeksag/django/commit/b439b472842bfd2d04c36b28d079a80fac5814bb

 PR updated to address Simon's comments.

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

Re: [Django] #16501: Add option to accept unicode characters in SlugField (was: validators.py don't like unicode slug)

[Django]

#16501: Add option to accept unicode characters in SlugField
---+
 Reporter:  norn   |Owner:  pbnan
 Type:  New feature|   Status:  new
Component:  Core (Other)   |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords:  unicode, slug  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
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/062.21357cace3198ef3171ca241d1815244%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23763: Python 3.5 compatibility

[Django]

#23763: Python 3.5 compatibility
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timgraham):

 All the tests currently pass except for some `ImportError` exceptions
 being reported, likely due to http://bugs.python.org/issue7559.
 {{{
 ==
 ERROR: apps.failing_app (unittest.loader.ModuleImportFailure)
 --
 Traceback (most recent call last):
   File "/home/tim/code/cpython/Lib/unittest/case.py", line 58, in
 testPartExecutor
 yield
   File "/home/tim/code/cpython/Lib/unittest/case.py", line 577, in run
 testMethod()
   File "/home/tim/code/cpython/Lib/unittest/loader.py", line 36, in
 testFailure
 raise exception
 ImportError: Failed to import test module: apps.failing_app
 Traceback (most recent call last):
   File "/home/tim/code/cpython/Lib/unittest/loader.py", line 451, in
 _find_test_path
 package = self._get_module_from_name(name)
   File "/home/tim/code/cpython/Lib/unittest/loader.py", line 358, in
 _get_module_from_name
 __import__(name)
   File "/home/tim/code/django/tests/apps/failing_app/__init__.py", line 1,
 in 
 raise ImportError("Oops")
 ImportError: Oops


 ==
 ERROR: migrations.faulty_migrations.import_error
 (unittest.loader.ModuleImportFailure)
 --
 Traceback (most recent call last):
   File "/home/tim/code/cpython/Lib/unittest/case.py", line 58, in
 testPartExecutor
 yield
   File "/home/tim/code/cpython/Lib/unittest/case.py", line 577, in run
 testMethod()
   File "/home/tim/code/cpython/Lib/unittest/loader.py", line 36, in
 testFailure
 raise exception
 ImportError: Failed to import test module:
 migrations.faulty_migrations.import_error
 Traceback (most recent call last):
   File "/home/tim/code/cpython/Lib/unittest/loader.py", line 451, in
 _find_test_path
 package = self._get_module_from_name(name)
   File "/home/tim/code/cpython/Lib/unittest/loader.py", line 358, in
 _get_module_from_name
 __import__(name)
   File
 
"/home/tim/code/django/tests/migrations/faulty_migrations/import_error/__init__.py",
 line 1, in 
 import fake_python_module  # NOQA
 ImportError: No module named 'fake_python_module'
 }}}
 Also, some GIS related exceptions like the following if GIS dependencies
 aren't installed:
 {{{
 ==
 ERROR: django.contrib.gis.admin (unittest.loader.ModuleImportFailure)
 --
 Traceback (most recent call last):
   File "/home/tim/code/cpython/Lib/unittest/case.py", line 58, in
 testPartExecutor
 yield
   File "/home/tim/code/cpython/Lib/unittest/case.py", line 577, in run
 testMethod()
   File "/home/tim/code/cpython/Lib/unittest/loader.py", line 36, in
 testFailure
 raise exception
 ImportError: Failed to import test module: django.contrib.gis.admin
 Traceback (most recent call last):
   File "/home/tim/code/cpython/Lib/unittest/loader.py", line 451, in
 _find_test_path
 package = self._get_module_from_name(name)
   File "/home/tim/code/cpython/Lib/unittest/loader.py", line 358, in
 _get_module_from_name
 __import__(name)
   File "/home/tim/code/django/django/contrib/gis/admin/__init__.py", line
 7, in 
 from django.contrib.gis.admin.options import GeoModelAdmin  # NOQA
   File "/home/tim/code/django/django/contrib/gis/admin/options.py", line
 2, in 
 from django.contrib.gis.admin.widgets import OpenLayersWidget
   File "/home/tim/code/django/django/contrib/gis/admin/widgets.py", line
 9, in 
 from django.contrib.gis.geos import GEOSGeometry, GEOSException
 ImportError: cannot import name 'GEOSGeometry'
 }}}

--
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 visi

Re: [Django] #23763: Python 3.5 compatibility

[Django]

#23763: Python 3.5 compatibility
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"b07aa52e8a8e4c7fdc7265f75ce2e7992e657ae9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b07aa52e8a8e4c7fdc7265f75ce2e7992e657ae9"
 Added a dummy class for HTMLParserError; refs #23763.
 }}}

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

[Django] #23763: Python 3.5 compatibility

[Django]

#23763: Python 3.5 compatibility
+
   Reporter:  timgraham |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  Core (Other)  |Version:  master
   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 |
+
 Python 3.5 is not scheduled for final until September 2015, but this is a
 tracking ticket for compatibility fixes for Django submitted in the
 meantime.

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

Re: [Django] #23763: Python 3.5 compatibility

[Django]

#23763: Python 3.5 compatibility
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by berkerpeksag):

 * cc: berker.peksag@… (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.77a1063c00e504ff50936932a181b542%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23762: CACHE_MIDDLEWARE_ANONYMOUS_ONLY deprecation period was only partial

[Django]

#23762: CACHE_MIDDLEWARE_ANONYMOUS_ONLY deprecation period was only partial
---+
 Reporter:  kezabelle  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by timgraham):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * 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.a76ef3b2a046d7b10e94806ea4e7b27a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23750: django.core.checks.register shouldn't be (primarily) a decorator

[Django]

#23750: django.core.checks.register shouldn't be (primarily) a decorator
-+-
 Reporter:  shaib|Owner:
 Type:   |  averybigant
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  1.7
  checks)|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 I left comments for improvement on the PR. Please uncheck "Patch needs
 improvement" when you update it, 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/063.89dfb0f06ee62f054c48e2d1580aa960%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21608: Logged out sessions are resurrected by concurrent requests

[Django]

#21608: Logged out sessions are resurrected by concurrent requests
--+-
 Reporter:  jonasborgstrom|Owner:  anonymous
 Type:  Bug   |   Status:  assigned
Component:  contrib.sessions  |  Version:  1.4
 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 jonasborgstrom):

 I think one key detail missing from the initial reproduction steps is that
 the "slow page" needs to modify the session to make it dirty. Otherwise
 the session will not be resurrected.

 Anyway, I've now create a complete reproduction test case here:
 https://github.com/jborg/django-21608

 See README.txt for details.

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

[Django] #23762: CACHE_MIDDLEWARE_ANONYMOUS_ONLY deprecation period was only partial

[Django]

#23762: CACHE_MIDDLEWARE_ANONYMOUS_ONLY deprecation period was only partial
---+
 Reporter:  kezabelle  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 As far as I can tell, the standard 2-versions deprecation policy was only
 partially implemented for the `CACHE_MIDDLEWARE_ANONYMOUS_ONLY` setting,
 because as of Django 1.7.1, the deprecation warning is only applied to
 
[https://github.com/django/django/blob/c5780adeecfbd85a80b5aa7130dd86e78b23e497/django/middleware/cache.py#L167
 CacheMiddleware], which is in contrast to how the documentation has
 
[https://github.com/django/django/blob/c5780adeecfbd85a80b5aa7130dd86e78b23e497/docs/topics/cache.txt#L437
 recommended using the two partial Middlewares] for a long time, due to the
 way MIDDLEWARE_CLASSES is applied in different orders depending on the
 point in the request/response cycle.

 As it's already gone in 1.8, the best course of action would be improve
 the [https://docs.djangoproject.com/en/dev/internals/deprecation
 /#deprecation-removed-in-1-8 deprecation notes for 1.8] in a way that
 really calls attention to this omission (rather than the one-line bullet
 point it currently receieves), as well as add some sort of notification to
 [https://docs.djangoproject.com/en/dev/releases/1.8/ the release notes],
 lest it be missed - failure to do so would lead to many people wondering
 why the setting doesn't work anymore [for which the answer needs to be
 "read #15201"]

 Meanwhile, while asking about making this ticket vs. re-opening #15201 in
 #django-dev, MarkusH suggested that the
 
[https://github.com/django/django/blob/c5780adeecfbd85a80b5aa7130dd86e78b23e497/django/middleware/cache.py#L206
 stack level for the warning should be 2, not 1].

 Marking as master (current 1.8) for the purposes of updating the
 documentation, though the missing warning can only apply as far as 1.7

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