Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

2018-01-15 Thread Django 
#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ErikW):

 I like Matthew's idea of reusing Subquery as the basis for CTEs since
 behind the scenes CTEs are really just syntactic sugar for Subqueries.
 I'd just like to add that being able to pull multiple values/aggregates
 from the Subquery/CTE would really push this over the top as a huge
 performance boost for complex analytical queries.

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

[Django] #29026: Make makemigrations scriptable / script-friendly

2018-01-15 Thread Django 
#29026: Make makemigrations scriptable / script-friendly
-+-
   Reporter:  Chris  |  Owner:  nobody
  Jerdonek   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  master
  Migrations |   Keywords:
   Severity:  Normal |  makemigrations,scripting,stderr,stdout
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently, the `makemigrations` management command doesn't lend itself
 well to scripting. For example, it writes its progress output to `stdout`
 rather than `stderr`. Also, there doesn't appear to be a structured /
 programmatic way to figure out what files it has created.

 My use case is that in my development environment, I'd like to be able to
 run `makemigrations` in a Docker container, find out what files were added
 (e.g. from `makemigrations`'s output), and then copy those files from the
 Docker container to my development machine so they can be added to source
 control.

 Currently, there doesn't seem to be an easy way to do this. One way, for
 example, is to manually read `makemigrations`'s output to find out what
 apps were affected, and then inspect the directories yourself for the new
 files.

 Better, for example, would be if `makemigrations` could write the paths to
 the created files to `stdout`.

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

Re: [Django] #29024: `TestContextDecorator` never exits if `setUp` fails in tests

2018-01-15 Thread Django 
#29024: `TestContextDecorator` never exits if `setUp` fails in tests
-+-
 Reporter:  Anthony King |Owner:  Shahbaj
 |  Sayyad
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  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 Shahbaj Sayyad):

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

Re: [Django] #29025: Security middleware for insecure (HTTP) connections

2018-01-15 Thread Django 
#29025: Security middleware for insecure (HTTP) connections
+--
 Reporter:  Vishwas Mittal  |Owner:  Vishwas Mittal
 Type:  New feature |   Status:  assigned
Component:  HTTP handling   |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Vishwas Mittal):

 Replying to [comment:2 Aymeric Augustin]:
 > Why should Django reinvent HTTPS instead of simply recommend to use it?
 Sometimes many users (including me) uses their Django server on the
 computer only (for local networks) this can pose some problem of security
 and sometimes for some servers (say for non-commercial purposes) the
 server can be HTTP.

 Here I am not saying to use it every time, there can be a check if the
 network is not HTTPS then we can use it's protection else just bypass 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/067.0fda11373243109788a6f382281bf25e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29025: Security middleware for insecure (HTTP) connections

2018-01-15 Thread Django 
#29025: Security middleware for insecure (HTTP) connections
+--
 Reporter:  Vishwas Mittal  |Owner:  Vishwas Mittal
 Type:  New feature |   Status:  assigned
Component:  HTTP handling   |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Aymeric Augustin):

 Why should Django reinvent HTTPS instead of simply recommend to use 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/067.5e6ca2699be2b96603a65051afed6a89%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #2259: Primary keys should be readonly by default in admin

2018-01-15 Thread Django 
#2259: Primary keys should be readonly by default in admin
-+-
 Reporter:  ed@… |Owner:  Pathangi
 |  Jatinshravan
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  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 Pathangi Jatinshravan):

 * owner:  (none) => Pathangi Jatinshravan
 * 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/072.fb57dfd5dfe565986cda9f6574ab8cf5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29025: Security middleware for insecure (HTTP) connections

2018-01-15 Thread Django 
#29025: Security middleware for insecure (HTTP) connections
+--
 Reporter:  Vishwas Mittal  |Owner:  Vishwas Mittal
 Type:  New feature |   Status:  assigned
Component:  HTTP handling   |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Vishwas Mittal):

 * owner:  nobody => Vishwas Mittal


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

[Django] #29025: Security middleware for insecure (HTTP) connections

2018-01-15 Thread Django 
#29025: Security middleware for insecure (HTTP) connections
--+--
   Reporter:  Vishwas Mittal  |  Owner:  nobody
   Type:  New feature | Status:  assigned
  Component:  HTTP handling   |Version:  2.0
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
 Hello everyone,

 I am starting my contribution to Django and I would like to propose a
 security middleware that can provide some layer of security even in HTTP
 connections by encrypting the request and response.

 Here I will implement an SSL type feature in the backend and will also
 provide a corresponding frontend implementation that can be used to
 complete the encryption-decryption couple.

 Please share your thoughts and valuable suggestions, I will appreciate any
 type of help I can get from you.

 P.S. This is just a brief intro about the feature, if you like this and
 feels something achievable then we can discuss it in detail.

 Regards
 Vishwas

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

Re: [Django] #29024: `TestContextDecorator` never exits if `setUp` fails in tests

2018-01-15 Thread Django 
#29024: `TestContextDecorator` never exits if `setUp` fails in tests
---+
 Reporter:  Anthony King   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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 Simon Charette):

 * version:  1.11 => master
 * stage:  Unreviewed => Accepted


Comment:

 Using `addCleanup` instead of hooking up on `tearDown` makes sense 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.2cb238d389294ac7250505e7a7ac1823%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29024: `TestContextDecorator` never exits if `setUp` fails in tests

2018-01-15 Thread Django 
#29024: `TestContextDecorator` never exits if `setUp` fails in tests
-+
   Reporter:  Anthony King   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  1.11
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 when using `TestContextDecorator` as a class decorator, `enable` is called
 just before `Test.setUp`, and `disable` is called after `Test.tearDown`.

 unfortunately, `tearDown` is not called in the event of a failure inside
 `setUp`. This can result in unexpected behaviour.

 Even though this class is not documented, there are decorators that use it
 that are.


 example:


 {{{#!python
 class example_decorator(TestContextDecorator):
 some_var = False

 def enable(self):
 self.__class__.some_var = True

 def disable(self):
 self.__class__.some_var = False

 class Example1TestCase(TestCase):
 def test_var_is_false(self):
 # some_var will be False
 self.assertFalse(example_decorator.some_var)


 @example_decorator()
 class Example2TestCase(TestCase):
 def setUp(self):
 raise Exception

 def test_var_is_true(self):
 # won't be hit due to exception in setUp
 self.assertTrue(example_decorator.some_var)


 class Example3TestCase(TestCase):
 def test_var_is_false(self):
 # some_var will be True now due to no cleanup in Example2TestCase
 self.assertFalse(example_decorator.some_var)

 }}}
 output:
 {{{
 .EF
 ==
 ERROR: test_var_is_true (sharefile.tests.Example2TestCase)
 --
 ... Traceback

 ==
 FAIL: test_var_is_false (sharefile.tests.Example3TestCase)
 --
 ...
 AssertionError: True is not false

 Ran 3 tests in 0.007s

 FAILED (failures=1, errors=1)
 }}}

 There are 2 potential fixes here:
 - decorate `setUpClass` and `tearDownClass`
 - use `addCleanup` inside the `setUp` decorator

 `addCleanup` will always run, and will only ever be registered if the
 context manager was successfully enabled.

 It would also be useful to have this class documented, however that's out
 of scope of this ticket.

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

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

Re: [Django] #29015: Add an error when the PostgreSQL database name length limit is exceeded

2018-01-15 Thread Django 
#29015: Add an error when the PostgreSQL database name length limit is exceeded
-+-
 Reporter:  Tadej Janež  |Owner:  Priyansh
 Type:   |  Saxena
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * cc: Adam (Chainz) Johnson (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/064.aeedcd23150ef81ab8b14fdfab8e873d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29023: running tests in parallel doesn't show exception chain, even with tblib (was: running tests in parallel doesn't show exception chain (even with tblib))

2018-01-15 Thread Django 
#29023: running tests in parallel doesn't show exception chain, even with tblib
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  parallel,exception,chain,traceback,pickling,tblib|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #29022: HashedFilesMixin does not properly skip protocol-relative urls

2018-01-15 Thread Django 
#29022: HashedFilesMixin does not properly skip protocol-relative urls
-+-
 Reporter:  Will Gulian  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 The code changed in 08ed3cc6d160d0d864ff687db9a62959a86e7372 so the
 comment is outdated but as far as I see, a URL starting with `//` would
 likely be filtered out in the next block: `if url.startswith('/') and not
 url.startswith(settings.STATIC_URL):`. Anyway, there's still a test
 assertion for `//foobar` remaining unchanged and I don't see a change to
 the URL you provided if I add that to the test. Can you find the
 difference between that test and your situation that reproduces the
 problem?

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

Re: [Django] #29023: running tests in parallel doesn't show exception chain (even with tblib)

2018-01-15 Thread Django 
#29023: running tests in parallel doesn't show exception chain (even with tblib)
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  parallel,exception,chain,traceback,pickling,tblib|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 > Side question: why must pickling be used at all? Why can't we simply
 render the traceback to a string using Python's traceback module, and then
 send the string back? It seems like that would result in simpler, more
 understandable code and sidestep many of the difficulties.

 From what I know It's just the default behavior of the `multiprocessing`
 module for  inter process exception bubbling. I feel like it's a bit
 harder than that as you still have to construct a `traceback` object from
 the string on the parent process side to raise the appropriate exception.

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

Re: [Django] #28977: Change Local Memory Cache to Use LRU

2018-01-15 Thread Django 
#28977: Change Local Memory Cache to Use LRU
-+-
 Reporter:  Grant Jenks  |Owner:  Grant
 |  Jenks
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache 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
-+-
Changes (by Tim Graham):

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


Comment:

 Some test coverage is missing as noted on the 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/068.b5fc6eafcbd463ce9210ecf42ab421ad%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25504: Django test teardown fails when there is no default database

2018-01-15 Thread Django 
#25504: Django test teardown fails when there is no default database
---+
 Reporter:  Sjoerd Langkemper  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  Testing framework  |  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
---+
Changes (by mihaicc):

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


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

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

Re: [Django] #28881: Document that CommonPasswordValidator assumes all words are lower case

2018-01-15 Thread Django 
#28881: Document that CommonPasswordValidator assumes all words are lower case
-+-
 Reporter:  Nick Farrell |Owner:  Karmen
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 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:"4fcd28d442c2fec56f544f99cb658f33f847824c" 4fcd28d]:
 {{{
 #!CommitTicketReference repository=""
 revision="4fcd28d442c2fec56f544f99cb658f33f847824c"
 Fixed #28881 -- Doc'd that CommonPasswordValidator's password list must be
 lowercase.
 }}}

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

Re: [Django] #28881: Document that CommonPasswordValidator assumes all words are lower case

2018-01-15 Thread Django 
#28881: Document that CommonPasswordValidator assumes all words are lower case
-+-
 Reporter:  Nick Farrell |Owner:  Karmen
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"146317b734275daddcc9b5e240b3c48b508fc6e6" 146317b7]:
 {{{
 #!CommitTicketReference repository=""
 revision="146317b734275daddcc9b5e240b3c48b508fc6e6"
 [2.0.x] Fixed #28881 -- Doc'd that CommonPasswordValidator's password list
 must be lowercase.

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

Re: [Django] #29023: running tests in parallel doesn't show exception chain (even with tblib)

2018-01-15 Thread Django 
#29023: running tests in parallel doesn't show exception chain (even with tblib)
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  parallel,exception,chain,traceback,pickling,tblib|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 One more thing to add: in the case where the full chain isn't being shown,
 there's also no way for the user to know that anything is missing (without
 also running in non-parallel mode and comparing the test outputs).

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

Re: [Django] #29023: running tests in parallel doesn't show exception chain (even with tblib)

2018-01-15 Thread Django 
#29023: running tests in parallel doesn't show exception chain (even with tblib)
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  parallel,exception,chain,traceback,pickling,tblib|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

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

[Django] #29023: running tests in parallel doesn't show exception chain (even with tblib)

2018-01-15 Thread Django 
#29023: running tests in parallel doesn't show exception chain (even with tblib)
-+-
   Reporter:  Chris  |  Owner:  nobody
  Jerdonek   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Testing|Version:  master
  framework  |   Keywords:
   Severity:  Normal |  
parallel,exception,chain,traceback,pickling,tblib
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Running tests in parallel doesn't show more than the first link of an
 exception chain. For example, with the following test (with `tblib`
 installed):

 {{{#!python
 def test(self):
 time.sleep(2)
 try:
 raise ValueError('foo')
 except Exception:
 raise KeyError('bar')
 }}}

 this is what the failure looks like when running tests in parallel:

 {{{
 Traceback (most recent call last):
   File "/Users/.../versions/3.6.4/lib/python3.6/unittest/case.py", line
 59, in testPartExecutor
 yield
   File "/Users/.../versions/3.6.4/lib/python3.6/unittest/case.py", line
 605, in run
 testMethod()
   File "/Users/.../myproject/myproject/tests/test_a.py", line 13, in test2
 raise KeyError('bar')
 KeyError: 'bar'
 }}}

 In contrast, this is what it looks like when running them not in parallel:

 {{{
 Traceback (most recent call last):
   File "/Users/.../myproject/myproject/tests/test_a.py", line 11, in test2
 raise ValueError('foo')
 ValueError: foo

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/Users/.../myproject/myproject/tests/test_a.py", line 13, in test2
 raise KeyError('bar')
 KeyError: 'bar'
 }}}

 Side question: why must pickling be used at all? Why can't we simply
 render the traceback to a string using Python's `traceback` module, and
 then send the string back? It seems like that would result in simpler,
 more understandable code and sidestep many of the difficulties.

 (This was reported using Python 3.6.4. and `master` as of Jan. 15, 2018:
 02365d3f38a64a5c2f3e932f23925a381d5bb151 .)

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

Re: [Django] #28403: Improve the example for FORMAT_MODULE_PATH and add missing formats

2018-01-15 Thread Django 
#28403: Improve the example for FORMAT_MODULE_PATH and add missing formats
-+-
 Reporter:  karyon   |Owner:  Ashaba
 Type:   |  John
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Patch seems good for adding the missing settings. We should probably take
 that.

 I'm not sure about the comment about re-using locale paths... (There is
 obviously some overlap between the two settings, but a clean up is a
 separate issue, maybe worth the effort or not.)

 @karyon: what's your thought on this now?

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

Re: [Django] #28881: Document that CommonPasswordValidator assumes all words are lower case

2018-01-15 Thread Django 
#28881: Document that CommonPasswordValidator assumes all words are lower case
-+-
 Reporter:  Nick Farrell |Owner:  Karmen
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 [https://github.com/django/django/pull/9586#pullrequestreview-88743187 PR]
 adds small doc fix.

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

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

Re: [Django] #28977: Change Local Memory Cache to Use LRU

2018-01-15 Thread Django 
#28977: Change Local Memory Cache to Use LRU
-+-
 Reporter:  Grant Jenks  |Owner:  Grant
 |  Jenks
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


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

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