Re: [Django] #9595: Add support for cache to not expire

[Django]

#9595: Add support for cache to not expire
-+-
   Reporter:  keseldude  |  Owner:  otherjacob
   Type:  New| Status:  new
  feature|  Component:  Core (Cache system)
  Milestone:  1.4|   Severity:  Normal
Version:  1.0|   Keywords:  cache timeout
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  1
  decision needed|  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by ed@…):

 * cc: ed@… (added)
 * ui_ux:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16722 - in django/trunk: django/test tests/regressiontests/settings_tests

[noreply]

Author: ramiro
Date: 2011-09-04 15:51:53 -0700 (Sun, 04 Sep 2011)
New Revision: 16722

Modified:
   django/trunk/django/test/utils.py
   django/trunk/tests/regressiontests/settings_tests/tests.py
Log:
Also copy `__module__` to our dynamically created TestCase subclass when 
override_settings acts as a class decorator.

Otherwise, an error in e.g. a test in 
tests/modeltests/proxy_model_inheritance/tests.py
was being reported as:

ERROR: test_table_exists (django.test.utils.ProxyModelInheritanceTests)

Refs #16672 and [16650].

Modified: django/trunk/django/test/utils.py
===
--- django/trunk/django/test/utils.py   2011-09-04 22:42:11 UTC (rev 16721)
+++ django/trunk/django/test/utils.py   2011-09-04 22:51:53 UTC (rev 16722)
@@ -211,6 +211,7 @@
 {
 '_pre_setup': _pre_setup,
 '_post_teardown': _post_teardown,
+'__module__': test_func.__module__,
 })
 else:
 @wraps(test_func)

Modified: django/trunk/tests/regressiontests/settings_tests/tests.py
===
--- django/trunk/tests/regressiontests/settings_tests/tests.py  2011-09-04 
22:42:11 UTC (rev 16721)
+++ django/trunk/tests/regressiontests/settings_tests/tests.py  2011-09-04 
22:51:53 UTC (rev 16722)
@@ -18,6 +18,9 @@
 def test_decorated_testcase_name(self):
 self.assertEquals(FullyDecoratedTranTestCase.__name__, 
'FullyDecoratedTranTestCase')
 
+def test_decorated_testcase_module(self):
+self.assertEquals(FullyDecoratedTranTestCase.__module__, __name__)
+
 FullyDecoratedTranTestCase = 
override_settings(TEST='override')(FullyDecoratedTranTestCase)
 
 # @override_settings(TEST='override')

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16672: Preserve name of TestCase decorated with override_settings

[Django]

#16672: Preserve name of TestCase decorated with override_settings
-+-
   Reporter:  julien |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Testing framework
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by ramiro):

 In [16722]:
 {{{
 #!CommitTicketReference repository="" revision="16722"
 Also copy `__module__` to our dynamically created TestCase subclass when
 override_settings acts as a class decorator.

 Otherwise, an error in e.g. a test in
 tests/modeltests/proxy_model_inheritance/tests.py
 was being reported as:

 ERROR: test_table_exists (django.test.utils.ProxyModelInheritanceTests)

 Refs #16672 and [16650].
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r16721 - django/trunk/docs/faq

[noreply]

Author: ramiro
Date: 2011-09-04 15:42:11 -0700 (Sun, 04 Sep 2011)
New Revision: 16721

Modified:
   django/trunk/docs/faq/install.txt
Log:
Fixed typo in PEP number introduced in last commit. Thanks Jannis for the eagle 
eyes.

Modified: django/trunk/docs/faq/install.txt
===
--- django/trunk/docs/faq/install.txt   2011-09-04 21:17:30 UTC (rev 16720)
+++ django/trunk/docs/faq/install.txt   2011-09-04 22:42:11 UTC (rev 16721)
@@ -23,7 +23,7 @@
 For a development environment -- if you just want to experiment with Django --
 you don't need to have a separate Web server installed; Django comes with its
 own lightweight development server. For a production environment, Django 
follows
-the WSGI spec, :pep:``, which means it can run on a variety of server
+the WSGI spec, :pep:`333`, which means it can run on a variety of server
 platforms. See :doc:`Deploying Django ` for some
 popular alternatives. Also, the `server arrangements wiki page`_ contains
 details for several deployment strategies.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16586: Use Sphinx' intersphinx extension to link to Python docs

[Django]

#16586: Use Sphinx' intersphinx extension to link to Python docs
-+-
   Reporter:  jezdez |  Owner:  aaugustin
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ramiro):

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


Comment:

 In [16720]:
 {{{
 #!CommitTicketReference repository="" revision="16720"
 Converted links to external topics so they use intersphinx extension
 markup.

 This allows to make these links more resilent to changes in the target
 URLs.
 Thanks Jannis for the report and Aymeric Augustin for the patch.

 Fixes #16586.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9805: reverse() does not add SCRIPT_NAME to the returned URL if called from middleware modules

[Django]

#9805: reverse() does not add SCRIPT_NAME to the returned URL if called from
middleware modules
+--
   Reporter:  ElliottM  |  Owner:  mtredinnick
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Core (Other)
Version:  1.0   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
Changes (by aaugustin):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 Replying to [comment:2 mtredinnick]:
 > There's a mention in another ticket that we might add a kind of "lazy"
 reverse() that resolves upon usage, rather than declaration. When I find
 that ticket, I'll drop in a comment here and wontfix this one.

 `lazy_reverse` was committed at r16121.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16734: urlresolvers doesn't get a script prefix from manage.py

[Django]

#16734: urlresolvers doesn't get a script prefix from manage.py
-+-
   Reporter:  d00gs  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Management
Version:  1.3|  commands)
 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 aaugustin):

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


Comment:

 Based on code inspection, I confirm that this bug exists.

 Possible fix: `django.core.management.setup_environ` could do something
 along the lines of:

 {{{
 from django.conf import settings
 from django.core.management.base import set_script_prefix
 from django.utils.encoding import force_unicode

 set_script_prefix(u'/' if settings.FORCE_SCRIPT_NAME is None else
 force_unicode(settings.FORCE_SCRIPT_NAME))
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16739: field clash not detected beyond parent

[Django]

#16739: field clash not detected beyond parent
-+-
   Reporter:  Leo|  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I confirm the bug. With this code in a `models.py`:
 {{{
 class GrandParent(models.Model):
 number = models.IntegerField()

 class Parent(GrandParent):
 pass

 class Child(Parent):
 number = models.IntegerField()
 }}}

 Expected result of `./manage.py validate`:
 {{{
 FieldError: Local field 'number' in class 'Child' clashes with field of
 similar name from base class 'GrandParent'
 }}}

 Actual result: no error.

 I tried to write a test case in `invalid_models`, but that didn't work
 because the name clash creates an exception, not a validation error.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16558: django.contrib.humanize filters are not well localized

[Django]

#16558: django.contrib.humanize filters are not well localized
--+---
   Reporter:  blackraven  |  Owner:  blackraven
   Type:  Bug | Status:  closed
  Milestone:  1.4 |  Component:  contrib.humanize
Version:  1.3 |   Severity:  Normal
 Resolution:  fixed   |   Keywords:  russian, humanize
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by anonymous):

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


Comment:

 ps.
 Just looked in SVN - looks like it was fixed at r16168.
 I'm using older version.
 Thanks jezdez for fixing - sorry for disturbing:)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16558: django.contrib.humanize filters are not well localized

[Django]

#16558: django.contrib.humanize filters are not well localized
--+---
   Reporter:  blackraven  |  Owner:  blackraven
   Type:  Bug | Status:  reopened
  Milestone:  1.4 |  Component:  contrib.humanize
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:  russian, humanize
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by anonymous):

 * status:  closed => reopened
 * resolution:  needsinfo =>


Comment:

 Well, here's an example:
 I have the following code in template:

 {obj.price|intcomma}

 If the object price is 2500, the output is:

 '''2,500'''

 disregarding of locale which is RU in my case.

 The problem is, in number of countries
 
(http://en.wikipedia.org/wiki/Decimal_mark#Countries_using_Arabic_numerals_with_decimal_comma)
 comma is decimal separator. So the output above is read as 2.500 ( two and
 five hundred  thousandths ).
 Instead, the decimal separator should be chosen according to locale, and
 in my case it should be just space char, so that my number will look like:
 '''2 500'''
 and any decimal number would look like:
 '''1 234.56'''

 Hope that makes things clear.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16558: django.contrib.humanize filters are not well localized

[Django]

#16558: django.contrib.humanize filters are not well localized
--+---
   Reporter:  blackraven  |  Owner:  blackraven
   Type:  Bug | Status:  closed
  Milestone:  1.4 |  Component:  contrib.humanize
Version:  1.3 |   Severity:  Normal
 Resolution:  needsinfo   |   Keywords:  russian, humanize
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by jezdez):

 * status:  reopened => closed
 * resolution:   => needsinfo


Comment:

 I'm not sure what this ticket is reporting, to be honest, except that
 something "is not well localized". Feel free to re-open if you have a
 clear explanation of what you expected you find, but got instead. **Any**
 detail would be much appreciated.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16558: django.contrib.humanize filters are not well localized

[Django]

#16558: django.contrib.humanize filters are not well localized
--+---
   Reporter:  blackraven  |  Owner:  blackraven
   Type:  Bug | Status:  reopened
  Milestone:  1.4 |  Component:  contrib.humanize
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:  russian, humanize
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by blackraven):

 * status:  closed => reopened
 * resolution:  duplicate =>


Comment:

 Not a duplicate of #16562 - it's completely different bug referring to
 USE_THOUSANDS_SEPARATOR, and is has nothing to do with localization of
 separator character.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16748: Documentation on creating custom querysets

[Django]

#16748: Documentation on creating custom querysets
-+-
   Reporter:  lee@…  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_docs:   => 0
 * stage:  Unreviewed => Design decision needed
 * needs_tests:   => 0
 * needs_better_patch:   => 0


Comment:

 The solution described in the blog post requires five lines of boilerplate
 code, which is a blocker for recommending it in the official
 documentation:

 {{{
 class CustomManager(models.Manager):

 def get_query_set(self):
 return CustomQuerySet(self.model)

 def __getattr__(self, name):
 return getattr(self.get_query_set(), name)
 }}}

 Currently, the docs just describe the APIs of `Manager` and `QuerySet`.

 I don't know if there's a general solution to this problem, if we want to
 develop one in Django, or just let each developer figure out what's most
 appropriate in his/her situation.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16645: OldFormForXTests.test_image_field fails under Oracle

[Django]

#16645: OldFormForXTests.test_image_field fails under Oracle
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Forms
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:  oracle
   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):

 IRC discussion about this patch:
 {{{
 2011-08-28 15:36:35  about the test failure with Oracle 11 related
 to a nullable filefield
 2011-08-28 15:37:18  I've been reviewing it. I don't feel
 comfortable with adapting the tests to workaround that
 2011-08-28 15:38:37  I konw there is some recommendation in the
 charfield docs discouraging using null=True, but we have a handful of
 models with FileField's and ImageField with null=tru in out tests, and
 they work correctly
 2011-08-28 15:39:57  ... and a bunch of models with other
 CharField-derived fields also with null=True. In some tests we even test
 for ORM behavior when confronted with the null=Tree
 2011-08-28 15:40:42  cramm: the problem here is that we test that an
 ImageField with no value has its name set to ''
 2011-08-28 15:40:47  So, I'd prefer to see first why things don't
 fail in 10g and fail in 11g
 2011-08-28 15:41:03  but since the field is nullable the result
 should be None
 2011-08-28 15:41:47  the docs don't say exactly how .name is
 supposed to behave, but basically, it's the string stored in the db
 2011-08-28 15:42:46  in short, I agree that I didn't nail the root
 cause, and the expected behavior of .name is underdefined
 2011-08-28 15:43:09  I gree with the latter :)
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16731: startswith and contains doesn't work with F expression

[Django]

#16731: startswith and contains doesn't work with F expression
-+-
   Reporter:  ronnas@…   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  startswith, F(),
Needs documentation:  0  |  wildcards
Patch needs improvement:  0  |  Has patch:  0
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by anonymous):

 This issue also appears in "contains" query and subsequently in
 istartswith and icontains.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16700: The request_started signal is not called for the first request a newly-initialized webserver receives.

[Django]

#16700: The request_started signal is not called for the first request a newly-
initialized webserver receives.
+---
   Reporter:  etianen   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  1.3   |   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):

 This is related to #14916.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14916: No proper initialization of models/signals/etc....

[Django]

#14916: No proper initialization of models/signals/etc
-+--
   Reporter:  Pakal  |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  Core (Other)
Version:  1.2|   Severity:  Normal
 Resolution:  duplicate  |   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 aaugustin):

 * status:  reopened => closed
 * resolution:   => duplicate


Comment:

 Please don't re-open tickets closed by core developers. As explained in
 the contributing guide, you should write to the django-developers mailing
 list instead.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16727: contrib.contenttypes.views.shortcut error

[Django]

#16727: contrib.contenttypes.views.shortcut error
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:
Version:  1.3|  contrib.contenttypes
 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 aaugustin):

 #16753 was opened for the bug in syndication. This one is just about
 contenttypes.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16753: Handle protocol-relative URLs in syndication

[Django]

#16753: Handle protocol-relative URLs in syndication
+-
   Reporter:  cato  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.syndication
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by aaugustin):

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


Comment:

 This bug is described in the comments of #16727.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13873: Provide an explicit setting to skip tests for INSTALLED_APPS

[Django]

#13873: Provide an explicit setting to skip tests for INSTALLED_APPS
-+-
   Reporter: |  Owner:  nobody
  lakinwecker| Status:  new
   Type:  New|  Component:  Testing framework
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by chrischambers):

 For anyone needing a temporary workaround for this issue,
 http://djangosnippets.org/snippets/2211/ is useful (note that the setting
 for excluding apps is TEST_EXCLUDE = [app1, app2]).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13873: Provide an explicit setting to skip tests for INSTALLED_APPS

[Django]

#13873: Provide an explicit setting to skip tests for INSTALLED_APPS
-+-
   Reporter: |  Owner:  nobody
  lakinwecker| Status:  new
   Type:  New|  Component:  Testing framework
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by chrischambers):

 * cc: magma.chambers@… (added)


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14916: No proper initialization of models/signals/etc....

[Django]

#14916: No proper initialization of models/signals/etc
-+--
   Reporter:  Pakal  |  Owner:  nobody
   Type:  Uncategorized  | Status:  reopened
  Milestone: |  Component:  Core (Other)
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--
Changes (by anonymous):

 * status:  closed => reopened
 * severity:   => Normal
 * resolution:  duplicate =>
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Uncategorized


Comment:

 I'm sorry, but this issue is not a duplicate of issue #3591 - which
 doesn't deal with early import of models and signal setup.

 Clearly at server startup, the first http requests are unlikely to trigger
 the import of all install apps, so signals might be issued whereas all
 their listeners aren't yet activated. Same for django models, whose
 relationship tree won't be complete...
 That's a serious workflow issue imo, invalidating the principle of the
 signal system of django.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #16753: Handle protocol-relative URLs in syndication

[Django]

#16753: Handle protocol-relative URLs in syndication
--+-
 Reporter:  cato  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  contrib.syndication
  Version:  SVN   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+-
 When trying to use protocol-relative URLs (see
 [http://tools.ietf.org/html/rfc3986#section-4.2 1] or
 [http://tools.ietf.org/html/rfc3986#section-4.2 2]) like for example
 returned by [https://github.com/jezdez/django-hosts django-hosts] the
 syndication framework prepends the protocol and the domain. This way a
 valid URL is transformed into an invalid or at least useless URL.

 Example:

 {{{
 class MyFeed(Feed):
 def item_link(self, item):
url = reverse_crossdomain("myhost", "myview",
 view_kwargs={'some': 'argument'})
return url
 }}}

 The value of {{{url}}} is "//example.com/path/to/view/" and the rendered
 feed contains {{{http://example.com//example.com/path/to/view/}}}.

 The syndication framework should either just pass the url as it is or
 prepend the protocol. For the case of prepending the protocol a patch is
 attached

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16731: startswith and contains doesn't work with F expression

[Django]

#16731: startswith and contains doesn't work with F expression
-+-
   Reporter:  ronnas@…   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  startswith, F(),
Needs documentation:  0  |  wildcards
Patch needs improvement:  0  |  Has patch:  0
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Old description:

> The expression:
> myTable.objects.filter(field1__startswith=F('field2'))
>
> rendered to:
> SELECT * FROM `my_table` WHERE `my_table`.`field1` LIKE
> `my_table`.`field2`
>
> should be:
> SELECT * FROM `my_table` WHERE `my_table`.`field1` LIKE
> CONCAT(`my_table`.`field2`,'%')

New description:

 The expression:
 {{{
 myTable.objects.filter(field1__startswith=F('field2'))
 }}}
 rendered to:
 {{{
 SELECT * FROM `my_table` WHERE `my_table`.`field1` LIKE
 `my_table`.`field2`
 }}}
 should be:
 {{{
 SELECT * FROM `my_table` WHERE `my_table`.`field1` LIKE
 CONCAT(`my_table`.`field2`,'%')
 }}}

--

Comment:

 Fixed formatting - please use preview.

 I have confirmed the problem as follows:



 {{{
 # todo/models.py

 class Todo(models.Model):
 summary = models.CharField(max_length=100, verbose_name=_('summary'))
 details = models.TextField(blank=True, verbose_name=_('details'))
 }}}


 {{{
 % ./manage.py shell

 >>> from todo.models import *>>> from django.db.models import F
 >>> Todo.objects.filter(details__startswith=F('summary'))
 Traceback (most recent call last):
   File "", line 1, in 
   File "django/db/models/query.py", line 66, in __repr__
 data = list(self[:REPR_OUTPUT_SIZE + 1])
   File "django/db/models/query.py", line 81, in __len__
 self._result_cache.extend(self._iter)
   File "django/db/models/query.py", line 266, in iterator
 for row in compiler.results_iter():
   File "django/db/models/sql/compiler.py", line 699, in results_iter
 for rows in self.execute_sql(MULTI):
   File "django/db/models/sql/compiler.py", line 754, in execute_sql
 cursor.execute(sql, params)
   File "django/db/backends/util.py", line 34, in execute
 return self.cursor.execute(sql, params)
   File "django/db/backends/sqlite3/base.py", line 261, in execute
 return Database.Cursor.execute(self, query, params)
 DatabaseError: near "ESCAPE": syntax error
 >>> from django.db import connection
 >>> connection.queries
 [{'time': '0.000', 'sql': u'SELECT "todo_todo"."id",
 "todo_todo"."summary", "todo_todo"."details" FROM "todo_todo" WHERE
 "todo_todo"."details" LIKE  ESCAPE \'\\\' "todo_todo"."summary" LIMIT
 21'}]
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16727: contrib.contenttypes.views.shortcut error

[Django]

#16727: contrib.contenttypes.views.shortcut error
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:
Version:  1.3|  contrib.contenttypes
 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 aaugustin):

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


Comment:

 By grepping the entire codebase for `startswith\(['"]https?://`, I have
 found this pattern in the following files:

 - `django.contrib.contenttypes.views` (line 25) => it's the bug reported
 here,
 - `django.contrib.syndication.views` (line 11) => it's a similar bug,
 - `django.utils.html` (line 132) => it's debatable, we'd probably better
 not touch this.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16723: Pluralize filter shouldn't pluralize decimal/float values between 1 and 2

[Django]

#16723: Pluralize filter shouldn't pluralize decimal/float values between 1 and 
2
+-
   Reporter:  rfugger   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 The docs say that `pluralize` "returns a plural suffix if the value is not
 1".

 It looks like `int(value)` is only intended to convert a string to an int
 and pluralize wasn't designed to deal with float values.

 An alternative fix could be to change the check to `if str(value) != "1"`.
 Thus 1.0 will be pluralized and it's still a one-liner.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16737: inspectdb does not handle non-ascii column names correctly

[Django]

#16737: inspectdb does not handle non-ascii column names correctly
+-
   Reporter:  moof@…|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  ORM aggregation
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:  inspectdb
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-
Changes (by aaugustin):

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


Comment:

 Non-ASCII identifiers are only supported by Python 3, so we'll have to
 convert the column name to ASCII.

 To fix this, we have to:

 - make sure `inspectdb` writes the file in utf-8
 - add `# coding: utf-8` at the top of the file
 - convert the column name to an ASCII field name, for instance with:
 `unicodedata.normalize('NFKD', column_name).encode('ascii', 'ignore')`
 - set `db_column` on the field

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13562: values() cannot follow reverse one-to-one relationship

[Django]

#13562: values() cannot follow reverse one-to-one relationship
-+-
   Reporter: |  Owner:  nobody
  bendavis78 | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I think this was fixed in 1.3: the docs say:
 > you can now also refer to fields on related models with reverse
 relations through OneToOneField, ForeignKey and ManyToManyField attributes
 [[BR]]

 The patch no longer applies, but I've ported it quickly from doctest to
 unittest (see attachement) and the test passes.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16735: Queryset values should be aliasable

[Django]

#16735: Queryset values should be aliasable
-+-
   Reporter: |  Owner:  nobody
  alex.latchford@…   | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  queryset, alias,
 Resolution: |  values
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Interesting idea. From a quick inspection of the source (`ValuesQuerySet`)
 this looks doable.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16718: check_for_language fails when django are imported from zip file

[Django]

#16718: check_for_language fails when django are imported from zip file
--+--
   Reporter:  jsantana@…  |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Translations
Version:  1.2 |   Severity:  Normal
 Resolution:  duplicate   |   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 aaugustin):

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


Comment:

 Django can't be packaged as a Python egg, in particular because it's hard
 to retrieve the templates and translation files.

 If I understand correctly, by "importing from a zipfile", you mean
 "running from an egg", so it's a duplicate of #596.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16721: Blocktrans does not handle correctly litteral percents (%) in content

[Django]

#16721: Blocktrans does not handle correctly litteral percents (%) in content
+--
   Reporter:  claudep   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:  1.4   |  Component:  Internationalization
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
Changes (by aaugustin):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.