[Django] #21775: No facility to specify the datafile of a django test Oracle tablespace

[Django]

#21775: No facility to specify the datafile of a django test Oracle tablespace
--+
 Reporter:  smeatonj  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 There is no way to customise the name of the datafile for the Oracle test
 database. This is required for RAC installations which use shared storage.
 I propose a new option to the DATABASES dict:

 {{{
 'TEST_TBLSPACE_DATAFILE': '',
 'TEST_TBLSPACE_TMP_DATAFILE': '',
 }}}

 Without these options, it is impossible to test against RAC, so I'm
 classifying it as a bug rather than a new feature.

 And the existing code that creates the tablespaces:

 {{{
 # django/db/backends/oracle/creation.py
 def _execute_test_db_creation(self, cursor, parameters, verbosity):
 if verbosity >= 2:
 print("_create_test_db(): dbname = %s" % parameters['dbname'])
 statements = [
 """CREATE TABLESPACE %(tblspace)s
DATAFILE '%(tblspace)s.dbf' SIZE 20M
REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 200M
 """,
 """CREATE TEMPORARY TABLESPACE %(tblspace_temp)s
TEMPFILE '%(tblspace_temp)s.dbf' SIZE 20M
REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 100M
 """,
 ]
 self._execute_statements(cursor, statements, parameters,
 verbosity)
 }}}

 Since not many people have access to an Oracle RAC installation, I'll
 throw together a patch in the near future.

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

[Django] #21774: Running some test labels individually results in PendingDeprecationWarnings

[Django]

#21774: Running some test labels individually results in 
PendingDeprecationWarnings
-+
   Reporter:  mjtamlyn   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Try {{{python -Wall runtests.py file_uploads}}}

 This seems to be because `tests/urls.py` includes urls from
 `admin_widgets` which has models imported, which are not installed.

 The easy fix would be to ensure every model in `admin_widgets` and
 `file_uploads` specifies an `app_label`. The better fix would be to get
 rid of the global `tests.urls` file in favour of `TestCase.urls`, at least
 for these two app labels.

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

Re: [Django] #21721: Python 3.4 support

[Django]

#21721: Python 3.4 support
-+
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  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
-+

Old description:

> Python 3.4 support should be added in master ready for 1.7, and probably
> also in 1.6.X as Py3.4 will be out before Django 1.7. As Py3.4 comes with
> bundled pip and venv, and is a prime target for new python developers and
> those running classes, it is very important for Django to support it.
>
> I've run the test suite (on sqlite) against 1.6.X and master. A test run
> on 1.6.X can be seen at https://gist.github.com/mjtamlyn/8195542
>
> The current state of things is as follows:
>
> - There are a couple of warnings printed at startup time. These relate to
> API changes in plistlib (which is OSX specific) and codecs (universal
> newlines reading of files has been deprecated).
> - ~~Our usage of `HTMLParser` should now always specify the value of
> `convert_charrefs` as it's default will change in Py3.5. This is slightly
> problematic as Py2.7 does not have this kwarg so we can't universally
> apply it. Perhaps the best option is a six-like wrapper.~~
> - `django.utils.module_loading. module_has_submodule` has some issues
> with eggs.  `sys.meta_path` is giving us `importlib` as a finder.
> `importlib.find_module` is deferred to `importlib.find_spec` (new in
> py3.4), which throws an error (`ImportError: spec missing loader`).
> - ~~There is a failing test in the mail library regarding encoding in the
> mail module. Florian seemed to know about this.~~
> - ~~There is a significant issue with signal deregistration. I've been
> able to ascertain that something is up in the `django.dispatch.saferef`
> module, but I don't have a sufficient understanding to work out what's
> wrong. There seems to be no test which tests this code directly and
> failures are thrown up at random during tests, test teardown and/or test
> suite teardown. They show up either as `NoneType is not callable` or as
> `catching classes that do not inherit from BaseException is not
> allowed`.~~
> - `U` mode has been deprecated for files. We use it in `makemessages` and
> in `sql`, both for management commands. It seems unnecessary in
> `makemessages`, in the `sql` we will have to be more careful as at
> present we split on `\n`, which may need to be `\r\n` on windows.
> However, it may well be fine anyway it probably doesn't matter if we have
> trailing `\r` characters on the sql statements.
> - There are quite a lot of `ResourceWarning`s thrown for unclosed files
> ~~(and sockets in the mail tests)~~

New description:

 Python 3.4 support should be added in master ready for 1.7, and probably
 also in 1.6.X as Py3.4 will be out before Django 1.7. As Py3.4 comes with
 bundled pip and venv, and is a prime target for new python developers and
 those running classes, it is very important for Django to support it.

 I've run the test suite (on sqlite) against 1.6.X and master. A test run
 on 1.6.X can be seen at https://gist.github.com/mjtamlyn/8195542

 The current state of things is as follows:

 - ~~There are a couple of warnings printed at startup time. These relate
 to API changes in plistlib (which is OSX specific) and codecs (universal
 newlines reading of files has been deprecated).~~
 - ~~Our usage of `HTMLParser` should now always specify the value of
 `convert_charrefs` as it's default will change in Py3.5. This is slightly
 problematic as Py2.7 does not have this kwarg so we can't universally
 apply it. Perhaps the best option is a six-like wrapper.~~
 - `django.utils.module_loading. module_has_submodule` has some issues with
 eggs.  `sys.meta_path` is giving us `importlib` as a finder.
 `importlib.find_module` is deferred to `importlib.find_spec` (new in
 py3.4), which throws an error (`ImportError: spec missing loader`).
 - ~~There is a failing test in the mail library regarding encoding in the
 mail module. Florian seemed to know about this.~~
 - ~~There is a significant issue with signal deregistration. I've been
 able to ascertain that something is up in the `django.dispatch.saferef`
 module, but I don't have a sufficient understanding to work out what's
 wrong. There seems to be no test which tests this code directly and
 failures are thrown up at random during tests, test teardown and/or test
 suite teardown. They show up either as `NoneType is not callable` or as
 `catching classes that do not inherit from BaseExceptio

Re: [Django] #21721: Python 3.4 support

[Django]

#21721: Python 3.4 support
-+
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  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
-+

Old description:

> Python 3.4 support should be added in master ready for 1.7, and probably
> also in 1.6.X as Py3.4 will be out before Django 1.7. As Py3.4 comes with
> bundled pip and venv, and is a prime target for new python developers and
> those running classes, it is very important for Django to support it.
>
> I've run the test suite (on sqlite) against 1.6.X and master. A test run
> on 1.6.X can be seen at https://gist.github.com/mjtamlyn/8195542
>
> The current state of things is as follows:
>
> - There are a couple of warnings printed at startup time. These relate to
> API changes in plistlib (which is OSX specific) and codecs (universal
> newlines reading of files has been deprecated).
> - Our usage of `HTMLParser` should now always specify the value of
> `convert_charrefs` as it's default will change in Py3.5. This is slightly
> problematic as Py2.7 does not have this kwarg so we can't universally
> apply it. Perhaps the best option is a six-like wrapper.
> - `django.utils.module_loading. module_has_submodule` has some issues
> with eggs.  `sys.meta_path` is giving us `importlib` as a finder.
> `importlib.find_module` is deferred to `importlib.find_spec` (new in
> py3.4), which throws an error (`ImportError: spec missing loader`).
> - ~~There is a failing test in the mail library regarding encoding in the
> mail module. Florian seemed to know about this.~~
> - ~~There is a significant issue with signal deregistration. I've been
> able to ascertain that something is up in the `django.dispatch.saferef`
> module, but I don't have a sufficient understanding to work out what's
> wrong. There seems to be no test which tests this code directly and
> failures are thrown up at random during tests, test teardown and/or test
> suite teardown. They show up either as `NoneType is not callable` or as
> `catching classes that do not inherit from BaseException is not
> allowed`.~~
> - `U` mode has been deprecated for files. We use it in `makemessages` and
> in `sql`, both for management commands. It seems unnecessary in
> `makemessages`, in the `sql` we will have to be more careful as at
> present we split on `\n`, which may need to be `\r\n` on windows.
> However, it may well be fine anyway it probably doesn't matter if we have
> trailing `\r` characters on the sql statements.
> - There are quite a lot of `ResourceWarning`s thrown for unclosed files
> (and sockets in the mail tests)

New description:

 Python 3.4 support should be added in master ready for 1.7, and probably
 also in 1.6.X as Py3.4 will be out before Django 1.7. As Py3.4 comes with
 bundled pip and venv, and is a prime target for new python developers and
 those running classes, it is very important for Django to support it.

 I've run the test suite (on sqlite) against 1.6.X and master. A test run
 on 1.6.X can be seen at https://gist.github.com/mjtamlyn/8195542

 The current state of things is as follows:

 - There are a couple of warnings printed at startup time. These relate to
 API changes in plistlib (which is OSX specific) and codecs (universal
 newlines reading of files has been deprecated).
 - ~~Our usage of `HTMLParser` should now always specify the value of
 `convert_charrefs` as it's default will change in Py3.5. This is slightly
 problematic as Py2.7 does not have this kwarg so we can't universally
 apply it. Perhaps the best option is a six-like wrapper.~~
 - `django.utils.module_loading. module_has_submodule` has some issues with
 eggs.  `sys.meta_path` is giving us `importlib` as a finder.
 `importlib.find_module` is deferred to `importlib.find_spec` (new in
 py3.4), which throws an error (`ImportError: spec missing loader`).
 - ~~There is a failing test in the mail library regarding encoding in the
 mail module. Florian seemed to know about this.~~
 - ~~There is a significant issue with signal deregistration. I've been
 able to ascertain that something is up in the `django.dispatch.saferef`
 module, but I don't have a sufficient understanding to work out what's
 wrong. There seems to be no test which tests this code directly and
 failures are thrown up at random during tests, test teardown and/or test
 suite teardown. They show up either as `NoneType is not callable` or as
 `catching classes that do not inherit from BaseException is not
 al

[django/django] 9d2c5b: Undelete the `return True` removed in 4e0a2fe.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9d2c5b0420bcbf00505a403241a2927cabc90805
  
https://github.com/django/django/commit/9d2c5b0420bcbf00505a403241a2927cabc90805
  Author: Marc Tamlyn 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/core/mail/backends/smtp.py
M tests/mail/tests.py

  Log Message:
  ---
  Undelete the `return True` removed in 4e0a2fe.

This is quite important otherwise we don't close our connections to the
SMTP server.


  Commit: 22198e6ce5be070e727b5c5ef45374a5af048018
  
https://github.com/django/django/commit/22198e6ce5be070e727b5c5ef45374a5af048018
  Author: Marc Tamlyn 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M tests/mail/tests.py

  Log Message:
  ---
  Be more careful about closing connections in mail tests.


Compare: https://github.com/django/django/compare/89f12c0596db...22198e6ce5be

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

[django/django] 89f12c: Add further workarounds for HTMLParser with Python...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 89f12c0596db201c7d052120d4337a36bc0aab17
  
https://github.com/django/django/commit/89f12c0596db201c7d052120d4337a36bc0aab17
  Author: Marc Tamlyn 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/utils/html_parser.py

  Log Message:
  ---
  Add further workarounds for HTMLParser with Python 3.4.

Python 3.5 will change the default value of convert_charrefs, so 3.4
gives warnings if it's not present. This is slightly technical as 2.7
doesn't have the kwarg. Thankfully, we already have a bunch of
workarounds for different versions.


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

Re: [Django] #21721: Python 3.4 support

[Django]

#21721: Python 3.4 support
-+
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  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 mjtamlyn):

 I've done a draft approach for suppressing the `ResourceWarning`s in
 `core.mail`. We can use `closing(get_connection())` in most cases in the
 tests and in `Message.send()`, but we use a custom context manager in the
 main utilities as we may already have a `connection` object. We do not
 want to close passed-in connections, that's the responsibility of whoever
 passed them in. Interestingly, the SMTP backend claims that just calling
 `send_messages` on it will close itself. It seems that on python 3.4 at
 least it does not.

 See diff at https://github.com/mjtamlyn/django/compare/mail-connection-
 wrappers. `auto_connection` is a rubbish name, but it is a utility only
 needed in this module.

 If we're happy with this approach, we should change the mail docs to
 recommend doing `with closing(get_connection())` where `get_connection()`
 is used, and add a note in the release notes that connections will now be
 closed. Ideally, I'd like to remove the implicit closing in
 `send_messages` in the SMTP backend. It seems weird, but also unreliable
 as the implementation does not close the connection should the message
 fail.

 In other news, I committed the `HTMLParser` fix.

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

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

[Django] #21773: development server sometimes takes a long time to restart after source has been changed

[Django]

#21773: development server sometimes takes a long time to restart after source 
has
been changed
---+
 Reporter:  clime  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 There are cases when development server takes a long time to restart after
 sources have been changed. It happens when an exception has been raised. I
 fix the exception and refresh the page but it keeps throwing the same
 error. I usually kill the server with ctrl-c to restart it manually. But
 then comes another problem when I try to start it, that is: "Error: That
 port is already in use." Django server does not release the port when
 being killed. Would it be possible to release it so I can start it
 immediately?

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

Re: [Django] #18726: Combination of F() expression with query seems to confuse sql compiler's table aliases

[Django]

#18726: Combination of F() expression with query seems to confuse sql compiler's
table aliases
-+-
 Reporter:  bugs@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.4
  (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|
-+-

Comment (by jonaskoelker):

 Here's a test case for `tests/queries/tests.py`:

 {{{
 def test_ticket_18726(self):
 a = ObjectA.objects.create(name="alpha")
 b = ObjectB.objects.create(name="beta", objecta=a, num=int())
 c = ObjectC.objects.create(name="charlie", objectb=b,
 objecta=None)

 def test(*args, **kwds):
 ObjectB.objects.filter(*args, **kwds).count()
 try: ObjectB.objects.exclude(*args, **kwds).count()
 except DatabaseError as e: self.fail(repr(e))

 test(objecta__objectb__name='beta')
 test(objectc__objectb__name=F('name'))
 #test(objecta__objectb__name=F('name'))

 test(objecta__objectb__name=F('objecta__name'))
 test(objecta__objectb__name=F('objecta__objectb__name'))
 test(objecta__objectb__name=F('objectc__objectb__name'))
 test(objecta__objectb__name=F('objectc__objectb__objecta__name'))
 #test(objecta__objectb__name=F('objectc__name'))

 test(name=F('objecta__objectb__name'))
 test(objecta__name=F('objecta__objectb__name'))
 #test(objectc__name=F('objecta__objectb__name'))

 }}}

 The commented-out lines exhibit the error.  The other ones don't.

 The first failure (`test(objecta__objectb__name=F('name'))`) goes away if
 you do this:

 {{{
 --- a/django/db/models/sql/query.py
 +++ b/django/db/models/sql/query.py
 @@ -1882,7 +1882,7 @@ class Query(object):   # in `trim_start`
  if self.alias_map[self.tables[pos + 1]].join_type != self.LOUTER:
  select_fields = [r[0] for r in join_field.related_fields]
  select_alias = self.tables[pos + 1]
 -self.unref_alias(self.tables[pos])
 +# self.unref_alias(self.tables[pos])
  extra_restriction = join_field.get_extra_restriction(
  self.where_class, None, self.tables[pos + 1])
  if extra_restriction:
 }}}

 Note that `self.alias_refcount['U1'] == 0` for some `self` of type
 `Query`, at some point during the execution of the first test case (if you
 don't comment out the unreffing).  The stuff in `trim_start` before
 `unref_alias` looks like it *might* be implicated, but I can't tell for
 sure.  Also, even if you comment out `unref_alias` the other two failures
 remain.

 Also, observe that you don't need a many-to-many relationship if you do a
 reverse lookup on a foreign key (but `path.m2m` is still true in
 `trim_start`).

 I hope this helps :-)

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

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

[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 mjtamlyn):

 It's worth noting that `imp.find_module` is the only one of these which is
 used in the source code (4 times), the others are only used in tests. Two
 of the uses in the main codebase are in a function which needs rewriting
 as it's about the old `sys.path` hackery from the old project layout, and
 we've already decided we are willing to *maybe* break some stuff there.
 There's already a `TODO` to this effect.

 The others are in `module_loading` and we will need to write a separate
 path for py3+

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

Re: [Django] #21638: Infinite migrations when using AUTH_USER_MODEL

[Django]

#21638: Infinite migrations when using AUTH_USER_MODEL
+
 Reporter:  patrick@…   |Owner:
 Type:  Bug |   Status:  new
Component:  Migrations  |  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 patrick@…):

 In django/db/migrations/autodetector.py line 241, the old version of the
 username field is compared against the current username field. Both the
 old and new username fields have their own separate instance of a
 django.core.validators.RegexValidator. The two RegexValidator objects have
 the exact same values, but because they are separate instances and do not
 have a comparison function they always compare as unequal.

 Some possible solutions:

 1) Ignore validators when comparing fields. My understanding is that the
 validators only affect data and do not influence the database schema, but
 I haven't fully explored their usage. I believe something similar was
 proposed and turned down in ticket #21275 because the validators may still
 be useful during the migration process.

 2) Add an {{{__eq__}}} function to the RegexValidator class. This is quick
 and easy, but the other validator classes may need this also to prevent
 the same error in the future.

 I'd be willing to contribute a patch, but I don't want to prescribe a
 solution without feedback from maintainers who understand the overall
 system better than I do.

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

Re: [Django] #21770: Management commands autocomplete broken

[Django]

#21770: Management commands autocomplete broken
-+-
 Reporter:  dfunckt  |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  app-loading  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"0a7588dd3f5ec5beef0298389661e78fd63ad6a6"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0a7588dd3f5ec5beef0298389661e78fd63ad6a6"
 Fixed #21770 -- Updated autocomplete for app-loading.

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

[django/django] 0a7588: Fixed #21770 -- Updated autocomplete for app-loadi...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 0a7588dd3f5ec5beef0298389661e78fd63ad6a6
  
https://github.com/django/django/commit/0a7588dd3f5ec5beef0298389661e78fd63ad6a6
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/core/management/__init__.py

  Log Message:
  ---
  Fixed #21770 -- Updated autocomplete for app-loading.

Thanks dfunckt for the report.


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

[django/django] d56252: Fixed #21477 -- Renamed db to using in pre/post_mi...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d562527a160f420c6af0d2736ad4e6c87b0d2ef1
  
https://github.com/django/django/commit/d562527a160f420c6af0d2736ad4e6c87b0d2ef1
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/contrib/auth/management/__init__.py
M django/contrib/contenttypes/management.py
M django/core/management/sql.py
M django/db/models/signals.py
M docs/ref/signals.txt
M tests/migrate_signals/tests.py

  Log Message:
  ---
  Fixed #21477 -- Renamed db to using in pre/post_migrate signals.


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

Re: [Django] #21477: Rename pre/post_migrate argument db to using

[Django]

#21477: Rename pre/post_migrate argument db to using
--+
 Reporter:  akaariai  |Owner:  syphar
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Migrations|  Version:  master
 Severity:  Release blocker   |   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"d562527a160f420c6af0d2736ad4e6c87b0d2ef1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d562527a160f420c6af0d2736ad4e6c87b0d2ef1"
 Fixed #21477 -- Renamed db to using in pre/post_migrate signals.
 }}}

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

Re: [Django] #21770: Management commands autocomplete broken

[Django]

#21770: Management commands autocomplete broken
-+-
 Reporter:  dfunckt  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  app-loading  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by dfunckt):

 I tried the patch and it works here too. FWIW, I personally didn't see any
 noticeable difference in autocompletion delay, though the project I tried
 it on has only about 15-20 models including Django's.

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

Re: [Django] #21477: Rename pre/post_migrate argument db to using

[Django]

#21477: Rename pre/post_migrate argument db to using
--+
 Reporter:  akaariai  |Owner:  syphar
 Type:  Cleanup/optimization  |   Status:  assigned
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:  1 |UI/UX:  0
--+

Comment (by aaugustin):

 I've restored pre/post_syncdb and made pre/post_migrate a different set of
 signals since this discussion.

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

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

[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 aaugustin):

 The app registry no longer uses the import lock, but there's still 5 uses
 of `imp.find_module`, one of `imp.load_module` and one of
 `imp.new_module`.

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

Re: [Django] #18251: multithreading deadlock in django.models.loading.get_apps

[Django]

#18251: multithreading deadlock in django.models.loading.get_apps
-+-
 Reporter:  harm |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  0|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"d674fe6dee16735dd2670243153326806b7e6cb0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d674fe6dee16735dd2670243153326806b7e6cb0"
 Used a regular lock for app registry population.

 Since the app registry is always populated before the first request is
 processed, the situation described in #18251 for the old app cache
 cannot happen any more.

 Refs #18251, #21628.
 }}}

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

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

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

[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 Aymeric Augustin ):

 In [changeset:"d674fe6dee16735dd2670243153326806b7e6cb0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d674fe6dee16735dd2670243153326806b7e6cb0"
 Used a regular lock for app registry population.

 Since the app registry is always populated before the first request is
 processed, the situation described in #18251 for the old app cache
 cannot happen any more.

 Refs #18251, #21628.
 }}}

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

[django/django] d674fe: Used a regular lock for app registry population.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d674fe6dee16735dd2670243153326806b7e6cb0
  
https://github.com/django/django/commit/d674fe6dee16735dd2670243153326806b7e6cb0
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/apps/registry.py
M django/utils/module_loading.py

  Log Message:
  ---
  Used a regular lock for app registry population.

Since the app registry is always populated before the first request is
processed, the situation described in #18251 for the old app cache
cannot happen any more.

Refs #18251, #21628.


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

Re: [Django] #21770: Management commands autocomplete broken

[Django]

#21770: Management commands autocomplete broken
-+-
 Reporter:  dfunckt  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  app-loading  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 An alternative would be to import only apps, not models.

 I'm reluctant to add this to the app registry for the sole purpose of
 autocompletion.

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

Re: [Django] #21721: Python 3.4 support

[Django]

#21721: Python 3.4 support
-+
 Reporter:  mjtamlyn |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Python 3 |  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
-+

Old description:

> Python 3.4 support should be added in master ready for 1.7, and probably
> also in 1.6.X as Py3.4 will be out before Django 1.7. As Py3.4 comes with
> bundled pip and venv, and is a prime target for new python developers and
> those running classes, it is very important for Django to support it.
>
> I've run the test suite (on sqlite) against 1.6.X and master. A test run
> on 1.6.X can be seen at https://gist.github.com/mjtamlyn/8195542
>
> The current state of things is as follows:
>
> - There are a couple of warnings printed at startup time. These relate to
> API changes in plistlib (which is OSX specific) and codecs (universal
> newlines reading of files has been deprecated).
> - Our usage of `HTMLParser` should now always specify the value of
> `convert_charrefs` as it's default will change in Py3.5. This is slightly
> problematic as Py2.7 does not have this kwarg so we can't universally
> apply it. Perhaps the best option is a six-like wrapper.
> - `django.utils.module_loading. module_has_submodule` has some issues
> with eggs.  `sys.meta_path` is giving us `importlib` as a finder.
> `importlib.find_module` is deferred to `importlib.find_spec` (new in
> py3.4), which throws an error (`ImportError: spec missing loader`).
> - There is a failing test in the mail library regarding encoding in the
> mail module. Florian seemed to know about this.
> - There is a significant issue with signal deregistration. I've been able
> to ascertain that something is up in the `django.dispatch.saferef`
> module, but I don't have a sufficient understanding to work out what's
> wrong. There seems to be no test which tests this code directly and
> failures are thrown up at random during tests, test teardown and/or test
> suite teardown. They show up either as `NoneType is not callable` or as
> `catching classes that do not inherit from BaseException is not allowed`.

New description:

 Python 3.4 support should be added in master ready for 1.7, and probably
 also in 1.6.X as Py3.4 will be out before Django 1.7. As Py3.4 comes with
 bundled pip and venv, and is a prime target for new python developers and
 those running classes, it is very important for Django to support it.

 I've run the test suite (on sqlite) against 1.6.X and master. A test run
 on 1.6.X can be seen at https://gist.github.com/mjtamlyn/8195542

 The current state of things is as follows:

 - There are a couple of warnings printed at startup time. These relate to
 API changes in plistlib (which is OSX specific) and codecs (universal
 newlines reading of files has been deprecated).
 - Our usage of `HTMLParser` should now always specify the value of
 `convert_charrefs` as it's default will change in Py3.5. This is slightly
 problematic as Py2.7 does not have this kwarg so we can't universally
 apply it. Perhaps the best option is a six-like wrapper.
 - `django.utils.module_loading. module_has_submodule` has some issues with
 eggs.  `sys.meta_path` is giving us `importlib` as a finder.
 `importlib.find_module` is deferred to `importlib.find_spec` (new in
 py3.4), which throws an error (`ImportError: spec missing loader`).
 - ~~There is a failing test in the mail library regarding encoding in the
 mail module. Florian seemed to know about this.~~
 - ~~There is a significant issue with signal deregistration. I've been
 able to ascertain that something is up in the `django.dispatch.saferef`
 module, but I don't have a sufficient understanding to work out what's
 wrong. There seems to be no test which tests this code directly and
 failures are thrown up at random during tests, test teardown and/or test
 suite teardown. They show up either as `NoneType is not callable` or as
 `catching classes that do not inherit from BaseException is not
 allowed`.~~
 - `U` mode has been deprecated for files. We use it in `makemessages` and
 in `sql`, both for management commands. It seems unnecessary in
 `makemessages`, in the `sql` we will have to be more careful as at present
 we split on `\n`, which may need to be `\r\n` on windows. However, it may
 well be fine anyway it probably doesn't matter if we have trailing `\r`
 characters on the sql statements.
 - There are quite a lot of `ResourceWarning`s thrown for unclosed files
 (and sockets in the mail tests)

--

Comment

[Django] #21772: additional context for included templates can override current context

[Django]

#21772: additional context for included templates can override current context
-+
 Reporter:  clime7@… |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.6
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Hey,

 here is how:

 base.html
 {{{
 {{ foo }} 
 {% include evil_snippet.html foo='bar' %}
 {{ foo }} 
 }}}

 evil_snippet.html
 {{{
 {% context_updater %}
 }}}

 @register.simple_tag(takes_context=True)
 def context_updater(context, template):
 context.update({'resistance': 'is futile'}) # adds new context layer
 that is not accounted 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/059.5c6ad30862f38f4daa39f45fae52dac7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21770: Management commands autocomplete broken

[Django]

#21770: Management commands autocomplete broken
-+-
 Reporter:  dfunckt  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  app-loading  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 The following patch fixes the issue:

 {{{
 diff --git a/django/core/management/__init__.py
 b/django/core/management/__init__.py
 index 6d0cb7e..b6a7d53 100644
 --- a/django/core/management/__init__.py
 +++ b/django/core/management/__init__.py
 @@ -376,7 +376,6 @@ class ManagementUtility(object):
  parser = LaxOptionParser(usage="%prog subcommand [options]
 [args]",
   version=get_version(),
   option_list=BaseCommand.option_list)
 -self.autocomplete()
  try:
  options, args = parser.parse_args(self.argv)
  handle_default_options(options)
 @@ -391,6 +390,8 @@ class ManagementUtility(object):
  else:
  django.setup()

 +self.autocomplete()
 +
  try:
  subcommand = self.argv[1]
  except IndexError:
 }}}

 It also makes autocompletion much slower. In order to discover management
 commands in applications referenced by an AppConfig in INSTALLED_APPS, one
 must populate the app registry, and that's slow.

 I don't see how we can avoid 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.a976fd1b3d2fa3e77aad283737e275bf%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is set to False.

[Django]

#21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is
set to False.
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"225a6ed2cfecc609760a36c3b20369daeec52e07"]:
 {{{
 #!CommitTicketReference repository=""
 revision="225a6ed2cfecc609760a36c3b20369daeec52e07"
 Fixed a test that was failing with PostGIS.

 Fixed #21452 again.

 Forward-port of 18d75e07 from stable/1.6.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/067.fa3a2ce990866304e137a61fe2dd8014%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 225a6e: Fixed a test that was failing with PostGIS.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 225a6ed2cfecc609760a36c3b20369daeec52e07
  
https://github.com/django/django/commit/225a6ed2cfecc609760a36c3b20369daeec52e07
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M tests/backends/tests.py

  Log Message:
  ---
  Fixed a test that was failing with PostGIS.

Fixed #21452 again.

Forward-port of 18d75e07 from stable/1.6.x.


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

[django/django] 18d75e: [1.6.x] Fixed a test that was failing with PostGIS...

[GitHub]

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: 18d75e079245d7ba789d69eacda2aaf7603d678e
  
https://github.com/django/django/commit/18d75e079245d7ba789d69eacda2aaf7603d678e
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M tests/backends/tests.py

  Log Message:
  ---
  [1.6.x] Fixed a test that was failing with PostGIS.

Fixed #21452 again.


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

Re: [Django] #21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is set to False.

[Django]

#21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is
set to False.
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | 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 Aymeric Augustin ):

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


Comment:

 In [changeset:"18d75e079245d7ba789d69eacda2aaf7603d678e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="18d75e079245d7ba789d69eacda2aaf7603d678e"
 [1.6.x] Fixed a test that was failing with PostGIS.

 Fixed #21452 again.
 }}}

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

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

Re: [Django] #21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is set to False.

[Django]

#21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is
set to False.
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | 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 aaugustin):

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


Comment:

 Reopening because the test fails under PostGIS:

 - http://ci.djangoproject.com/job/Django%201.6/469/
 - http://ci.djangoproject.com/job/Django/3834/

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

[django/django] 720c6d: Restored a test broken by overzealous PEP8 cleanup

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 720c6d3a44f5a723854e5eda4e963155b136582f
  
https://github.com/django/django/commit/720c6d3a44f5a723854e5eda4e963155b136582f
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M tests/backends/tests.py

  Log Message:
  ---
  Restored a test broken by overzealous PEP8 cleanup


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

Re: [Django] #21453: Set autocommit mode before calling init_connection_state

[Django]

#21453: Set autocommit mode before calling init_connection_state
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Aymeric Augustin ):

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


Comment:

 In [changeset:"fbe1abac4af3a7fc138bd176471e36acb1070a58"]:
 {{{
 #!CommitTicketReference repository=""
 revision="fbe1abac4af3a7fc138bd176471e36acb1070a58"
 Fixed #21453 -- Enabled autocommit before calling init_connection_state.

 Also ensured the transaction state is clean on Oracle while I was there.

 This change cannot be backported to 1.6 because it's
 backwards-incompatible for custom database backends.
 }}}

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

[django/django] fbe1ab: Fixed #21453 -- Enabled autocommit before calling ...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: fbe1abac4af3a7fc138bd176471e36acb1070a58
  
https://github.com/django/django/commit/fbe1abac4af3a7fc138bd176471e36acb1070a58
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/db/backends/__init__.py
M django/db/backends/oracle/base.py
M django/db/backends/postgresql_psycopg2/base.py
M docs/releases/1.7.txt

  Log Message:
  ---
  Fixed #21453 -- Enabled autocommit before calling init_connection_state.

Also ensured the transaction state is clean on Oracle while I was there.

This change cannot be backported to 1.6 because it's
backwards-incompatible for custom database backends.


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

Re: [Django] #21386: admindocs 'views' section depends on SITE_ID setting

[Django]

#21386: admindocs 'views' section depends on SITE_ID setting
--+
 Reporter:  ramiro|Owner:  bouke
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admindocs |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by anonymous):

 That works perfectly on my setup. Thanks for the hint.

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

Re: [Django] #21769: Error message displayed falsely in poll tutorial

[Django]

#21769: Error message displayed falsely in poll tutorial
---+--
 Reporter:  timdaman   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.6
 Severity:  Normal |   Resolution:  invalid
 Keywords:  tutorial   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 The `vote` view in the tutorial is only meant to be used as the form
 action url, not for the initial display. The initial display of the poll
 is handled by the `detail` view on part 3 of the tutorial. The `except`
 path in the `vote` view is there to prevent the view from crashing if it
 is inadvertently called by a GET method, but it should generally not
 happen.

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

Re: [Django] #21768: TemplateView doc describes context incorrectly

[Django]

#21768: TemplateView doc describes context incorrectly
---+
 Reporter:  nedbatchelder  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by claudep):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #21768: TemplateView doc describes context incorrectly

[Django]

#21768: TemplateView doc describes context incorrectly
---+--
 Reporter:  nedbatchelder  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 Would that change make sense?
 {{{
 -* ``params``: The dictionary of keyword arguments captured from the
 URL
 -  pattern that served the view.
 +* Populated with keyword arguments captured from the URL pattern that
 +  served the view (through
 :class:`django.views.generic.base.ContextMixin`).
 }}}

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

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

Re: [Django] #21453: Set autocommit mode before calling init_connection_state

[Django]

#21453: Set autocommit mode before calling init_connection_state
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Being aware of transactions means ending `init_connection_state` with:

 {{{
 # Ensure all changes are preserved even when AUTOCOMMIT is False.
 if not self.get_autocommit():
 self.commit()
 }}}

 I think that's fine.

 I'm going to run `init_connection_state` in the mode prescribed by the
 settings because it's the most reasonable expectation.

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

[django/django] c72659: Fixed flake8 issues.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: c726598c3da5320df88a10fc407f8df6874589b1
  
https://github.com/django/django/commit/c726598c3da5320df88a10fc407f8df6874589b1
  Author: Simon Charette 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/dispatch/dispatcher.py
M setup.cfg
M tests/backends/tests.py

  Log Message:
  ---
  Fixed flake8 issues.


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

Re: [Django] #21770: Management commands autocomplete broken

[Django]

#21770: Management commands autocomplete broken
-+-
 Reporter:  dfunckt  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  app-loading  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * keywords:  AppConfig, admin_script, manage, django-admin => app-loading
 * owner:  nobody => aaugustin
 * status:  new => assigned


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

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

Re: [Django] #21770: Management commands autocomplete broken

[Django]

#21770: Management commands autocomplete broken
-+-
 Reporter:  dfunckt  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:  AppConfig,   |  Needs documentation:  0
  admin_script, manage, django-  |  Patch needs improvement:  0
  admin  |UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * severity:  Normal => Release blocker
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

Re: [Django] #21453: Set autocommit mode before calling init_connection_state

[Django]

#21453: Set autocommit mode before calling init_connection_state
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.6
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Finally I handled #21452 first because I wanted to backport it to 1.6.

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

Re: [Django] #21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is set to False.

[Django]

#21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is
set to False.
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"cb4a000adbb750da62daab318a9f4da8e3d4fdcd"]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb4a000adbb750da62daab318a9f4da8e3d4fdcd"
 [1.6.x] Fixed #21452 -- Non-autocommit connections to PostgreSQL.

 When settings.DATABASES['default']['AUTOCOMMIT'] = False, the connection
 wasn't in autocommit mode but Django pretended it was.

 Thanks Anssi for analysing this issue.

 Refs #17062.

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

Re: [Django] #17062: Using postgres, if you rollback the first transaction on a connection, the effect of settings.TIME_ZONE is lost

[Django]

#17062: Using postgres, if you rollback the first transaction on a connection, 
the
effect of settings.TIME_ZONE is lost
-+-
 Reporter:  mwhudson |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"cb4a000adbb750da62daab318a9f4da8e3d4fdcd"]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb4a000adbb750da62daab318a9f4da8e3d4fdcd"
 [1.6.x] Fixed #21452 -- Non-autocommit connections to PostgreSQL.

 When settings.DATABASES['default']['AUTOCOMMIT'] = False, the connection
 wasn't in autocommit mode but Django pretended it was.

 Thanks Anssi for analysing this issue.

 Refs #17062.

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

[django/django] b79bf9: [1.6.x] Fixed a test isolation issue. Refs #17062.

[GitHub]

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: b79bf9c7a9c1bc0e3cf0c5c4b0d8191a3033530b
  
https://github.com/django/django/commit/b79bf9c7a9c1bc0e3cf0c5c4b0d8191a3033530b
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M tests/backends/tests.py

  Log Message:
  ---
  [1.6.x] Fixed a test isolation issue. Refs #17062.

This test could change settings.DATABASES['default']['TIME_ZONE'] and
didn't restore the previous value.

Backport of 1c24096f from master.


  Commit: cb4a000adbb750da62daab318a9f4da8e3d4fdcd
  
https://github.com/django/django/commit/cb4a000adbb750da62daab318a9f4da8e3d4fdcd
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/db/backends/postgresql_psycopg2/base.py
M tests/backends/tests.py

  Log Message:
  ---
  [1.6.x] Fixed #21452 -- Non-autocommit connections to PostgreSQL.

When settings.DATABASES['default']['AUTOCOMMIT'] = False, the connection
wasn't in autocommit mode but Django pretended it was.

Thanks Anssi for analysing this issue.

Refs #17062.

Backport of 1afe7488 from master


Compare: https://github.com/django/django/compare/6728f159f060...cb4a000adbb7

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

Re: [Django] #17062: Using postgres, if you rollback the first transaction on a connection, the effect of settings.TIME_ZONE is lost

[Django]

#17062: Using postgres, if you rollback the first transaction on a connection, 
the
effect of settings.TIME_ZONE is lost
-+-
 Reporter:  mwhudson |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"b79bf9c7a9c1bc0e3cf0c5c4b0d8191a3033530b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b79bf9c7a9c1bc0e3cf0c5c4b0d8191a3033530b"
 [1.6.x] Fixed a test isolation issue. Refs #17062.

 This test could change settings.DATABASES['default']['TIME_ZONE'] and
 didn't restore the previous value.

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

[django/django] 52cad4: Fixed removal of signal receivers in Python 3.4

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 52cad43bc3d3126fcf7e08582373c12e88895cd3
  
https://github.com/django/django/commit/52cad43bc3d3126fcf7e08582373c12e88895cd3
  Author: Florian Apolloner 
  Date:   2014-01-09 (Thu, 09 Jan 2014)

  Changed paths:
M django/dispatch/dispatcher.py
R django/dispatch/saferef.py
A django/dispatch/weakref_backports.py
R tests/dispatch/tests/test_saferef.py

  Log Message:
  ---
  Fixed removal of signal receivers in Python 3.4

Make use of `weakref.finalize` and `weakref.WeakMethod` on python 3.4.
Simplified the removal of receivers, the old function looked overly
complicated.

Many thanks go to Antoine Pitrou for helping me to debug and explain all
the failures I ran into while writing that patch.


  Commit: 7959aff8be437f6cc9cbab2cdae86a6aad24f925
  
https://github.com/django/django/commit/7959aff8be437f6cc9cbab2cdae86a6aad24f925
  Author: Florian Apolloner 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M MANIFEST.in
A django/dispatch/license.python.txt
M django/dispatch/weakref_backports.py

  Log Message:
  ---
  Added license info for the weakref backports


  Commit: 56ab5f52c717ad9f54f94b09b6c61568f612ba6b
  
https://github.com/django/django/commit/56ab5f52c717ad9f54f94b09b6c61568f612ba6b
  Author: Florian Apolloner 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M MANIFEST.in
M django/dispatch/dispatcher.py
A django/dispatch/license.python.txt
R django/dispatch/saferef.py
A django/dispatch/weakref_backports.py
R tests/dispatch/tests/test_saferef.py

  Log Message:
  ---
  Merge pull request #2163 from apollo13/signals

Signals


Compare: https://github.com/django/django/compare/1afe7488322f...56ab5f52c717

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

Re: [Django] #17062: Using postgres, if you rollback the first transaction on a connection, the effect of settings.TIME_ZONE is lost

[Django]

#17062: Using postgres, if you rollback the first transaction on a connection, 
the
effect of settings.TIME_ZONE is lost
-+-
 Reporter:  mwhudson |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"1c24096f1e860960fa44df937713528065b5f79a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1c24096f1e860960fa44df937713528065b5f79a"
 Fixed a test isolation issue. Refs #17062.

 This test could change settings.DATABASES['default']['TIME_ZONE'] and
 didn't restore the previous value.
 }}}

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

Re: [Django] #17062: Using postgres, if you rollback the first transaction on a connection, the effect of settings.TIME_ZONE is lost

[Django]

#17062: Using postgres, if you rollback the first transaction on a connection, 
the
effect of settings.TIME_ZONE is lost
-+-
 Reporter:  mwhudson |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"1afe7488322f9b53ea00f47fb07c4374a5f2150e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1afe7488322f9b53ea00f47fb07c4374a5f2150e"
 Fixed #21452 -- Non-autocommit connections to PostgreSQL.

 When settings.DATABASES['default']['AUTOCOMMIT'] = False, the connection
 wasn't in autocommit mode but Django pretended it was.

 Thanks Anssi for analysing this issue.

 Refs #17062.
 }}}

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

[django/django] 1c2409: Fixed a test isolation issue. Refs #17062.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1c24096f1e860960fa44df937713528065b5f79a
  
https://github.com/django/django/commit/1c24096f1e860960fa44df937713528065b5f79a
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M tests/backends/tests.py

  Log Message:
  ---
  Fixed a test isolation issue. Refs #17062.

This test could change settings.DATABASES['default']['TIME_ZONE'] and
didn't restore the previous value.


  Commit: 1afe7488322f9b53ea00f47fb07c4374a5f2150e
  
https://github.com/django/django/commit/1afe7488322f9b53ea00f47fb07c4374a5f2150e
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/db/backends/postgresql_psycopg2/base.py
M tests/backends/tests.py

  Log Message:
  ---
  Fixed #21452 -- Non-autocommit connections to PostgreSQL.

When settings.DATABASES['default']['AUTOCOMMIT'] = False, the connection
wasn't in autocommit mode but Django pretended it was.

Thanks Anssi for analysing this issue.

Refs #17062.


Compare: https://github.com/django/django/compare/9918c4ac...1afe7488322f

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

Re: [Django] #21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is set to False.

[Django]

#21452: Connections may be set to autocommit under PostgreSQL when AUTOCOMMIT is
set to False.
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | 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 Aymeric Augustin ):

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


Comment:

 In [changeset:"1afe7488322f9b53ea00f47fb07c4374a5f2150e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="1afe7488322f9b53ea00f47fb07c4374a5f2150e"
 Fixed #21452 -- Non-autocommit connections to PostgreSQL.

 When settings.DATABASES['default']['AUTOCOMMIT'] = False, the connection
 wasn't in autocommit mode but Django pretended it was.

 Thanks Anssi for analysing this issue.

 Refs #17062.
 }}}

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

[Django] #21771: ModelAdmin's log_deletion method behaves incorrectly compared to other log methods

[Django]

#21771: ModelAdmin's log_deletion method behaves incorrectly compared to other 
log
methods
-+
 Reporter:  Keryn Knight   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.admin|Version:  master
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 The current implementation of
 
[https://github.com/django/django/blob/8f04f53dd847896f49a9bc367bb7269984ebdb6e/django/contrib/admin/options.py#L713
 log_deletion] makes use of `self.model` to figure out the appropriate
 `content_type`, even though `object` is passed in. The `log_addition` and
 `log_change` methods correctly use the provided object to ascertain the
 type.
 I can only assume that at some point obj wasn't intended/guaranteed to
 exist at the point `log_deletion` is called, but in both places it's used
 
([https://github.com/django/django/blob/8f04f53dd847896f49a9bc367bb7269984ebdb6e/django/contrib/admin/options.py#L1580
 ModelAdmin.delete_view],
 
[https://github.com/django/django/blob/17c66e6fe77bc5eb2bd9e6f8f032a105d3cac3d7/django/contrib/admin/actions.py#L48,
 actions.delete_selected]) there is already a requirement (or at least an
 assumption) that the object exists.

 I consider this to be a bug, because it means that the following use case
 doesn't work, which is how I came across it:
 {{{
 class MyModelAdmin(ModelAdmin):
 def log_deletion(self, request, object, object_repr):
 super(MyModelAdmin, self).log_deletion(request, object,
 object_repr)
 super(MyModelAdmin, self).log_deletion(request,
 object.content_object, object_repr)
 }}}
 where `object.content_object` is a GFK back to the "owner" of the object.
 Instead of getting two deletion messages, to the instance and the
 GFK/parent, you end up with two for the instance, because the content_type
 of the GFK/parent is never used.

 The equivalent code for the `log_addition` and `log_change` methods
 appears to work.

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

[Django] #21770: Management commands autocomplete broken

[Django]

#21770: Management commands autocomplete broken
-+-
 Reporter:  dfunckt  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (Management |Version:  master
  commands)  |   Keywords:  AppConfig,
 Severity:  Normal   |  admin_script, manage, django-admin
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 Tabbing for command autocompletion in manage.py raises the following
 error:

 {{{
 $ ./manage.py sql

 Traceback (most recent call last):
   File "./manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "//src/django/django/core/management/__init__.py", line
 426, in execute_from_command_line
 utility.execute()
   File "//src/django/django/core/management/__init__.py", line
 379, in execute
 self.autocomplete()
   File "//src/django/django/core/management/__init__.py", line
 326, in autocomplete
 subcommands = list(get_commands()) + ['help']
   File "//bin/../lib/python3.3/functools.py", line 251, in
 wrapper
 result = user_function(*args, **kwds)
   File "//src/django/django/core/management/__init__.py", line
 118, in get_commands
 app_configs = apps.get_app_configs()
   File "//src/django/django/apps/registry.py", line 121, in
 get_app_configs
 self.check_ready()
   File "//src/django/django/apps/registry.py", line 115, in
 check_ready
 raise RuntimeError("App registry isn't ready yet.")
 RuntimeError: App registry isn't ready yet.
 }}}

 Bringing the issue up in #django-dev, mjtamlyn suggested moving the
 try/catch with django.setup() block to the beginning of
 ManagementUtility.execute() method, which fixed the issue. However, the
 change broke the test suite, specifically many tests from
 test_admin_scripts.

 I'm not at all familiar with that (huge) part of the test suite, so i'm
 not sure how to go about it, even though i'm willing to help.

 Python 3.3, Django@9918c4ac3

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

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

[Django] #21769: Error message displayed falsely in poll tutorial

[Django]

#21769: Error message displayed falsely in poll tutorial
---+--
 Reporter:  timdaman   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.6
 Severity:  Normal |   Keywords:  tutorial
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+--
 I am working through the tutorial "poll" project and found a very minor
 bug in the example code. In section 4,

 https://docs.djangoproject.com/en/1.6/intro/tutorial04/

 the vote method erroneously displays the error message when the vote form
 is initially loaded. This does not make sense since the user has not yet
 attempted to submit form data. In a real world setting this could cause
 user confusion and frustration as "Looking at a blank form" is != to
 "Submitting a blank form" and the messages each requires is different
 ("Please make a choice" vs. "Oops, you forgot to make a choice").

 Below is the modification I made to detect this difference and display the
 correct output. I am new to django and my last web editing job was in the
 90's so I welcome suggestions for improvements of my code!


 {{{
 def vote(request, poll_id):
 p = get_object_or_404(Poll, pk=poll_id)

 if request.method == "POST":
 try:
 selected_choice = p.choice_set.get(pk=request.POST['choice'])
 except (KeyError, Choice.DoesNotExist):
 # Redisplay the poll voting form.

 return render(request, 'polls/detail.html', {
 'poll': p,
 'error_message': "You didn't select a choice.",
 })

 else:
 selected_choice.votes += 1
 selected_choice.save()
 # Always return an HttpResponseRedirect after successfully
 dealing
 # with POST data. This prevents data from being posted twice
 if a
 # user hits the Back button.
 return HttpResponseRedirect(reverse('polls:results',
 args=(p.id,)))
 else:
 return render(request, 'polls/detail.html', {
 'poll': p,
 })
 }}}

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

[Django] #21768: TemplateView doc describes context incorrectly

[Django]

#21768: TemplateView doc describes context incorrectly
---+
 Reporter:  nedbatchelder  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.6
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 Here: https://docs.djangoproject.com/en/1.6/ref/class-based-
 views/base/#templateview

 The bottom of that section says:

 Context

 params: The dictionary of keyword arguments captured from the URL
 pattern that served the view.

 but the top says:

 Changed in Django 1.5:

 The context used to be populated with a {{ params }} dictionary of the
 parameters captured in the URL. Now those parameters are first-level
 context variables.

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

Re: [Django] #21766: Can't use reverse() or is_valid_path() with dynamically set TestCase.urls (was: Exception with dynamic TestCase.urls and settings.APPEND_SLASH=True)

[Django]

#21766: Can't use reverse() or is_valid_path() with dynamically set 
TestCase.urls
---+--
 Reporter:  paulmelnikow   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  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 paulmelnikow):

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


Comment:

 This issue also seems to affect `reverse()` as well as `is_valid_path()`.
 To test views which require `reverse()`, setting APPEND_SLASH=False won't
 work, so I put the urlconf into the test module instead.

 {{{#!py
 urlpatterns = patterns('',
 url(r'^api-auth/', include('rest_framework.urls',
 namespace='rest_framework')),
 )

 class TestLogin(TestCase):
 urls = 'myapp.tests.test_login'
 }}}

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

Re: [Django] #21413: select_related "row, fields misalignment" in SQLCompiler.fill_related_selections()

[Django]

#21413: select_related "row, fields misalignment" in
SQLCompiler.fill_related_selections()
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  select_related   |  Needs documentation:  0
  parent inheritance subclass|  Patch needs improvement:  0
  oracle |UI/UX:  0
Has patch:  0|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Anssi Kääriäinen ):

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


Comment:

 In [changeset:"9918c4ac3ec9622631558ef26ebf3919cb69"]:
 {{{
 #!CommitTicketReference repository=""
 revision="9918c4ac3ec9622631558ef26ebf3919cb69"
 Fixed #21413 -- resolve_columns fields misalignment
 }}}

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

[django/django] 9918c1: Fixed #21413 -- resolve_columns fields misalignmen...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9918c4ac3ec9622631558ef26ebf3919cb69
  
https://github.com/django/django/commit/9918c4ac3ec9622631558ef26ebf3919cb69
  Author: Anssi Kääriäinen 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M django/contrib/gis/db/models/sql/compiler.py
M django/db/models/sql/compiler.py
M tests/model_inheritance_regress/tests.py

  Log Message:
  ---
  Fixed #21413 -- resolve_columns fields misalignment


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

Re: [Django] #21386: admindocs 'views' section depends on SITE_ID setting

[Django]

#21386: admindocs 'views' section depends on SITE_ID setting
--+
 Reporter:  ramiro|Owner:  bouke
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admindocs |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by bouke):

 By including `SITE_ID=None` in your settings, you should not encounter any
 issues on 1.6. It would be good to provide a fix for 1.6, but backporting
 the fix of 1.7 would introduce changes in the featureset. It might be
 better to include installation instructions for admindocs noting that
 `SITE_ID` should be configured.

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

Re: [Django] #21386: admindocs 'views' section depends on SITE_ID setting

[Django]

#21386: admindocs 'views' section depends on SITE_ID setting
--+
 Reporter:  ramiro|Owner:  bouke
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.admindocs |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by sthzg@…):

 Is there a chance to backport this fix to one of the next 1.6.x minor
 updates? This would leave existing 1.6 installations that don't need the
 sitesframework completely supported and would allow for an easy update
 path to solve the problem.

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

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

Re: [Django] #21765: Contexts cannot be compared for equality.

[Django]

#21765: Contexts cannot be compared for equality.
-+-
 Reporter:  Keryn Knight |Owner:  nobody
   |   Status:  new
 Type:  New feature  |  Version:  master
Component:  Template system  |   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):

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


Comment:

 Seems a reasonable request 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/095.995962a2a40867add2c6a849f317b912%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #21767: Invalid usage of ugettext in BaseForm.__init__

[Django]

#21767: Invalid usage of ugettext in BaseForm.__init__
--+--
 Reporter:  akaariai  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Forms |  Version:  master
 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 mjtamlyn):

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


Comment:

 I don't believe this is an issue. `Form.__init__` is surely not called at
 module time - it's not a metaclasses' `__new__` which is called when the
 form is defined. The method takes `data` and `files` which are naturally
 user specified data, so it must be called during a response cycle.

 Also with the app loading changes to import sequence, these errors tend to
 blow up now if `ugettext` is called at module level.

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

[Django] #21767: Invalid usage of ugettext in BaseForm.__init__

[Django]

#21767: Invalid usage of ugettext in BaseForm.__init__
--+
   Reporter:  akaariai|  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  master
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 The line
 {{{
 self.label_suffix = label_suffix if label_suffix is not None else
 _(':')
 }}}
 in django.forms.forms.BaseForm.__init__ uses ugettext(). To me it seems it
 should use ugettext_lazy as that line will be called when the model is
 defined. This means that the default language is used for translation
 instead of the use-time language. Using ugettext_lazy() should solve 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/051.782ab7e0ae195122c17b557d392f3977%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 9cc337: Fixed #21756 -- Skipped two timezone-related tests...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9cc3371a0f45894de12d2fb60a57afd111fb9c3e
  
https://github.com/django/django/commit/9cc3371a0f45894de12d2fb60a57afd111fb9c3e
  Author: Aymeric Augustin 
  Date:   2014-01-12 (Sun, 12 Jan 2014)

  Changed paths:
M tests/utils_tests/test_dateformat.py

  Log Message:
  ---
  Fixed #21756 -- Skipped two timezone-related tests on Windows.

Windows cannot use a time zone other than the default time zone.

Thanks manfre for the report.


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

Re: [Django] #21756: utils_tests.test_dateformat.DateFormatTests failing on Windows with pytz installed

[Django]

#21756: utils_tests.test_dateformat.DateFormatTests failing on Windows with pytz
installed
-+-
 Reporter:  manfre   |Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Utilities|  Version:  master
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  timezone tzinfo  | Triage Stage:  Accepted
Has patch:  0|  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:"9cc3371a0f45894de12d2fb60a57afd111fb9c3e"]:
 {{{
 #!CommitTicketReference repository=""
 revision="9cc3371a0f45894de12d2fb60a57afd111fb9c3e"
 Fixed #21756 -- Skipped two timezone-related tests on Windows.

 Windows cannot use a time zone other than the default time zone.

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

Re: [Django] #21756: utils_tests.test_dateformat.DateFormatTests failing on Windows with pytz installed

[Django]

#21756: utils_tests.test_dateformat.DateFormatTests failing on Windows with pytz
installed
-+-
 Reporter:  manfre   |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Utilities|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  timezone tzinfo  | 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):

 Affected tests use 'Europe/Copenhagen', which is the same as
 'Europe/Paris'; that's why I didn't notice 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/064.65cbd55635dc91076d5a749ae51f65e9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.