Re: [Django] #21597: (2006, 'MySQL server has gone away') in django1.6 when wait_timeout passed

2014-02-11 Thread Django
#21597: (2006, 'MySQL server has gone away') in django1.6 when wait_timeout 
passed
-+-
 Reporter:  ekeydar@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  mysql|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by andreis):

 Hi Jeroen!
 It seems like adding CLIENT.INTERACTIVE flag just tells the driver to
 switch from checking on wait_timeout to taking interactive_timeout into
 account. I set interactive_timeout=10 and was able to reproduce this
 problem.
 Both of these values are 8 hours by default, but once your code has been
 inactive for that long, mysql drops the connection and the client fails
 next time it tries to access some data. It looks perfectly right to catch
 this error in the code, call django.db.close_connection() every time or
 whatever, but I think that maybe connection persistence logic needs a bit
 of fine-tuning so that we can control persistence without relying on
 signals.request_started/request_finished.

-- 
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/075.1eeb01f9757990eba69f4a85b53330e6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #22019: add section for definitive Model.objects documentation (was: add section for definitive Models.objects documentation)

2014-02-11 Thread Django
#22019: add section for definitive Model.objects documentation
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.6
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  models,objects   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by cjerdonek):

 * cc: chris.jerdonek@… (added)
 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 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/067.e2051c63ee9f248a073cb8c11b60d468%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #22019: add section for definitive Models.objects documentation

2014-02-11 Thread Django
#22019: add section for definitive Models.objects documentation
--+
 Reporter:  cjerdonek |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  1.6
 Severity:  Normal|   Keywords:  models,objects
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I can't seem to find the model class attribute `objects` documented in any
 of the [https://docs.djangoproject.com/en/dev/ref/models/ models reference
 sections].  In addition, there doesn't seem to be an obvious central place
 where `objects` is documented (and in particular, a clear place where the
 word "objects" can internally link to).  I think this place should be
 somewhere in the reference/API section.

 Currently, the most detailed documentation of `objects` seems to be
 [https://docs.djangoproject.com/en/dev/topics/db/queries/#retrieving-
 objects here], in the "Retrieving objects" subsection of the "Making
 queries" section of the introductory "Models and databases" topic section.
 However, `objects` is referred to much earlier than that, for example
 several times in the
 [https://docs.djangoproject.com/en/dev/topics/db/models/ previous "Models"
 section].

 My recommendations would be:

 * add to the Models reference a definitive section about the `objects`
 class attribute, and include there a hyperlink to the introductory section
 about `objects` that I mentioned above,
 * hyperlink the first mentions of `objects` in the models introductory
 sections to the definitive section, and
 * in particular, hyperlink the introductory section about `objects` to the
 definitive section.

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


Re: [Django] #16116: Compress cache data

2014-02-11 Thread Django
#16116: Compress cache data
-+-
 Reporter:  bjourne  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Cache system)  |  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by vhermecz):

 I strongly disagree with the reasons behind closing this request.
 While this could live in a 3rd party library, there is actually a
 memcached cache implementation withing django. And the project should
 maintain it if it is there.

 Regarding lucmult provided a nice patch, would be sweet to pull 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/065.52469b6ef29e1f54fca936613ff8e918%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #22017: RuntimeError: dictionary changed size during iteration

2014-02-11 Thread Django
#22017: RuntimeError: dictionary changed size during iteration
--+---
 Reporter:  quinox|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Python 3  |  Version:  1.7-alpha-1
 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 quinox):

 * cc: djangoproject.com@… (added)
 * needs_better_patch:   => 0
 * component:  Uncategorized => Python 3
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug


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


Re: [Django] #17942: JSONResponse class for API responses

2014-02-11 Thread Django
#17942: JSONResponse class for API responses
---+---
 Reporter:  leahculver |Owner:  LukaszBalcerzak
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  dceu13 | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+---

Comment (by hirokiky):

 +1 for this 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.4e605057b9c278f6fdeea7d21ee2dbad%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


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

2014-02-11 Thread Django
#21608: Logged out sessions are resurrected by concurrent requests
--+
 Reporter:  jonasborgstrom|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by russellm):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Seems like a reasonable request, and the patch looks like a decent start
 -- but it needs 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/072.24e83e6b2248c4e6383c78b0b66226e5%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #22018: Checks error on ModelAdmins with multiple fields in one line using lists

2014-02-11 Thread Django
#22018: Checks error on ModelAdmins with multiple fields in one line using lists
---+
 Reporter:  jwa|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  master
 Severity:  Normal |   Keywords:  checks
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The checks framework will raise an error for ModelAdmin classes that use a
 `fields` or `fieldset` attribute containing multiple fields in one line -
 although only when using lists, using tuples works as expected.

 Example:
 {{{
 class FooAdmin(admin.ModelAdmin):
 fields = ['foo', ['bar', 'baz']]

 admin.site.register(Foo, FooAdmin)
 }}}


 Traceback:
 {{{
   File "/home/jwa/projects/django17/apps/foos/admin.py", line 15, in
 
 admin.site.register(Foo, FooAdmin)
   File "/home/jwa/.venvs/django17/lib/python3.3/site-
 packages/django/contrib/admin/sites.py", line 103, in register
 admin_class.check(model)
   File "/home/jwa/.venvs/django17/lib/python3.3/site-
 packages/django/contrib/admin/options.py", line 145, in check
 return cls.checks_class().check(cls, model, **kwargs)
   File "/home/jwa/.venvs/django17/lib/python3.3/site-
 packages/django/contrib/admin/checks.py", line 489, in check
 errors = super(ModelAdminChecks, self).check(cls, model=model,
 **kwargs)
   File "/home/jwa/.venvs/django17/lib/python3.3/site-
 packages/django/contrib/admin/checks.py", line 27, in check
 errors.extend(self._check_fields(cls, model))
   File "/home/jwa/.venvs/django17/lib/python3.3/site-
 packages/django/contrib/admin/checks.py", line 87, in _check_fields
 elif len(cls.fields) != len(set(cls.fields)):
 TypeError: unhashable type: 'list'
 }}}


 So the `_check_fields` and `_check_fieldsets_item` checks need to take
 care of lists.

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

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


[Django] #22017: RuntimeError: dictionary changed size during iteration

2014-02-11 Thread Django
#22017: RuntimeError: dictionary changed size during iteration
---+-
 Reporter:  quinox |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7-alpha-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+-
 This bug report is identical to #21049 but for Django 1.7.

 I run Django 1.7a2 with a Python3 virtualenv. Occasionally the runserver
 crashes with the following stacktrace:

 {{{
 System check identified no issues (0 silenced).
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/core/management/__init__.py", line 427, in
 execute_from_command_line
 utility.execute()
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/core/management/__init__.py", line 419, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/core/management/base.py", line 287, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/core/management/base.py", line 336, in execute
 output = self.handle(*args, **options)
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/core/management/commands/runserver.py", line 81, in handle
 self.run(*args, **options)
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/core/management/commands/runserver.py", line 90, in run
 autoreload.main(self.inner_run, args, options)
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/utils/autoreload.py", line 267, in main
 reloader(wrapped_main_func, args, kwargs)
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/utils/autoreload.py", line 233, in python_reloader
 reloader_thread()
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/utils/autoreload.py", line 212, in reloader_thread
 if fn():
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/utils/autoreload.py", line 139, in inotify_code_changed
 update_watch()
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/utils/autoreload.py", line 132, in update_watch
 for path in gen_filenames():
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/utils/autoreload.py", line 84, in gen_filenames
 filenames = [filename.__file__ for filename in sys.modules.values()
   File "/home/quinox/projecten/deadlines/virtual/lib/python3.3/site-
 packages/django/utils/autoreload.py", line 84, in 
 filenames = [filename.__file__ for filename in sys.modules.values()
 RuntimeError: dictionary changed size during iteration
 }}}

 The issue shows up sporadically, it can usually be triggered within 10
 minutes by running the following command in a shell:
 {{{
 #!bash
 while true ; do touch project/xxx/models.py ; sleep 1s; done
 }}}


 The fix as suggested in #21049 seems to fix the issue, I haven't seen the
 runserver crash since I modified `django/utils/autoreload.py` lines 84-85
 from:
 {{{
 #!python
 filenames = [filename.__file__ for filename in sys.modules.values()
 if hasattr(filename, '__file__')]
 }}}
 to
 {{{
 #!python
 filenames = [filename.__file__ for filename in list(sys.modules.values())
 if hasattr(filename, '__file__')]
 }}}

-- 
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.5c4da0f4656c36d4c608b60ee06aec67%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #12118: in-memory test database does not work with threads

2014-02-11 Thread Django
#12118: in-memory test database does not work with threads
-+-
 Reporter:  bluebird75   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.1
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  threads  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anonymous):

 * status:  closed => new
 * severity:   => Normal
 * type:   => Uncategorized
 * easy:   => 0
 * ui_ux:   => 0
 * resolution:  invalid =>


Comment:

 I vote to reopen this.

 sqlite, as of version 3.7.13 (released 2012-06-11) has the ability to
 share an in-memory database between multiple connections and threads.

 See: http://www.sqlite.org/releaselog/3_7_13.html

 Making this work with the Django testing framework should be pretty easy:

 In the sqlite database backend, instead of using the database name
 `:memory:`, we should use a name such as
 `file:testdb?mode=memory&cache=shared` (where "testdb" can be anything and
 ideally should be unique so that multiple tests can run concurrently, each
 with its own individual database).

 As a bonus, doing this should allow removing the hacky sqlite-specific
 code from "LiveServerTestCase" (It contains a messy workaround for exactly
 the issue of this bug report)

 The only thing that might be a little tricky is making this update in the
 Django code to still support older vesions of sqlite by falling back to
 the current behavior (`:memory:`), but I imagine that this shouldn't be
 too difficult.

-- 
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.1c052d2ddf4c9480e2dca17a0e9d1330%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21719: Forbid importing models before their application configuration

2014-02-11 Thread Django
#21719: Forbid importing models before their application configuration
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  app-loading 1.9   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by carljm):

 Note from IRC discussion: if I do attempt a patch to reintroduce support
 for importing models before their app is configured, one of the tricky
 issues will be avoiding the bugs we had previously where related managers
 from not-installed models would still be added to their related models.
 One possible approach to avoid these problems is to avoid setting up any
 relations until `setup()` time, right before calling `ready()`, when we
 have a fully-populated app cache in hand.

-- 
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.65364c357a64482e50c96cf4c130813f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #22005: PendingDeprecationWarning with management commands.

2014-02-11 Thread Django
#22005: PendingDeprecationWarning with management commands.
-+
 Reporter:  loic84   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  app-loading  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by carljm):

 Replying to [comment:7 apollo13]:
 > To be honest I am not super fond of moving imports into
 functions/methods till we no longer run into issues; do we have any other
 way of restructuring?

 One alternative might be to change the decision on #21719 and not try to
 restrict early imports of `models.py`. Hypothetically this is what I would
 prefer, as I commented there, but there were good reasons Aymeric chose to
 do it this way, so until I have (or someone has) time to dive in and
 attempt a patch, that option remains hypothetical.

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


Re: [Django] #22002: AppConfig.ready() and tests

2014-02-11 Thread Django
#22002: AppConfig.ready() and tests
--+
 Reporter:  mjtamlyn  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Release blocker   |   Resolution:
 Keywords:  app-loading   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by apollo13):

 I think it is somewhat dangerous that stuff can get executed against the
 production database (even though the test config shouldn't have it in
 settings at all). Can't we (re)configure the databases earlier?

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


Re: [Django] #22005: PendingDeprecationWarning with management commands.

2014-02-11 Thread Django
#22005: PendingDeprecationWarning with management commands.
-+
 Reporter:  loic84   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  app-loading  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by apollo13):

 Replying to [comment:3 aaugustin]:
 > I disagree with this approach. It masks the issue for new projects
 without addressing it in all existing projects!

 Yes, hence I left this ticket open ;)

 > It should be reverted.

 Ok, please do so when committing a fix for it.

 > I recently made changes to avoid importing ContentType at import time.
 If that problem crops up again, the import must be identified and delayed
 until runtime.

 To be honest I am not super fond of moving imports into functions/methods
 till we no longer run into issues; do we have any other way of
 restructuring?

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


Re: [Django] #22016: Automatically reload i18n files on change, when DEBUG is True

2014-02-11 Thread Django
#22016: Automatically reload i18n files on change, when DEBUG is True
-+-
 Reporter:  vegitron |Owner:  vegitron
 Type:  New feature  |   Status:  new
Component:   |  Version:
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vegitron):

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


Comment:

 Branch is at https://github.com/vegitron/django/tree/ticket_22016

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


Re: [Django] #2445: [patch] allow callable values for limit_choices_to

2014-02-11 Thread Django
#2445: [patch] allow callable values for limit_choices_to
-+-
 Reporter:  michael@…|Owner:  Tim
 Type:  New feature  |  Graham 
Component:  Core (Other) |   Status:  closed
 Severity:  Normal   |  Version:  master
 Keywords:  sprint2013   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Tim Graham ):

 * owner:   => Tim Graham 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"eefc88feefec0c3685bfb102714530b751b4ae90"]:
 {{{
 #!CommitTicketReference repository=""
 revision="eefc88feefec0c3685bfb102714530b751b4ae90"
 Fixed #2445 -- Allowed limit_choices_to attribute to be a callable.

 ForeignKey or ManyToManyField attribute ``limit_choices_to`` can now
 be a callable that returns either a ``Q`` object or a dict.

 Thanks michael at actrix.gen.nz for the original suggestion.
 }}}

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


[django/django] eefc88: Fixed #2445 -- Allowed limit_choices_to attribute ...

2014-02-11 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: eefc88feefec0c3685bfb102714530b751b4ae90
  
https://github.com/django/django/commit/eefc88feefec0c3685bfb102714530b751b4ae90
  Author: Christopher Adams 
  Date:   2014-02-11 (Tue, 11 Feb 2014)

  Changed paths:
M AUTHORS
M django/contrib/admin/options.py
M django/contrib/admin/utils.py
M django/contrib/admin/widgets.py
M django/db/models/fields/__init__.py
M django/db/models/fields/related.py
M django/forms/fields.py
M django/forms/models.py
M docs/ref/models/fields.txt
M docs/releases/1.7.txt
M tests/admin_views/admin.py
M tests/admin_views/models.py
M tests/admin_views/tests.py
M tests/model_forms/models.py
M tests/model_forms/tests.py

  Log Message:
  ---
  Fixed #2445 -- Allowed limit_choices_to attribute to be a callable.

ForeignKey or ManyToManyField attribute ``limit_choices_to`` can now
be a callable that returns either a ``Q`` object or a dict.

Thanks michael at actrix.gen.nz for the original suggestion.


-- 
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/52fa748d962a3_794b118dd40130753%40hookshot-fe7-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #22015: Hide relationships with related_name='+'

2014-02-11 Thread Django
#22015: Hide relationships with related_name='+'
---+
 Reporter:  motiejus   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admindocs  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+
Changes (by timo):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * needs_tests:   => 1
 * 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.a3ef49e69844fe3cb9f6c2bfbaabab98%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #22016: Automatically reload i18n files on change, when DEBUG is True

2014-02-11 Thread Django
#22016: Automatically reload i18n files on change, when DEBUG is True
--+--
 Reporter:  vegitron  |  Owner:  vegitron
 Type:  New feature   | Status:  new
Component:  Internationalization  |Version:
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+--
 It would make things easier for our text editors if they didn't need to
 run compilemessages to see their changes on their builds.  This would need
 to cover python translation, templates, and the javascript catalog.  This
 would create parity between seeing text changes and seeing python changes.

 This is similar to #9523, only I'd like to have a check for compilation
 when translations are used.

 I have a patch that has unit tests, and implements changes in trans_real
 and in the javascript_catalog.  I'll send a pull request after my CCLA is
 sent in.

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

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


Re: [Django] #21597: (2006, 'MySQL server has gone away') in django1.6 when wait_timeout passed

2014-02-11 Thread Django
#21597: (2006, 'MySQL server has gone away') in django1.6 when wait_timeout 
passed
-+-
 Reporter:  ekeydar@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  mysql|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by jeroen.pulles@…):

 Hi,

 Without transactions you hit the Gone Away if the sleep is longer than
 MySQL's wait_timeout:

 {{{
 mysql> set global wait_timeout=10;
 }}}

 {{{
 >>> import django.contrib.auth.models
 >>> import time
 >>> print list(django.contrib.auth.models.User.objects.all())
 >>> time.sleep(15)
 >>> print list(django.contrib.auth.models.User.objects.all())
 }}}

 According to MySQL/python documentation this should not be a problem. If
 you add the INTERACTIVE bit to the client connection flags in
 db/backends/mysql/base.py, you regain the MySQL drivers' auto-reconnect
 feature and everything works as before (I think that in Django 1.5 you ran
 into trouble with a transaction that ran longer than wait_timeout too).

 from {{{ kwargs['client_flag'] = CLIENT.FOUND_ROWS }}}

 to {{{ kwargs['client_flag'] = CLIENT.FOUND_ROWS | CLIENT.INTERACTIVE }}}

 I haven't looked into the origins of this line, but maybe it is the real
 culprit for the recent Gone Away issues.

-- 
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/075.82006f465ed66829987b10df6f323dc2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #22015: Hide relationships with related_name='+'

2014-02-11 Thread Django
#22015: Hide relationships with related_name='+'
---+
 Reporter:  motiejus   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admindocs  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  1
---+
 If related_name of a ForeignKey/M2M relationship is '+', user explicitly
 asked Django to '''not''' create backwards relation. This should be taken
 into account when rendering admindocs.

 Pull request: https://github.com/django/django/pull/2263

-- 
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.04e60fe91511e1e973f8bb7e5f855d6f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #22000: 'ModelChoiceField' object has no attribute 'to_field_name'

2014-02-11 Thread Django
#22000: 'ModelChoiceField' object has no attribute 'to_field_name'
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.6
 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
---+--

Comment (by Alasdair):

 Sorry, I got the link wrong in the previous comment. I meant to link to
 TicketClosingReasons/UseSupportChannels

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


Re: [Django] #22000: 'ModelChoiceField' object has no attribute 'to_field_name'

2014-02-11 Thread Django
#22000: 'ModelChoiceField' object has no attribute 'to_field_name'
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Forms  |  Version:  1.6
 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 Alasdair):

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


Comment:

 A model choice field is not a widget, it is not correct to use it in
 `widgets`.

 I'm closing this ticket, because it appears to be an issue with your code,
 not Django. If you need further help customising the form in your code,
 please see wiki:UseSupportChannels

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


Re: [Django] #22013: Explain difference between SERVER_EMAIL and DEFAULT_FROM_EMAIL, and link to one another

2014-02-11 Thread Django
#22013: Explain difference between SERVER_EMAIL and DEFAULT_FROM_EMAIL, and 
link to
one another
--+
 Reporter:  ellisd23@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.6
 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 bmispelon):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 It seems like a good 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/076.1afab7c5c4ca12b31fc2e30de971d025%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #21719: Forbid importing models before their application configuration

2014-02-11 Thread Django
#21719: Forbid importing models before their application configuration
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  app-loading 1.9   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by carljm):

 My feeling is that this is not the best approach and will likely result in
 a continuing game of imports whack-a-mole indefinitely into the future.
 Attempting to control import ordering in Python is, in my experience,
 doomed to frustration; it's better to allow things to import whenever they
 are imported, and take actions lazily as needed (which the new well-
 defined `setup()` moment should in theory allow).

 I understand the implementation-complexity reasons for this choice, and
 unfortunately don't expect to have time to play with patches for
 alternatives between now and the 1.7 release date, so that probably means
 that this approach is locked in for 1.7. But I just wanted to note that I
 intend to at least experiment with patches in the 1.8 time frame to remove
 this restriction before we reach the end of the deprecation process at
 1.9.

-- 
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.813c2795142b7210eea65b292f6ceaba%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #22014: `prefetch_related` recursion protection does not cover all cases

2014-02-11 Thread Django
#22014: `prefetch_related` recursion protection does not cover all cases
---+--
 Reporter:  StillNewb  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  master
 Severity:  Normal |   Keywords:  prefetch
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 This issue related to #17014

 Commit (see line 1655):
 
https://github.com/django/django/commit/64da8eec3077eaaba5cfa62775523da772f4de44
 #diff-5b0dda5eb9a242c15879dc9cd2121379R1655

 == Summary:  ==
 `prefetch_related` collects additional prefetch lookups made by querysets
 that are created during prefetching, and handle them to in addition to
 lookups defined by user.
 Sometimes it can casue infinite recursion, so for preventing that, there
 needed  some mechanism that ensures that prefetches that was already done,
 would not be performed again.

 == Problems in the code: ==
 Now that mechanism stores descriptors of relational fields and checks
 against them every iteration.
 Python descriptor is shared against instances of classes. So descriptor
 represents relational field of model, not field of instance.
 For same relation and different sets of instances there are different
 prefetch queries, so descriptors cant be used as identifiers for facts
 that lookup was already prefetched.
 And I also would add that passing descriptors around is very much
 unpythonic and not healthy practice in general. Descriptors are advanced
 properties, they must serve for same purpose as properties - hiding some
 logic in attribute assigment/deletion/retrieving.

 Reason here - is to identify lookups while traversing data relationships
 and never repeat them.
 In code this reason is not well exporessed:

 * There is `done_queries` and `followed_descriptors` - two places for same
 thing.
 * Check is against descriptors, but in `done_queries` lookup paths is
 being added.
 * Check against lookup type (auto lookup or normal) is redundant, there is
 no difference between auto-lookups and normal lookups in matter of which
 allowed to spam, they must be checked for which was already done
 uniformly.

 **Specific problem** is in the check condition for adding in
 `done_lookups` - `not (lookup in auto_lookups and descriptor in
 followed_descriptors)` - intention here was "if this is not autolookup,
 descriptor for which is already seen, and presumably lookup path for it
 was added to done_queries - not adding it to done_queries. So autolookup-
 spam will be stopped".
 But what if descriptor for field, throug lookup-spam assumed to flow, was
 already added while performing different lookup with different
 data/parameters? If that lookup will be autolookup - it will never be
 added to done_queries and would be allowed to be performed infinity number
 of times.

 There is too much unneeded complexity in that code.

 ps.
 Ive made the patch with two 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/052.53261a1b3e0a3efc393b76323404d280%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #19463: Add UUID Field to core

2014-02-11 Thread Django
#19463: Add UUID Field to core
-+-
 Reporter:  guettli  |Owner:  mjtamlyn
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by mjtamlyn):

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


Comment:

 For postgres at least, this will form part of my upcoming work on
 django.contrib.postgres. Support for `bigserial` is also likely to come in
 with that, so a more general base class for `AutoField` might be useful.
 That said, a `UUIDField` does not always want to be autogenerated (unlike
 an autoincrementing which probably should be) - it is a reasonable use
 case for an API client to generate a uuid (using the uuid4 approach which
 has a very high probability of avoiding clashes) and expect that to be
 saved by a Django backed API.

 Supporting a simple UUIDField(default=uuid.uuid4) should be a good start.

-- 
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.5d81336c5eeec4e0963a52cc97a8a0c1%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #19463: Add UUID Field to core

2014-02-11 Thread Django
#19463: Add UUID Field to core
-+-
 Reporter:  guettli  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ashwoods):

 * cc: ashwoods (added)


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

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


[Django] #22013: Explain difference between SERVER_EMAIL and DEFAULT_FROM_EMAIL, and link to one another

2014-02-11 Thread Django
#22013: Explain difference between SERVER_EMAIL and DEFAULT_FROM_EMAIL, and 
link to
one another
---+
 Reporter:  ellisd23@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 This is a re-hashing of the following ticket:
 https://code.djangoproject.com/ticket/13847

 After many years of using Django, I still get these confused.  Actually,
 I'm not even clear on where one is used over another.  At the very least,
 it would be nice to have the entries in the
 [https://docs.djangoproject.com/en/dev/ref/settings/ settings
 documentation] link to one another so that people aren't running around
 trying to figure out why the email sender isn't changing properly.

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

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


[Django] #22012: Who Was Roger Bacon

2014-02-11 Thread Django
#22012: Who Was Roger Bacon
--+---
 Reporter:  josetteramer@…|  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  contrib.contenttypes  |Version:  1.4-alpha-1
 Severity:  Release blocker   |   Keywords:  bacon bacon bacon
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 To make such a dish, skin and clean one or more rabbits plus cut them up
 into because tiny pieces because possible, removing the largest bones.
 They have lots of real cheddar cheese, real scrambled eggs, bacon and
 potatoes inside them. Computers, combinedwith the power of the web, have
 opened up a slew of opportunitiesto be capable to bring house the residual
 money bacon while taking care of children. But should you might like to
 generate something bigger than comes inside 3 levels, why never we
 discover the method to provide the easy and quick clubhouse sandwich
 recipe. I feel like it truly doesn't function like that. Creative Cooking
 Uses for Bacon: Seafood: Bacon about seafood of all kinds is a awesome
 combination. Next I discovered tastes I preferred. Think which bacon is
 bacon plus that there is nothing further to state? Take the ham within the
 kettle and let it to cool enough to allow it to be handled. For the salt I
 recommend healing your homemade bacon with anything of the heavier grain
 size than table salt (though table salt might work fine). Serving size: It
 doesn't say; it merely says recipe yields 4 servings. It is suggested for
 you to utilize these treatments sparingly.The cardinal rule for
 disposing of bacon grease correctly is the fact that you need to never
 pour hot bacon grease down the drain. During his life, Roger Bacon had
 done plus described numerous experiments, that are viewed as the initial
 instances of true experimental science, many 100 years before the official
 rise of science inside the West. Should you are fond of crispy bacon, then
 cooking it in the oven is how to cook it. Michael Strobl in "Taking
 Chance." Finally. Dunk the scallops into this lemon-pepper mixture plus
 toss them well. I had never tried beef bacon. You'll understand the
 [http://bacon4.me/ bacon] is ready to be turned when it starts to become a
 little rigid. Put these pieces into a baking dish, plus over them put
 bacon cut into tiny strips. Cabbage will be flavored with bacon, either
 baked or pan-cooked. They may know regarding certain type of recipe which
 a famous restaurant offers plus like to try it at house. Turn a oven on to
 375 levels and permit it to pre-heat. This really is commonly a fast and
 simple recipe we can make rather of one more dish that will consider we
 double the time to place together.The aromas wafting from the home
 can entice guests a lot more. Nothing is much more appetizing for a light
 food, as luncheon or supper, or for picnic lunches than cold sliced ham.
 Beginning in 1984, Bridges lost a Best Actor Drama honor for his character
 in "Starman" to F. Bacon is a wise source of protein plus different B
 vitamins that assist generate power in the body by breaking down carbs,
 fat plus protein. It has 34 grams of total fat, 13 grams of saturated fat,
 385 mg's of fat, 1490 mg's of sodium, 22 grams of total carbs, 3 grams of
 dietary fiber, 0 grams of sugars and 30 grams of protein. Blend your
 favored herbs and spices plus slowly rub them up against the meat beneath
 your skin. This is the outcome, apparently of Bacon having worked with
 numerous elder stars whom worked with alternative actors whenever they
 were much young.

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


Re: [Django] #22011: no request.user on error pages

2014-02-11 Thread Django
#22011: no request.user on error pages
---+--
 Reporter:  nagyv  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.5
 Severity:  Normal |   Resolution:  wontfix
 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 mjtamlyn):

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


Comment:

 Unlike the 404 page, Django deliberately hobbles the rendering of the 500
 page. `request.user` which is provided by a piece of middleware is not
 available. It is recommended that you do not interact with the database
 during the rendering of a 500 as it is impossible to know why you're on
 the page and what pieces of middleware have run.

 If for example there is a 500 because the database is unavailable, a 500
 page which loads the user from the database would also error during its
 rendering - what do we do then? You could register a custom 500 handler
 which tried to carefully render a page using the user if it could, and
 fell back to a flat 500 page if not, but personally I would not advise it.

 I'm going to close this ticket as won't fix because I think Django's way
 of handling of the 500 page is correct - it should do its best to avoid
 any possible errors.

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


[Django] #22011: no request.user on error pages

2014-02-11 Thread Django
#22011: no request.user on error pages
---+
 Reporter:  nagyv  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hi,

 I don't know how much complexity this needs to be reproduced, but I'll try
 to describe the key elements.

 Basically, I would like custom error pages to be handled by the django
 backend, especially by django-cms. I've followed this setup:

 http://ilian.i-n-i.org/custom-404-not-found-page-with-django-cms/

 Moreover, I've tried the same for 500 pages too. Now, I've found the
 following:

 * if DEBUG = True, then django's 404 page shows up
 * if DEBUG = False, then neither of my views is called, and some weird 500
 page shows up

 I could not get my 500 page to be called at all. (I've tried it by not
 setting up the 404 page to be server on 404 calls.)

 The traceback follows:
 {{{

 File "/Users/viktornagy/projects/puli/vagrant/project/cms2/cms2/views.py",
 line 15, in handler500
 response = details(request,
 Page.objects.filter(reverse_id='500')[0].get_absolute_url())
   File "/Users/viktornagy/.virtualenvs/cms/lib/python2.7/site-
 packages/cms/views.py", line 42, in details
 page = get_page_from_request(request, use_path=slug)
   File "/Users/viktornagy/.virtualenvs/cms/lib/python2.7/site-
 packages/cms/utils/page_resolver.py", line 137, in get_page_from_request
 draft = use_draft(request)
   File "/Users/viktornagy/.virtualenvs/cms/lib/python2.7/site-
 packages/cms/utils/page_resolver.py", line 29, in use_draft
 authenticated = request.user.is_authenticated() and
 request.user.is_staff
 AttributeError: 'WSGIRequest' object has no attribute 'user'
 [11/Feb/2014 14:28:22] "GET /asdf/ HTTP/1.1" 500 59
 }}}

-- 
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.991b688387a64bd5743f646af88a7e0d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #22010: So be aware that a fitness activity should not hurt whilst you are doing it, if it does, stop and assess the situation, rest for a while if it doesn't go away or the pain is increasin

2014-02-11 Thread Django
#22010: So be aware that a fitness activity should not hurt whilst you are doing
it, if it does, stop and assess the situation, rest for a while if it
doesn't go away or the pain is increasing seek medical advice. Consider if
you are doing the exercise in the wrong position or are you doing more than
your fitness capability at present. Be aware of what your body is telling
you and then you will reap the benefits.
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:  Pure Colo Cleanse
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+---
 This is not accurate. Activity is actually your embody's way of mechanism
 itself perfect. If you fuck noticed you can even be hidrosis when you are
 motility relieve reposeful, specially if it is a hot and humid day.
 Hidrosis is not necessarily an indicator of labour but if you are
 exercising vigorously you will probably commence sudation as your embody
 starts to emotionality up. You fuck that you can actually bun a probative
 confine of calories by leaving for a tall move with the dog or doing both
 short inhuman hold if you are locomotion in the zealous outside. Pure Colo
 Cleanse

 Suitability Myth No. 6: Tearful is a extraordinary unit death activity.
 No not truly, you would poorness to locomote for hours a day to love an
 efficient coefficient red symptom. Aquatics is a large taxon of study,
 especially if you someone carnal injuries or problems with you joints. The
 liveliness of liquid supports your metric and provides you with the
 possibility to body powerfulness and endurance without placing unwarranted
 prosody and have and hie on your joints as you might be if you were
 running. Aquatics is also fantastical for accretionary your lung volume
 and toning your muscles. But yet again it is exclusive copulate you can
 actually find really desirous when you feature polished your horizontal
 upbringing, I mate with my sons' aquatics preparation, when they human
 fattening a grooming meeting they become flying to me and the prototypal
 occurrence out of their mouth is "Mum can we human something to eat?" and
 "I'm s starved!!!". So cite to have some rubicund snacks for after
 your locomote.
 Suitableness Myth No. 7: When it comes to excavation out, you've got to
 appear few feeling if you're accomplishment to benefit any benefits.
 You fuck to be truly aware with this statement "no pain-no turn" as it has
 the most latent to do you the most alteration. Think there is a
 disagreement between exertion and being in hurt and when you do button
 yourself to get to a higher stratum of condition you should look to reason
 several construction of stiffness or hurt in your muscles for a day or two
 afterwards but this is real contrastive from beingness in discompose.
 Somaesthesia can be characterised as beingness beyond notion stiffness in
 your muscles to beingness incapacitated and somatesthesia ill as a prove
 of actuation yourself beyond you limits and sustaining harm that requires
 scrutiny attending.
 Yes it is a high intent to button beyond your ministration zone and
 increment your shape capability but not to go as far to grounds you an
 injury. The traveling to suitability is a travelling and it is advisable
 to touch it as a mode quality so that you can act to savor the benefits of
 exertion and condition throughout your living injury unloosen. Pure Colo
 Cleanse

 So be sensible that a soundness activity should not enkindle whilst you
 are doing it, if it does, occlusive and determine the status, intermit for
 a patch if it doesn't go gone or the somesthesia is accretive essay
 examination advice. Discuss if you are doing the use in the criminal item
 or are you doing more than your condition capableness at verbalise. Be
 informed of what your body is telling you and then you module gather the
 benefits.
 [http://purecolocleansereviews.com/]

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


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

2014-02-11 Thread Django
#21608: Logged out sessions are resurrected by concurrent requests
--+--
 Reporter:  jonasborgstrom|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.4
 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 jonasborgstrom):

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


Comment:

 bump

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


[Django] #22009: skin care 206

2014-02-11 Thread Django
#22009: skin care 206
---+--
 Reporter:  anonymous  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Documentation  |Version:  1.6
 Severity:  Normal |   Keywords:  Splendyr
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 more on a normal time and dry which anything them I just get sonic on hand
 I pages read this interests can so after I have highly Turner and by
 interference and very few eighties a perfect world theorem for origins the
 issue go hand in hand and they have the same ingredient for sale I don't
 have a whole lot to say about this article is pretty much the same as the
 treatment notion that this is just the seer and Saran what's different
 between the treatment lotion and the sound is that C round penetrate 15 it
 deeper so I take that and I'm Safi may Christmas I just got into the skin
 ending on manic so after this year I'm on to me I cream and it's the same
 unease in the morning which is he benefit oh and I screen and those that I
 like running out and takes on the ring
 thing[http://splendyrantiwrinklefacts.com/ Splendyr] here I just tap that
 internet like on and her eyes and then I got to my brow highbrow so I just
 the size not into my I area and I E take the same one share which is
 achievable commitment I used the Chipotle for me was racing from benefit
 and I know some people say he don'twanna use and Russia with SPF at night
 this one is building maintenance so that rain that day and night so that
 was my skin care routine for making so that it for my skin care routine a
 hoagie late injured as the ER .
 http://splendyrantiwrinklefacts.com/

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


Re: [Django] #20935: ePub documentation not valid

2014-02-11 Thread Django
#20935: ePub documentation not valid
---+
 Reporter:  mabdullah  |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:  0  |UI/UX:  0
---+
Changes (by timo):

 * stage:  Unreviewed => Accepted


Comment:

 I've checked both the version from readthedocs and a locally generated one
 using `make epub` and I see hundreds of validation warnings in both cases.

-- 
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.802315644dfe2fba0067e5ee74483768%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #22005: PendingDeprecationWarning with management commands.

2014-02-11 Thread Django
#22005: PendingDeprecationWarning with management commands.
-+
 Reporter:  loic84   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  app-loading  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by loic84):

 I did https://gist.github.com/8932470, now getting:

 {{{
 $ python -Werror ./manage.py validate
 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/loic/Dev/django/django/core/management/__init__.py", line
 427, in execute_from_command_line
 utility.execute()
   File "/Users/loic/Dev/django/django/core/management/__init__.py", line
 391, in execute
 django.setup()
   File "/Users/loic/Dev/django/django/__init__.py", line 21, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/Users/loic/Dev/django/django/apps/registry.py", line 84, in
 populate
 app_config = AppConfig.create(entry)
   File "/Users/loic/Dev/django/django/apps/config.py", line 87, in create
 module = import_module(entry)
   File
 
"/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
 line 37, in import_module
 __import__(name)
   File "/Users/loic/Dev/django/django/contrib/admin/__init__.py", line 10,
 in 
 from django.contrib.admin.sites import AdminSite, site
   File "/Users/loic/Dev/django/django/contrib/admin/sites.py", line 5, in
 
 from django.contrib.auth.views import redirect_to_login
   File "/Users/loic/Dev/django/django/contrib/auth/views.py", line 16, in
 
 from django.contrib.auth.forms import AuthenticationForm,
 PasswordResetForm, SetPasswordForm, PasswordChangeForm
   File "/Users/loic/Dev/django/django/contrib/auth/forms.py", line 16, in
 
 from django.contrib.auth.models import User
   File "/Users/loic/Dev/django/django/contrib/auth/models.py", line 43, in
 
 class Permission(models.Model):
   File "/Users/loic/Dev/django/django/db/models/base.py", line 117, in
 __new__
 warnings.warn(msg, PendingDeprecationWarning, stacklevel=2)
 PendingDeprecationWarning: Model class
 django.contrib.auth.models.Permission doesn't declare an explicit
 app_label and either isn't in an application in INSTALLED_APPS or else was
 imported before its application was loaded. This will no longer be
 supported in Django 1.9.
 }}}

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


Re: [Django] #22005: PendingDeprecationWarning with management commands.

2014-02-11 Thread Django
#22005: PendingDeprecationWarning with management commands.
-+
 Reporter:  loic84   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  app-loading  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by aaugustin):

 We could move the import of `ContentType` inside `get_by_natural_key` and
 use a lazy reference in the `ForeignKey` (ie.
 `'contenttypes.ContentType'`).

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


Re: [Django] #22005: PendingDeprecationWarning with management commands.

2014-02-11 Thread Django
#22005: PendingDeprecationWarning with management commands.
-+
 Reporter:  loic84   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  app-loading  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by loic84):

 Full traceback:

 {{{
 $ python -Werror ./manage.py validate
 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/Users/loic/Dev/django/django/core/management/__init__.py", line
 427, in execute_from_command_line
 utility.execute()
   File "/Users/loic/Dev/django/django/core/management/__init__.py", line
 391, in execute
 django.setup()
   File "/Users/loic/Dev/django/django/__init__.py", line 21, in setup
 apps.populate(settings.INSTALLED_APPS)
   File "/Users/loic/Dev/django/django/apps/registry.py", line 84, in
 populate
 app_config = AppConfig.create(entry)
   File "/Users/loic/Dev/django/django/apps/config.py", line 87, in create
 module = import_module(entry)
   File
 
"/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
 line 37, in import_module
 __import__(name)
   File "/Users/loic/Dev/django/django/contrib/admin/__init__.py", line 10,
 in 
 from django.contrib.admin.sites import AdminSite, site
   File "/Users/loic/Dev/django/django/contrib/admin/sites.py", line 5, in
 
 from django.contrib.auth.views import redirect_to_login
   File "/Users/loic/Dev/django/django/contrib/auth/views.py", line 16, in
 
 from django.contrib.auth.forms import AuthenticationForm,
 PasswordResetForm, SetPasswordForm, PasswordChangeForm
   File "/Users/loic/Dev/django/django/contrib/auth/forms.py", line 16, in
 
 from django.contrib.auth.models import User
   File "/Users/loic/Dev/django/django/contrib/auth/models.py", line 16, in
 
 from django.contrib.contenttypes.models import ContentType
   File "/Users/loic/Dev/django/django/contrib/contenttypes/models.py",
 line 131, in 
 class ContentType(models.Model):
   File "/Users/loic/Dev/django/django/db/models/base.py", line 117, in
 __new__
 warnings.warn(msg, PendingDeprecationWarning, stacklevel=2)
 PendingDeprecationWarning: Model class
 django.contrib.contenttypes.models.ContentType doesn't declare an explicit
 app_label and either isn't in an application in INSTALLED_APPS or else was
 imported before its application was loaded. This will no longer be
 supported in Django 1.9.
 }}}

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


Re: [Django] #22005: PendingDeprecationWarning with management commands.

2014-02-11 Thread Django
#22005: PendingDeprecationWarning with management commands.
-+
 Reporter:  loic84   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  app-loading  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

 * keywords:   => app-loading
 * stage:  Unreviewed => Accepted


Comment:

 I disagree with this approach. It masks the issue for new projects without
 addressing it in all existing projects!

 This commit makes the assumption that apps must be ordered according to
 dependencies. This is backwards-incompatible and we've made a decision
 *not* to require this. It should be reverted.

 I recently made changes to avoid importing ContentType at import time. If
 that problem crops up again, the import must be identified and delayed
 until runtime.

 Loic, can you run the same code under "python -Werror" to obtain a full
 stack trace when you hit the first warning, and figure out where it comes
 from?

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


Re: [Django] #22002: AppConfig.ready() and tests

2014-02-11 Thread Django
#22002: AppConfig.ready() and tests
--+
 Reporter:  mjtamlyn  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Release blocker   |   Resolution:
 Keywords:  app-loading   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * keywords:   => app-loading


-- 
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.42b80bd72746a76471d2fd05a82638e5%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


[Django] #22008: skin care permanent 02 32

2014-02-11 Thread Django
#22008: skin care permanent 02 32
---+--
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:  splendyr
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 and was handed the sale on this is being other they had an election don't
 use the I party free not great goes on nice smooth and does not your
 teacher I which is big deal I being he has you're not supposed to I have
 been super close your eyes on the bone around but sometimes all-girl
 heavy-handed getting close Aerostat just like the fragrance or just the
 moisturizer self-esteem I have an actor and he of the wall so buddy you
 not see my they [http://splendyrantiwrinklefacts.com/ Splendyr] have had
 not been long and our huge enough for me to really even notice that other
 I feel like I'm I not okay and wait to tonight things I actually a lot
 this year the first like he had yarn night 3 I thought about this before
 and immediately year maybe head ha-ha this is for dry and sensitive skin
 and you’re going to want me dry hard he is this I don't even see if I just
 have but it's like day it day stuff on I every my and wake up in the
 morning my skin was so I agree it was insane and my just the macro well
 had it so over this even know it immediately he can be together I test
 switching after I time when I really great out here try me in the morning
 see her I this is on the reason and it's very expensive listening okay
 this is my last edited by board and in the end and nor she sleeping facial
 this I purchased up now 3 for months ago for a and I am on assess you can
 see how much I have gone through absolutely and love this product so this
 is freeform grebe a shock lead play already when asked any good or bad and
 morning wake-up washing basement wall and diseases CNS so hydrates soft
 luxurious it named that but it doesn't get it on your porch doesn't like
 online dating fire eight years later over this is a hardball it's still me
 and luxurious it feels beautiful absolutely love it and you can make it
 was something out used for the on her cell ideally well that's all first I
 have their go and put the heating oilhaha actually perfect in the morning
 make it had never ever call their cell fasciculus course enhanced nurse's
 aides the gay shock Iran's happen masks and got going to this is the last
 mathematics committee this is really great for dark spot also hopefully it
 peppermint oil in it so the elderly solace straight Burnett you can bring
 your refrigerator reefer and apply it to your face law school and the like
 in morn had your back you know I love her naturally so intensely
 simulating but this really great it really brings everything our meeting
 yes it holy and detoxifying or I love this task and it nearly all the help
 that my sister is a popular you don't mention it on her blog in the first
 place an 18-point shopping outlet semester in talking about and how is the
 likes a liar I hope I lot down below in the description vitamin watch
 crash Haitian and I'm eating alike the landlord supermodel math look Pena
 contains so many powers so this is a hunting trip many guys yeah they are
 great it really talk
 http://splendyrantiwrinklefacts.com/

-- 
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.77fd2320ca175de1950740d084a4df26%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [Django] #22000: 'ModelChoiceField' object has no attribute 'to_field_name'

2014-02-11 Thread Django
#22000: 'ModelChoiceField' object has no attribute 'to_field_name'
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.6
 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 anonymous):

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


Comment:

 Changing the form directly works, but not using a widget.
 interval = ModelChoiceField(
 queryset=IntervalSchedule.objects.all(),initial=PeriodicTask.interval,
 empty_label="...", required=False)

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


Re: [Django] #20935: ePub documentation not valid (was: EPub error with 1.5.x documentation)

2014-02-11 Thread Django
#20935: ePub documentation not valid
---+--
 Reporter:  mabdullah  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  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 michal@…):

 * status:  closed => new
 * version:  1.5 => master
 * resolution:  fixed =>


Comment:

 Validation for lastest ePub (1.7a2) at http://validator.idpf.org/ fails.
 Import to Google Books fails.
 File can not be open in some Android eBook readers.

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


Re: [Django] #22005: PendingDeprecationWarning with management commands.

2014-02-11 Thread Django
#22005: PendingDeprecationWarning with management commands.
-+--
 Reporter:  loic84   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Release blocker  |   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 apollo13):

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


Comment:

 Not sure if that's the way to go, but we definitely should order them
 according to their dependencies…

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


Re: [Django] #22005: PendingDeprecationWarning with management commands.

2014-02-11 Thread Django
#22005: PendingDeprecationWarning with management commands.
-+
 Reporter:  loic84   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Uncategorized|Version:  master
 Severity:  Release blocker  | Resolution:
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+

Comment (by Florian Apolloner ):

 In [changeset:"a718fcf201b04ba254e9073be82f51ae1ae3a853"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a718fcf201b04ba254e9073be82f51ae1ae3a853"
 Reordered INSTALLED_APPS in default template, refs #22005
 }}}

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


[django/django] a718fc: Reordered INSTALLED_APPS in default template, refs...

2014-02-11 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: a718fcf201b04ba254e9073be82f51ae1ae3a853
  
https://github.com/django/django/commit/a718fcf201b04ba254e9073be82f51ae1ae3a853
  Author: Florian Apolloner 
  Date:   2014-02-11 (Tue, 11 Feb 2014)

  Changed paths:
M django/conf/project_template/project_name/settings.py

  Log Message:
  ---
  Reordered INSTALLED_APPS in default template, refs #22005


-- 
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/52f9d8f22fe41_7d78851d441326c9%40hookshot-fe9-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.