Re: [Django] #14299: Add additional cache.*_many functions

2010-09-21 Thread Django
#14299: Add additional cache.*_many functions
---+
  Reporter:  manfre| Owner:  manfre 
 
Status:  closed| Milestone:  1.3
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:  wontfix   |  Keywords:  cache, add_many, 
offset_many
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by manfre):

 jdunck, thanks for the feedback. I'm not sure it's worth the time to
 update the patch given the wontfix.

 1. Tests in the base mixin run for all of the backends, except dummy.
 2. Agreed.
 3. Unrelated issue see #14315
 4. ok
 5. One set is for the dummy backend and the second set is for the rest of
 them.
 6. ok
 7. ok
 8. A more conforming approach would be to return a dict containing the new
 values. Any keys with errors would be omitted or set to None.

-- 
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-upda...@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] #11077: Django's built-in tests fail when using url reverse tags in default registration templates

2010-09-21 Thread Django
#11077: Django's built-in tests fail when using url reverse tags in default
registration templates
-+--
  Reporter:  srosro  | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Testing framework   |   Version:
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Comment (by berto):

 +1

 I sat down to write some tests on a new application and there's nothing
 more discouraging than to start with failure.  The suggestion by Adam V in
 the django-dev thread was super quick and easy to avoid the problem ...
 only test your own apps ![1]!

 I've peared down the suggestion down to creating a MY_APPS tuple
 containing only my apps and running the tests with:

 {{{
 ./manage.py test $(python -c "import settings; print '
 '.join(settings.MY_APPS)")
 }}}

 ![1] http://groups.google.com/group/django-
 developers/browse_thread/thread/c7eb9930591e3a38#msg_36dbc5a388c5fdb2

-- 
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-upda...@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] #14299: Add additional cache.*_many functions

2010-09-21 Thread Django
#14299: Add additional cache.*_many functions
---+
  Reporter:  manfre| Owner:  manfre 
 
Status:  closed| Milestone:  1.3
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:  wontfix   |  Keywords:  cache, add_many, 
offset_many
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Changes (by jdunck):

  * needs_better_patch:  0 => 1

Comment:

 Feedback as I come across things -- I somehow didn't notice Jacob's
 already wontfix'd this ticket.  Perhaps feedback is useful anyway.  I
 leave Jacob to answer your previous questions.

  1. Did you test against other backends?  I see you've implemented in
 base, but it's not clear to me that base will work in all backends.
  1. Dummy .set_many should return the empty dict rather than None
  1. Why the change to smart_str in memcache incr/decr?  Unrelated issue?
  1. Replace: "``add_many()`` returns a dictionary with all the keys passed
 and their values being a bool indicating whether or not the value was
 added" with "``add_many() returns a dictionary containing all keys passed
 in and boolean values indicating whether the value was added."
  1. test_add_many and test_offset_many are repeated in your diff.  Please
 remove the dupes.
  1. move comment "# add_many takes a second ``timeout`` parameter" below
 the call to delete_many.
  1. In test_add_many, please ensure to test both cases where a key does
 exist and where it does not.
  1. In offset_many, I'm not sure about returning booleans for a failed
 incr/decr. Is this something you've seen in other 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 post to this group, send email to django-upda...@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] #11441: Signal documentation should mention 'weak' parameter for connect

2010-09-21 Thread Django
#11441: Signal documentation should mention 'weak' parameter for connect
+---
  Reporter:  Mike_A | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords:  weak signal
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by gremmie):

 * cc: gremmie (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-upda...@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] #11509: Incorrect capitalisation of web in Widget documentation

2010-09-21 Thread Django
#11509: Incorrect capitalisation of web in Widget documentation
+---
  Reporter:  thepointer | Owner:  dwillis
Status:  assigned   | Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by dwillis):

  * has_patch:  0 => 1
  * version:  1.0 => SVN

-- 
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-upda...@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] #11509: Incorrect capitalisation of web in Widget documentation

2010-09-21 Thread Django
#11509: Incorrect capitalisation of web in Widget documentation
+---
  Reporter:  thepointer | Owner:  dwillis
Status:  assigned   | Milestone: 
 Component:  Documentation  |   Version:  1.0
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by dwillis):

  * owner:  nobody => dwillis
  * 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 post to this group, send email to django-upda...@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] #13747: Post 1.2 Development code wrongly included in 1.2 doc on Custom Management Commands

2010-09-21 Thread Django
#13747: Post 1.2 Development code wrongly included in 1.2 doc on Custom 
Management
Commands
+---
  Reporter:  metamemetics   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution:  fixed  |  Keywords:  Custom Management Commands
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 Perhaps the anonymous re-opener meant to say it should be marked as added
 in 1.3? I have not checked to be sure, but it sounds like now the problem
 may be that reading the dev documentation there is no indication ("new in
 development") that this advice cannot be followed if you are running the
 current official release?

-- 
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-upda...@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] #11561: raw_id_fields requires that the user has change permissions on the model class that is being linked to

2010-09-21 Thread Django
#11561: raw_id_fields requires that the user has change permissions on the model
class that is being linked to
---+
  Reporter:  dhow...@gmail.com | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  django.contrib.admin  |   Version:  1.0
  
Resolution:|  Keywords:  raw_if_fields 
permissions
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by zbyte64):

 Possible fix would be to add a has_view_permission and the changelist_view
 would check against that permission instead of has_change_permission

-- 
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-upda...@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] #13747: Post 1.2 Development code wrongly included in 1.2 doc on Custom Management Commands

2010-09-21 Thread Django
#13747: Post 1.2 Development code wrongly included in 1.2 doc on Custom 
Management
Commands
+---
  Reporter:  metamemetics   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution:  fixed  |  Keywords:  Custom Management Commands
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 No, the docs really don't say that (any more). As of [13364], that text
 was removed from the 1.2 documentation. However, it still exists in the
 "dev" documentation, which reflects the current state of trunk.

-- 
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-upda...@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] #14324: Django not rotating logs

2010-09-21 Thread Django
#14324: Django not rotating logs
-+--
  Reporter:  mikewash| Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Core framework  |   Version:  1.0  
Resolution:  invalid |  Keywords:  rotating logs
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

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

Comment:

 This Trac is for reporting bugs in Django. Currently Django does not even
 use Python logging, so it is hard to see how what you are describing could
 be a bug in Django code. This question would be more likely to get helpful
 responses on either django-users, #django IRC, or possibly a Python list,
 since the logging module comes from Python.

-- 
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-upda...@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] #14323: ModelChoiceField does not catch ValueErrors in to_python()

2010-09-21 Thread Django
#14323: ModelChoiceField does not catch ValueErrors in to_python()
-+--
  Reporter:  mcfletch| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.2   
Resolution:  duplicate   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

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

Comment:

 Duplicate of #11716

-- 
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-upda...@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] #14325: GenericForeignKey fails if assigned to an object which implements the __len__ method

2010-09-21 Thread Django
#14325: GenericForeignKey fails if assigned to an object which implements the
__len__ method
---+
  Reporter:  natano| Owner:  nobody 

Status:  new   | Milestone: 

 Component:  Contrib apps  |   Version:  1.2

Resolution:|  Keywords:  contenttypes, 
genericforeignkey
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  1  

Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14325: GenericForeignKey fails if assigned to an object which implements the __len__ method

2010-09-21 Thread Django
#14325: GenericForeignKey fails if assigned to an object which implements the
__len__ method
-+--
 Reporter:  natano   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Contrib apps | Version:  1.2   
 Keywords:  contenttypes, genericforeignkey  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 Supposing you have a model with a GenericForeignKey:
 {{{
 class Example(models.Model):
 content_type = models.ForeignKey(ContentType)
 object_id = models.PositiveIntegerField()
 instance = generic.GenericForeignKey()
 }}}

 and a model which implements the {{{__len__}}} method:
 {{{
 class Table(models.Model)
 data = models.TextField()

 def __len__(self):
 return 0
 }}}

 If you do
 {{{
 t = Table.object.create()
 e = Example()
 e.instance = t
 }}}
 you get an error:
 {{{
 Impossible arguments to GFK.get_content_type!
 }}}

 I think this is cause by checking for a logical True value instead of a
 "not None" comparison.

-- 
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-upda...@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] #14324: Django not rotating logs

2010-09-21 Thread Django
#14324: Django not rotating logs
-+--
  Reporter:  mikewash| Owner:  nobody   
Status:  new | Milestone:   
 Component:  Core framework  |   Version:  1.0  
Resolution:  |  Keywords:  rotating logs
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by mikewash):

  * needs_better_patch:  => 0
  * 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 post to this group, send email to django-upda...@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] #14324: Django not rotating logs

2010-09-21 Thread Django
#14324: Django not rotating logs
+---
 Reporter:  mikewash|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.0   
 Keywords:  rotating logs   |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 System Information:
 Python 2.5.2
 Apache 2.2
 Windows XP

 I was trying to rotate logs in django but it kept delivering this error
 [Windows Error 32] when running it in the development environment (python
 manage.py runserver). I was curious if there is some way to rotate logs to
 work in sync with the Django Framework.

 Also I placed the code in the settings.py file.

 Here is the code

 {{{
 logger = logging.getLogger("")
 logger.setLevel(logging.DEBUG)
 handler = logging.handlers.RotatingFileHandler(LOG_FILE, maxBytes=20,
 backupCount=5)
 handler.setFormatter(logging.Formatter(LOG_FORMAT))
 logger.addHandler(handler)
 }}}

-- 
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-upda...@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] #14323: ModelChoiceField does not catch ValueErrors in to_python()

2010-09-21 Thread Django
#14323: ModelChoiceField does not catch ValueErrors in to_python()
+---
 Reporter:  mcfletch|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 If you have an integer field reference (common) and a user passes a non-
 integer-coercible data-value such as 'w' (admittedly somewhat uncommon)
 you get a ValueError raised from the depths of the ORM when the QuerySet
 is queried.

 Should catch ValueErrors and raise ValidationErrors to properly report
 errors.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r13865 - in django/branches/releases/1.2.X: django/views/decorators tests/regressiontests/decorators

2010-09-21 Thread noreply
Author: lukeplant
Date: 2010-09-21 14:33:53 -0500 (Tue, 21 Sep 2010)
New Revision: 13865

Modified:
   django/branches/releases/1.2.X/django/views/decorators/cache.py
   django/branches/releases/1.2.X/tests/regressiontests/decorators/tests.py
Log:
[1.2.X] Fixed #12019 - backwards compatibility issues with cache_page decorator.

Thanks to rokclimb15 for the report, and j4mie/rokclimb15 for the patches.

Backport of [13864] from trunk

Modified: django/branches/releases/1.2.X/django/views/decorators/cache.py
===
--- django/branches/releases/1.2.X/django/views/decorators/cache.py 
2010-09-21 19:32:22 UTC (rev 13864)
+++ django/branches/releases/1.2.X/django/views/decorators/cache.py 
2010-09-21 19:33:53 UTC (rev 13865)
@@ -33,6 +33,10 @@
 #   my_view = cache_page(123, key_prefix="foo")(my_view)
 # and possibly this way (?):
 #   my_view = cache_page(123, my_view)
+# and also this way:
+#   my_view = cache_page(my_view)
+# and also this way:
+#   my_view = cache_page()(my_view)
 
 # We also add some asserts to give better error messages in case people are
 # using other ways to call cache_page that no longer work.
@@ -45,9 +49,14 @@
 elif callable(args[1]):
 return 
decorator_from_middleware_with_args(CacheMiddleware)(cache_timeout=args[0], 
key_prefix=key_prefix)(args[1])
 else:
-assert False, "cache_page must be passed either a single argument 
(timeout) or a view function and a timeout"
+assert False, "cache_page must be passed a view function if called 
with two arguments"
+elif len(args) == 1:
+if callable(args[0]):
+return 
decorator_from_middleware_with_args(CacheMiddleware)(key_prefix=key_prefix)(args[0])
+else:
+return 
decorator_from_middleware_with_args(CacheMiddleware)(cache_timeout=args[0], 
key_prefix=key_prefix)
 else:
-return 
decorator_from_middleware_with_args(CacheMiddleware)(cache_timeout=args[0], 
key_prefix=key_prefix)
+return 
decorator_from_middleware_with_args(CacheMiddleware)(key_prefix=key_prefix)
 
 
 def cache_control(**kwargs):

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/decorators/tests.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/decorators/tests.py
2010-09-21 19:32:22 UTC (rev 13864)
+++ django/branches/releases/1.2.X/tests/regressiontests/decorators/tests.py
2010-09-21 19:33:53 UTC (rev 13865)
@@ -112,6 +112,10 @@
 self.assertEqual(my_view_cached(HttpRequest()), "response")
 my_view_cached2 = cache_page(my_view, 123, key_prefix="test")
 self.assertEqual(my_view_cached2(HttpRequest()), "response")
+my_view_cached3 = cache_page(my_view)
+self.assertEqual(my_view_cached3(HttpRequest()), "response")
+my_view_cached4 = cache_page()(my_view)
+self.assertEqual(my_view_cached4(HttpRequest()), "response")
 
 
 # For testing method_decorator, a decorator that assumes a single argument.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r13864 - in django/trunk: django/views/decorators tests/regressiontests/decorators

2010-09-21 Thread noreply
Author: lukeplant
Date: 2010-09-21 14:32:22 -0500 (Tue, 21 Sep 2010)
New Revision: 13864

Modified:
   django/trunk/django/views/decorators/cache.py
   django/trunk/tests/regressiontests/decorators/tests.py
Log:
Fixed #12019 - backwards compatibility issues with cache_page decorator.

Thanks to rokclimb15 for the report, and j4mie/rokclimb15 for the patches.

Modified: django/trunk/django/views/decorators/cache.py
===
--- django/trunk/django/views/decorators/cache.py   2010-09-19 14:05:43 UTC 
(rev 13863)
+++ django/trunk/django/views/decorators/cache.py   2010-09-21 19:32:22 UTC 
(rev 13864)
@@ -33,6 +33,10 @@
 #   my_view = cache_page(123, key_prefix="foo")(my_view)
 # and possibly this way (?):
 #   my_view = cache_page(123, my_view)
+# and also this way:
+#   my_view = cache_page(my_view)
+# and also this way:
+#   my_view = cache_page()(my_view)
 
 # We also add some asserts to give better error messages in case people are
 # using other ways to call cache_page that no longer work.
@@ -45,9 +49,14 @@
 elif callable(args[1]):
 return 
decorator_from_middleware_with_args(CacheMiddleware)(cache_timeout=args[0], 
key_prefix=key_prefix)(args[1])
 else:
-assert False, "cache_page must be passed either a single argument 
(timeout) or a view function and a timeout"
+assert False, "cache_page must be passed a view function if called 
with two arguments"
+elif len(args) == 1:
+if callable(args[0]):
+return 
decorator_from_middleware_with_args(CacheMiddleware)(key_prefix=key_prefix)(args[0])
+else:
+return 
decorator_from_middleware_with_args(CacheMiddleware)(cache_timeout=args[0], 
key_prefix=key_prefix)
 else:
-return 
decorator_from_middleware_with_args(CacheMiddleware)(cache_timeout=args[0], 
key_prefix=key_prefix)
+return 
decorator_from_middleware_with_args(CacheMiddleware)(key_prefix=key_prefix)
 
 
 def cache_control(**kwargs):

Modified: django/trunk/tests/regressiontests/decorators/tests.py
===
--- django/trunk/tests/regressiontests/decorators/tests.py  2010-09-19 
14:05:43 UTC (rev 13863)
+++ django/trunk/tests/regressiontests/decorators/tests.py  2010-09-21 
19:32:22 UTC (rev 13864)
@@ -112,6 +112,10 @@
 self.assertEqual(my_view_cached(HttpRequest()), "response")
 my_view_cached2 = cache_page(my_view, 123, key_prefix="test")
 self.assertEqual(my_view_cached2(HttpRequest()), "response")
+my_view_cached3 = cache_page(my_view)
+self.assertEqual(my_view_cached3(HttpRequest()), "response")
+my_view_cached4 = cache_page()(my_view)
+self.assertEqual(my_view_cached4(HttpRequest()), "response")
 
 
 # For testing method_decorator, a decorator that assumes a single argument.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #13747: Post 1.2 Development code wrongly included in 1.2 doc on Custom Management Commands

2010-09-21 Thread Django
#13747: Post 1.2 Development code wrongly included in 1.2 doc on Custom 
Management
Commands
+---
  Reporter:  metamemetics   | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:  Custom Management Commands
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

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

Comment:

 IMO this feature addition should be marked as added in 1.2, since the doc
 says you should use it: "When you are using management commands and wish
 to provide console output, you should write to self.stdout and
 self.stderr, instead of printing to stdout and stderr directly."

-- 
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-upda...@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] #14309: Spanish translation on deleting objects

2010-09-21 Thread Django
#14309: Spanish translation on deleting objects
---+
  Reporter:  asi...@gmail.com  | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  Translations  |   Version:  1.2  
Resolution:|  Keywords:  Spanish 1.2.x
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by asi...@gmail.com):

 I would like to help with this, but i cant find any Google groups about
 Spanish translation.

-- 
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-upda...@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] #12090: Show admin actions on the edit pages too

2010-09-21 Thread Django
#12090: Show admin actions on the edit pages too
---+
  Reporter:  apollo13  | Owner:  jezdez
Status:  assigned  | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by hamlet):

 Regarding the design issue let me propose to allow for a list of actions
 that are offered as individual buttons on the change page next to 'Save',
 'Save and add another': 'Save and /action/', e.g. via:

 {{{
 class ArticleAdmin(admin.ModelAdmin):
 list_display = ['title', 'status']
 actions = [publish, unpublish, comments_close]
 save_plus_action = [unpublish, comments_close]
 save_plus_action_done = [publish]
 }}}

 As it's unclear whether the list or change page should display after that,
 we would need the secondary option, say {{{save_plus_action_done}}} to
 leave the change page after saving and firing this action.

-- 
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-upda...@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] #5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")

2010-09-21 Thread Django
#5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")
+---
  Reporter:  anonymous  | Owner:  nobody 
Status:  new| Milestone:  1.3
 Component:  Forms  |   Version:  SVN
Resolution: |  Keywords:  sprintdec01
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * milestone:  => 1.3

Comment:

 How about we slate it for 1.3 then. Get some discussion going in django-
 dev group to get things rolling.

-- 
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-upda...@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] #14322: Please set default values for required and error css classes

2010-09-21 Thread Django
#14322: Please set default values for required and error css classes
---+
 Reporter:  dfoerster  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I'm very happy about the fix for #3512 which makes it possible to set css
 classe to be used for required or errornous form rows. However, there are
 no default values set and thus it's still required to adapt all form
 classes used in a project.

 Adding default values would make it much easier to format generated forms
 and wouldn't hurt anyone not using 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 post to this group, send email to django-upda...@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] #5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")

2010-09-21 Thread Django
#5622: Empty ipaddress raises an error (invalid input syntax for type inet: "")
+---
  Reporter:  anonymous  | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Forms  |   Version:  SVN
Resolution: |  Keywords:  sprintdec01
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by anonymous):

 Same problem as I've duplicated
 [http://code.djangoproject.com/ticket/14321 here] by mistake. No milestone
 set in 3 years? This looks promising :)

-- 
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-upda...@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] #14321: IPAddressField inserted as empty string although null=True

2010-09-21 Thread Django
#14321: IPAddressField inserted as empty string although null=True
---+
  Reporter:  ri...@mail.ru | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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

Comment:

 Sorry for the dupe. Same problem as
 [http://code.djangoproject.com/ticket/5622 here].

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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.