date:20141227

Re: [Django] #23919: Cleanups for when we drop Python 2 compatibility

2014-12-27 Thread Django

#23919: Cleanups for when we drop Python 2 compatibility
-+-
 Reporter:  timgraham|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by collinanderson:

Old description:

> This is a tracking ticket of things that we can remove when we drop
> Python 2 compatibility (in a few years or so). Please edit the
> description of the ticket as you come across new items.
>
> * `django.dispatch.weakref_backports`
> * `django.utils.2to3_fixes`
> * `django.utils.lru_cache`
> * `django.utils.html_parser.use_workaround`
> * `django.utils.decorators.ContextDecorator`
> * `django.utils.six`
> * Change `inspect.getargspec()` (deprecated since 3.0) to
> `inspect.getfullargspec()`
> * `@python_2_unicode_compatible`
> * `from __future__ import unicode_literals`
> * Lots of workarounds in `django.http.cookie`
> * `str()` stuff for environment variables, e.g.
> 0bfb53866199f366ed140d49938fd185e5898156

New description:

 This is a tracking ticket of things that we can remove when we drop Python
 2 compatibility (in a few years or so). Please edit the description of the
 ticket as you come across new items.

 * `django.dispatch.weakref_backports`
 * `django.utils.2to3_fixes`
 * `django.utils.lru_cache`
 * `django.utils.html_parser.use_workaround`
 * `django.utils.decorators.ContextDecorator`
 * `django.utils.six`
 * Change `inspect.getargspec()` (deprecated since 3.0) to
 `inspect.getfullargspec()`
 * `@python_2_unicode_compatible`
 * `from __future__ import unicode_literals`
 * Lots of workarounds in `django.http.cookie`
 * `str()` stuff for environment variables, e.g.
 0bfb53866199f366ed140d49938fd185e5898156
 * `django.core.mail.message.make_msgid()` #23905

--

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

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

2014-12-27 Thread Django

#21608: Logged out sessions are resurrected by concurrent requests
--+-
 Reporter:  jonasborgstrom|Owner:  anonymous
 Type:  Bug   |   Status:  assigned
Component:  contrib.sessions  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+-

Comment (by collinanderson):

 would `session.save(force_update=True)` fix this issue?

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

Re: [Django] #21628: Stop using the `imp` module

2014-12-27 Thread Django

#21628: Stop using the `imp` module
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by collinanderson):

 I think the one remaining case is in `ProxyFinder` in
 `tests/utils_tests/test_module_loading.py`

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

Re: [Django] #21906: dumpdata should not use router.allow_migrate (was: dumpdata should not use router.allow_syncdb)

2014-12-27 Thread Django

#21906: dumpdata should not use router.allow_migrate
-+-
 Reporter:  yscumc   |Owner:
 |  andersonresende
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  1.5
  commands)  |
 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
-+-

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

Re: [Django] #22079: TestClient serialization of GET params with empty list as value (was: TestClient serialization of POST params with empty list as value)

2014-12-27 Thread Django

#22079: TestClient serialization of GET params with empty list as value
-+-
 Reporter:   |Owner:  nobody
  code.djangoproject.com@…   |
 Type:  Bug  |   Status:  new
Component:  Testing framework|  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
-+-

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

Re: [Django] #22209: Django internals call len(queryset) instead of queryset.count()

2014-12-27 Thread Django

#22209: Django internals call len(queryset) instead of queryset.count()
-+-
 Reporter:  gcc  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (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
-+-

Comment (by collinanderson):

 Changing the behavior of `count()` to magically check the length of the
 cached data if it exists only helps if the queryset is evaluated first.
 It's still better to use `len()` rather than `count()` in this case:

 {{{
 if queryset.count():
 for x in queryset:
 # do something.
 }}

 I've actually gone through a lot of my code and changed count() to len()
 in a lot of cases it where it was actually making things slower.
 It seems to me it's not worth changing anything here except for maybe
 changing the warning to be less severe.

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

Re: [Django] #22446: Add tox support

2014-12-27 Thread Django

#22446: Add tox support
--+
 Reporter:  jmbowman  |Owner:  jmbowman
 Type:  Cleanup/optimization  |   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:  0 |UI/UX:  0
--+

Comment (by collinanderson):

 Is this still needed now that we have http://djangoci.com/?

 Not sure what the approach would be now. Maybe a docker container with all
 of the databases (kind of outside the scope of django itself)? Or an
 ansible script to set it all up?

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

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

Re: [Django] #23938: changing a ManyToManyField to a CharField while also deleting the model being connected to breaks migrations

2014-12-27 Thread Django

#23938: changing a ManyToManyField to a CharField while also deleting the model
being connected to breaks migrations
-+
 Reporter:  hoylemd  |Owner:  MarkusH
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by MarkusH):

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

Re: [Django] #11495: Improvements to django.views.static.serve directory indexes

2014-12-27 Thread Django

#11495: Improvements to django.views.static.serve directory indexes
--+---
 Reporter:  SmileyChris   |Owner:  SmileyChris
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  static| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+---

Comment (by timgraham):

 It seems `show_indexes` dates back to when the view was first added in
 572ac3e7dfadec6434527ebbdccef97de1cc191c. I didn't see any mention in the
 ticket about why this functionality was needed. I guess it makes it a bit
 easier to debug if you have a typo in a file name or something (rather
 than opening up a file browser). Collin, can you present your rationale
 for deprecating it? No doubt some people like it and 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/069.81bf44870ab057d913e4e04f92662f12%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24056: Syntax highlighting does not work

2014-12-27 Thread Django

#24056: Syntax  highlighting does not work
--+
 Reporter:  AmiZya|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"1cbdb49b0aaba726435db55c4d71dc6a8ade1d2b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1cbdb49b0aaba726435db55c4d71dc6a8ade1d2b"
 [1.7.x] Fixed #24056 -- Fixed syntax highlighting in
 topics/testing/tools.txt.

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

Re: [Django] #24056: Syntax highlighting does not work

2014-12-27 Thread Django

#24056: Syntax  highlighting does not work
--+
 Reporter:  AmiZya|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"116d2098f61cff44596175b5d8b9d8d0d4005a0e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="116d2098f61cff44596175b5d8b9d8d0d4005a0e"
 [1.6.x] Fixed #24056 -- Fixed syntax highlighting in
 topics/testing/tools.txt.

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

Re: [Django] #24056: Syntax highlighting does not work

2014-12-27 Thread Django

#24056: Syntax  highlighting does not work
--+
 Reporter:  AmiZya|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"3d0c3a0482496fc1914a40ec3c3eb70e67f0d643"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3d0c3a0482496fc1914a40ec3c3eb70e67f0d643"
 Fixed #24056 -- Fixed syntax highlighting in topics/testing/tools.txt.
 }}}

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

Re: [Django] #23753: Provide a set of SQL functions

2014-12-27 Thread Django

#23753: Provide a set of SQL functions
-+-
 Reporter:  jarshwah |Owner:  jarshwah
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  expressions  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  closed => new
 * has_patch:  1 => 0
 * resolution:  fixed =>
 * severity:  Normal => Release blocker
 * stage:  Ready for checkin => Accepted


Comment:

 There's a test failure on Oracle/Python 2:
 {{{
 db_functions.tests.FunctionTests.test_coalesce_mixed_values

 Traceback (most recent call last):
   File "/mnt/jenkinsdata/workspace/django-
 oracle/database/oracle11/python/python3.3/django/db/backends/utils.py",
 line 65, in execute
 return self.cursor.execute(sql, params)
   File "/mnt/jenkinsdata/workspace/django-
 oracle/database/oracle11/python/python3.3/django/db/backends/oracle/base.py",
 line 942, in execute
 return self.cursor.execute(query, self._param_generator(params))
 cx_Oracle.DatabaseError: ORA-00932: inconsistent datatypes: expected NCHAR
 got NCLOB
 }}}

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

Re: [Django] #24057: Fix typo in custom lookups howto.

2014-12-27 Thread Django

#24057: Fix typo in custom lookups howto.
--+
 Reporter:  EnTeQuAk  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  closed
Component:  Documentation |Version:  master
 Severity:  Normal| Resolution:  fixed
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"508be27dbf43b5525a298ad184a9833906b6744c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="508be27dbf43b5525a298ad184a9833906b6744c"
 Fixed #24057 -- Fixed typo in docs/howto/custom-lookups.txt.
 }}}

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

Re: [Django] #29: Fix usability issue with limit_choices_to and "Add another" in admin

2014-12-27 Thread Django

#29: Fix usability issue with limit_choices_to and "Add another" in admin
---+-
 Reporter:  adrian |Owner:  anonymous
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Someday/Maybe
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+-

Comment (by collinanderson):

 #23595 is prepopulating add fields based on limit_choices_to.

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

Re: [Django] #23595: “add” button for related fields in admin interface should send 'limit_choices_to' parameter to add form

2014-12-27 Thread Django

#23595: “add” button for related fields in admin interface should send
'limit_choices_to' parameter to add form
--+
 Reporter:  macarena  |Owner:  gchp
 Type:  Cleanup/optimization  |   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:  1
--+
Changes (by collinanderson):

 * cc: cmawebsite@… (added)


Comment:

 Maybe this will solve #29 :)

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

[Django] #24057: Fix typo in custom lookups howto.

2014-12-27 Thread Django

#24057: Fix typo in custom lookups howto.
--+
 Reporter:  EnTeQuAk  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Quite simple typo I think, the PR is on GitHub:
 https://github.com/django/django/pull/3803

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

Re: [Django] #19253: Refactor keyfunc from template cache tag

2014-12-27 Thread Django

#19253: Refactor keyfunc from template cache tag
-+-
 Reporter:  nosa_manuel  |Owner:  oinopion
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sprint2013   | 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 jezdez):

 I think this should have put into `django.utils.cache` where other cache
 related utilities including cache key generation happen already.

 Is there a particular reason why this was put into a completely new module
 instead?

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

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

Re: [Django] #22839: Many to many hasattr check fails with python 3

2014-12-27 Thread Django

#22839: Many to many hasattr check fails with python 3
-+-
 Reporter:  web-chib@…   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 collinanderson):

 * status:  new => closed
 * cc: cmawebsite@… (added)
 * resolution:   => invalid


Comment:

 As linovia said, hasattr returns False on all exceptions on python 2, and
 only returns False on AttributeError on python 3. Feel free to reopen if
 that isn't the issue.

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

Re: [Django] #23922: Quoting problem in RequestFactory

2014-12-27 Thread Django

#23922: Quoting problem in RequestFactory
-+-
 Reporter:  berkerpeksag |Owner:
 |  berkerpeksag
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by berkerpeksag):

 * status:  assigned => closed
 * needs_better_patch:  1 => 0
 * resolution:   => invalid


Comment:

 Thanks. I agree with your analysis. I'll convert my branch to a pull
 request and will close [https://github.com/django/django/pull/3645 PR
 #3645].

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

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

Re: [Django] #23882: django 1.7 + inotify breaks autoreload of runserver with vim

2014-12-27 Thread Django

#23882: django 1.7 + inotify breaks autoreload of runserver with vim
--+
 Reporter:  orzel |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  autoreload| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by collinanderson):

 * cc: cmawebsite@… (added)
 * keywords:   => autoreload


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

Re: [Django] #24053: Drop IE6/7 admin CSS/icons

2014-12-27 Thread Django

#24053: Drop IE6/7 admin CSS/icons
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
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
--+

Comment (by collinanderson):

 Sounds like a good idea to me.

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

Re: [Django] #11495: Improvements to django.views.static.serve directory indexes

2014-12-27 Thread Django

#11495: Improvements to django.views.static.serve directory indexes
--+---
 Reporter:  SmileyChris   |Owner:  SmileyChris
 Type:  Bug   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  static| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+---
Changes (by collinanderson):

 * cc: cmawebsite@… (added)
 * keywords:   => static


Comment:

 I think we should deprecate and remove `show_indexes` completely. What do
 people use it for?

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

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

Re: [Django] #20488: Enhance the Storage class with new copy and move methods

2014-12-27 Thread Django

#20488: Enhance the Storage class with new copy and move methods
--+
 Reporter:  kux   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  File uploads/storage  |  Version:  master
 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 kux):

 Addressed all comments and opened new PR
 https://github.com/django/django/pull/3801

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

Re: [Django] #20488: Enhance the Storage class with new copy and move methods

2014-12-27 Thread Django

#20488: Enhance the Storage class with new copy and move methods
--+
 Reporter:  kux   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  File uploads/storage  |  Version:  master
 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
--+
Changes (by kux):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #23831: mark_safe and mark_for_escaping should account for html

2014-12-27 Thread Django

#23831: mark_safe and mark_for_escaping should account for __html__
---+-
 Reporter:  aaugustin  |Owner:  aaugustin
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  1.7
 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 Aymeric Augustin ):

 In [changeset:"3483682749577b4b5a8141a766489d5b460e30e9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3483682749577b4b5a8141a766489d5b460e30e9"
 [1.7.x] Fixed #23831 -- Supported strings escaped by third-party libs in
 Django.

 Refs #7261 -- Made strings escaped by Django usable in third-party libs.

 The changes in mark_safe and mark_for_escaping are straightforward. The
 more tricky part is to handle correctly objects that implement __html__.

 Historically escape() has escaped SafeData. Even if that doesn't seem a
 good behavior, changing it would create security concerns. Therefore
 support for __html__() was only added to conditional_escape() where this
 concern doesn't exist.

 Then using conditional_escape() instead of escape() in the Django
 template engine makes it understand data escaped by other libraries.

 Template filter |escape accounts for __html__() when it's available.
 |force_escape forces the use of Django's HTML escaping implementation.

 Here's why the change in render_value_in_context() is safe. Before Django
 1.7 conditional_escape() was implemented as follows:

 if isinstance(text, SafeData):
 return text
 else:
 return escape(text)

 render_value_in_context() never called escape() on SafeData. Therefore
 replacing escape() with conditional_escape() doesn't change the
 autoescaping logic as it was originally intended.

 This change should be backported to Django 1.7 because it corrects a
 feature added in Django 1.7.

 Thanks mitsuhiko for the report.

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

Re: [Django] #7261: Support for html for Library interoperability

2014-12-27 Thread Django

#7261: Support for __html__ for Library interoperability
-+
 Reporter:  mitsuhiko|Owner:  unaizalakain
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  __html__ | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Aymeric Augustin ):

 In [changeset:"3483682749577b4b5a8141a766489d5b460e30e9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3483682749577b4b5a8141a766489d5b460e30e9"
 [1.7.x] Fixed #23831 -- Supported strings escaped by third-party libs in
 Django.

 Refs #7261 -- Made strings escaped by Django usable in third-party libs.

 The changes in mark_safe and mark_for_escaping are straightforward. The
 more tricky part is to handle correctly objects that implement __html__.

 Historically escape() has escaped SafeData. Even if that doesn't seem a
 good behavior, changing it would create security concerns. Therefore
 support for __html__() was only added to conditional_escape() where this
 concern doesn't exist.

 Then using conditional_escape() instead of escape() in the Django
 template engine makes it understand data escaped by other libraries.

 Template filter |escape accounts for __html__() when it's available.
 |force_escape forces the use of Django's HTML escaping implementation.

 Here's why the change in render_value_in_context() is safe. Before Django
 1.7 conditional_escape() was implemented as follows:

 if isinstance(text, SafeData):
 return text
 else:
 return escape(text)

 render_value_in_context() never called escape() on SafeData. Therefore
 replacing escape() with conditional_escape() doesn't change the
 autoescaping logic as it was originally intended.

 This change should be backported to Django 1.7 because it corrects a
 feature added in Django 1.7.

 Thanks mitsuhiko for the report.

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

Re: [Django] #7261: Support for html for Library interoperability

2014-12-27 Thread Django

#7261: Support for __html__ for Library interoperability
-+
 Reporter:  mitsuhiko|Owner:  unaizalakain
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  __html__ | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Aymeric Augustin ):

 In [changeset:"6d52f6f8e688b5c4e70be8352eb02c05fea60e85"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6d52f6f8e688b5c4e70be8352eb02c05fea60e85"
 Fixed #23831 -- Supported strings escaped by third-party libs in Django.

 Refs #7261 -- Made strings escaped by Django usable in third-party libs.

 The changes in mark_safe and mark_for_escaping are straightforward. The
 more tricky part is to handle correctly objects that implement __html__.

 Historically escape() has escaped SafeData. Even if that doesn't seem a
 good behavior, changing it would create security concerns. Therefore
 support for __html__() was only added to conditional_escape() where this
 concern doesn't exist.

 Then using conditional_escape() instead of escape() in the Django
 template engine makes it understand data escaped by other libraries.

 Template filter |escape accounts for __html__() when it's available.
 |force_escape forces the use of Django's HTML escaping implementation.

 Here's why the change in render_value_in_context() is safe. Before Django
 1.7 conditional_escape() was implemented as follows:

 if isinstance(text, SafeData):
 return text
 else:
 return escape(text)

 render_value_in_context() never called escape() on SafeData. Therefore
 replacing escape() with conditional_escape() doesn't change the
 autoescaping logic as it was originally intended.

 This change should be backported to Django 1.7 because it corrects a
 feature added in Django 1.7.

 Thanks mitsuhiko for the report.
 }}}

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

Re: [Django] #23831: mark_safe and mark_for_escaping should account for html

2014-12-27 Thread Django

#23831: mark_safe and mark_for_escaping should account for __html__
---+-
 Reporter:  aaugustin  |Owner:  aaugustin
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  1.7
 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 Aymeric Augustin ):

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


Comment:

 In [changeset:"6d52f6f8e688b5c4e70be8352eb02c05fea60e85"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6d52f6f8e688b5c4e70be8352eb02c05fea60e85"
 Fixed #23831 -- Supported strings escaped by third-party libs in Django.

 Refs #7261 -- Made strings escaped by Django usable in third-party libs.

 The changes in mark_safe and mark_for_escaping are straightforward. The
 more tricky part is to handle correctly objects that implement __html__.

 Historically escape() has escaped SafeData. Even if that doesn't seem a
 good behavior, changing it would create security concerns. Therefore
 support for __html__() was only added to conditional_escape() where this
 concern doesn't exist.

 Then using conditional_escape() instead of escape() in the Django
 template engine makes it understand data escaped by other libraries.

 Template filter |escape accounts for __html__() when it's available.
 |force_escape forces the use of Django's HTML escaping implementation.

 Here's why the change in render_value_in_context() is safe. Before Django
 1.7 conditional_escape() was implemented as follows:

 if isinstance(text, SafeData):
 return text
 else:
 return escape(text)

 render_value_in_context() never called escape() on SafeData. Therefore
 replacing escape() with conditional_escape() doesn't change the
 autoescaping logic as it was originally intended.

 This change should be backported to Django 1.7 because it corrects a
 feature added in Django 1.7.

 Thanks mitsuhiko for the report.
 }}}

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

Re: [Django] #24052: Document how to use models from other apps in RunPython

2014-12-27 Thread Django

Comment (by iambibhas):

I recently faced this when migrating a model which had an FK to a custom
user model. The custom user model was added in the migration 0002 of my
accounts app. I had to manually add `0002_migration_name` to the
dependency list for the migration to work, otherwise it'd just complain
that it can't find the custom user model. The user models migration was
not added to the dependency list automatically. I'll check if I can
reproduce this. This happened during the migration that was reported in
#24037.

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

Re: [Django] #24000: create_default_site 'db' kwarg should be 'using'

2014-12-27 Thread Django

#24000: create_default_site 'db' kwarg should be 'using'
-+-
 Reporter:  tkhyn|Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  contrib.sites|  Version:  1.7
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  sites multidb| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"a79012f6d88a8cd67bd35c54b91d826f2b7a4cb2"]:
 {{{
 #!CommitTicketReference repository=""
 revision="a79012f6d88a8cd67bd35c54b91d826f2b7a4cb2"
 [1.7.x] Fixed #24000 -- Corrected contrib.sites default site creation in a
 multiple database setup.

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

Re: [Django] #23745: Migrations migrate is slow

2014-12-27 Thread Django

#23745: Migrations migrate is slow
--+
 Reporter:  claudep   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Release blocker   |   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by timgraham):

 I did some research, and I can hit the logic in question:
 {{{
 if app_label == settings.AUTH_USER_MODEL and ignore_swappable:
continue
 }}}
 on both master and with Claude's patch if I follow the steps in this
 comment: https://code.djangoproject.com/ticket/22563#comment:8

 Andrew first added an error message saying that changing `AUTH_USER_MODEL`
 after creating an initial migration was invalid:
 
https://github.com/django/django/commit/fc974313b85da932a70f1f993b33207d78d31831

 and then someone reporting hitting that error with a false positive and he
 changed it to the current version:
 
https://github.com/django/django/commit/5182efce8d73ec552a1d7f3e86a24369bb261044

 His comment was "I've committed a patch that suppresses the error in that
 one case (where we know it's safe to do so), and I can now switch
 `AUTH_USER_MODEL` even midway through a migration set without 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/065.2a6c72e1c29dfdb278173171a544199d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23929: More tests for create_default_site

2014-12-27 Thread Django

#23929: More tests for create_default_site
-+-
 Reporter:  wrwrwr   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.sites|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"965a999ae5a03ca595f3842feacfbce5dc12f20a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="965a999ae5a03ca595f3842feacfbce5dc12f20a"
 [1.7.x] Fixed #23929 -- Added more tests for create_default_site.

 Backport of 1f98ec2e53e4636863396ab54f671f4546f9ba4c 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.46318500bde56c132ba329d5ebe84cdf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22279: AttributeError: 'db.backends.dummy.base.DatabaseWrapper' object has no attribute 'Database'

2014-12-27 Thread Django

#22279: AttributeError: 'db.backends.dummy.base.DatabaseWrapper' object has no
attribute 'Database'
-+-
 Reporter:  blueyed  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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
-+-
Changes (by claudep):

 * has_patch:  0 => 1


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

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

Re: [Django] #24000: create_default_site 'db' kwarg should be 'using'

2014-12-27 Thread Django

#24000: create_default_site 'db' kwarg should be 'using'
-+-
 Reporter:  tkhyn|Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  contrib.sites|  Version:  1.7
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  sites multidb| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"89e2c60f4396241c667b7a1de37765b7c96d702f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="89e2c60f4396241c667b7a1de37765b7c96d702f"
 Fixed #24000 -- Corrected contrib.sites default site creation in a
 multiple database setup.
 }}}

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

Re: [Django] #22340: Legacy Table Creation Methods Not Properly Deprecated

2014-12-27 Thread Django

#22340: Legacy Table Creation Methods Not Properly Deprecated
-+
 Reporter:  mlavin   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by timgraham):

 The remaining work for this ticket seems to be to replace the documented
 `django.db.connection.creation` methods (`create_test_db()` and
 `destroy_test_db()`) with a `SchemaEditor` equivalent. I think all of the
 `DatabaseCreation` methods that deal with generating SQL don't need to go
 through a deprecation cycle as they will be unused in Django 1.9 when
 support for apps without migrations is removed.

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

Re: [Django] #24051: Tables are not created in specified tablespace when DEFAULT_TABLESPACE is specified

2014-12-27 Thread Django

#24051: Tables are not created in specified tablespace when DEFAULT_TABLESPACE 
is
specified
-+-
 Reporter:  douglasjreynolds |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  Tablespace model | 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 Claude Paroz ):

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


Comment:

 In [changeset:"322560489b2d2f873c7b8bd7799efd7cf80fb28b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="322560489b2d2f873c7b8bd7799efd7cf80fb28b"
 [1.7.x] Fixed #24051 -- Made schema infrastructure honor tablespaces

 Partial backport of 30cbd5d36. Thanks Douglas J. Reynolds for the
 report and initial patch.
 }}}

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

Re: [Django] #24000: create_default_site 'db' kwarg should be 'using'

2014-12-27 Thread Django

#24000: create_default_site 'db' kwarg should be 'using'
-+-
 Reporter:  tkhyn|Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  contrib.sites|  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  sites multidb| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Actually, it doesn't seem that a backwards compatibility shim is required.

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

Re: [Django] #24000: create_default_site 'db' kwarg should be 'using'

2014-12-27 Thread Django

#24000: create_default_site 'db' kwarg should be 'using'
-+-
 Reporter:  tkhyn|Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  contrib.sites|  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  sites multidb| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * owner:  nobody => timgraham
 * status:  new => assigned
 * version:  master => 1.7


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

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

Re: [Django] #24051: Tables are not created in specified tablespace when DEFAULT_TABLESPACE is specified

2014-12-27 Thread Django

#24051: Tables are not created in specified tablespace when DEFAULT_TABLESPACE 
is
specified
-+-
 Reporter:  douglasjreynolds |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  Tablespace model | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #14180: Creating redundant indexes on foreign keys for MySQL/InnoDB tables

2014-12-27 Thread Django

#14180: Creating redundant indexes on foreign keys  for MySQL/InnoDB tables
-+-
 Reporter:  zimnyx   |Owner:  Claude
 Type:   |  Paroz 
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Claude Paroz ):

 * owner:   => Claude Paroz 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"2ceb10f3b02cbebad6ed908880f49a7c3e901d12"]:
 {{{
 #!CommitTicketReference repository=""
 revision="2ceb10f3b02cbebad6ed908880f49a7c3e901d12"
 Fixed #14180 -- Prevented unneeded index creation on MySQL-InnoDB

 Thanks zimnyx for the report and Simon Charette, Tim Graham for
 the reviews.
 }}}

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

Re: [Django] #24051: Tables are not created in specified tablespace when DEFAULT_TABLESPACE is specified

2014-12-27 Thread Django

#24051: Tables are not created in specified tablespace when DEFAULT_TABLESPACE 
is
specified
-+-
 Reporter:  douglasjreynolds |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  Tablespace model | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * needs_tests:  1 => 0


Comment:

 Alternate patch without creating new tests:
 https://github.com/django/django/pull/3798

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

Re: [Django] #24056: Syntax highlighting does not work

2014-12-27 Thread Django

#24056: Syntax  highlighting does not work
--+
 Reporter:  AmiZya|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by claudep):

 * stage:  Unreviewed => Accepted


Comment:

 Seems like the parser doesn't like a class definition formed by a single
 code comment (a docstring should be ok).

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

Re: [Django] #24056: Syntax highlighting does not work

2014-12-27 Thread Django

#24056: Syntax  highlighting does not work
-+-
 Reporter:  AmiZya   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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:  1|UI/UX:  0
-+-
Changes (by AmiZya):

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


Comment:

 Tried it on Safari, Firefox 34 , and Chrome 39 on Mac OS X.

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

[Django] #24056: Syntax highlighting does not work

2014-12-27 Thread Django

#24056: Syntax  highlighting does not work
--+
 Reporter:  AmiZya|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 The syntax  highlighting does not work in this place:
 
https://docs.djangoproject.com/en/dev/topics/testing/tools/#django.test.SimpleTestCase.client_class

 Tried to look at the code and can't find anything suspicious...

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

Re: [Django] #23753: Provide a set of SQL functions

2014-12-27 Thread Django

#23753: Provide a set of SQL functions
-+-
 Reporter:  jarshwah |Owner:  jarshwah
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  expressions  | 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 Josh Smeaton ):

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


Comment:

 In [changeset:"47182965465f47657cbab6858a6a8637cc32b2df"]:
 {{{
 #!CommitTicketReference repository=""
 revision="47182965465f47657cbab6858a6a8637cc32b2df"
 Fixed #23753 -- Added a suite of SQL Functions

 Added functions and tests
 Added docs and more tests
 Added TextField converter to mysql backend
 Aliased Value as V in example docs and tests
 Removed unicode_compatible in example
 Fixed console emulation in examples
 }}}

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

46 matches

Mail list logo