Re: [Django] #17186: Inverted F expression (negation)

[Django]

#17186: Inverted F expression (negation)
-+-
 Reporter:  niwi |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by nate_b):

 Regarding use case for negation on non-boolean values: That's a good
 question; I'm not sure that there is one.  I provided that only as a
 stupid example of lack of composability (at the db level negation on non-
 boolean values can work, but that doesn't mean it is useful).  If you can
 propose a test, I would be glad to include it.  Altogether, though, that
 does raise a good question - so far, all {{{F()}}} objects are generally
 composable across all operations, and I would not want to break that by
 adding another operation.  Not all computations in general are composable,
 though; should {{{F()}}} object composability reflect that?  Now my head
 hurts.

 Regarding "Why ~F() instead of not F()": there are two reasons.  One: To
 match with [https://docs.djangoproject.com/en/dev/topics/db/queries
 /#complex-lookups-with-q-objects Q objects]; Two, and more importantly:
 python itself
 [http://docs.python.org/library/operator.html#operator.__not__ does not
 provide a __not__() method for object instances].  So yes, you are
 absolutely right, but I don't think it can be done.

 As to your other points, well taken.  I hope my updated patch is an
 improvement.

-- 
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] #17631: edge case: django.test.client should handle fields and files with the same name

[Django]

#17631: edge case: django.test.client should handle fields and files with the 
same
name
---+
 Reporter:  dnozay |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 problem:
 - want to upload file with very common name, e.g. 'somefield'
 - want to post data with very common name for field, e.g. 'somefield'

 http://www.scotthawker.com/scott/?p=1892

 http://code.activestate.com/recipes/146306/

 {{{
 >>> fields = { 'somefield': 1 }
 >>> files = { 'somefield': open('/dev/null', 'r') }
 >>> data = QueryDict('', mutable=True)
 >>> data.update(fields)
 >>> data.update(files)
 >>> data
 ]}>
 >>> data.items()
 [(u'somefield', )]
 >>> data
 ]}>
 >>>
 >>> from django.utils.datastructures import MultiValueDict
 >>> data = MultiValueDict()
 >>> data.update(fields)
 >>> data.update(files)
 >>> data
 ]}>
 >>> data.items()
 [('somefield', )]
 >>> data['somefield']
 
 >>> data.getlist('somefield')
 [1, ]
 >>>
 }}}


 https://code.djangoproject.com/browser/django/trunk/django/test/client.py

 {{{
 116 # Each bit of the multipart form data could be either a form
 value or a
 117 # file, or a *list* of form values and/or files. Remember that
 HTTP field
 118 # names can be duplicated!
 119 for (key, value) in data.items():
 }}}

 IMHO, the test client should use data.lists() instead when providing
 MultiValueDict or subclass.

-- 
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] #17585: Not possible to filter authors that have books other than hardcover

[Django]

#17585: Not possible to filter authors that have books other than hardcover
-+-
 Reporter:  mbertheau@…  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by akaariai):

 * status:  new => closed
 * cc: anssi.kaariainen@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => worksforme


Comment:

 Actually, I think it can:
 {{{
 Author.objects.all().delete()
 a = Author.objects.create(name='anssi')
 b = Author.objects.create(name='bart')
 c = Author.objects.create(name='carl')

 book1 = Book.objects.create(bound='hardcover', author=a)
 book2 = Book.objects.create(bound='somethingelse', author=a)
 book3 = Book.objects.create(bound='somethingelse', author=b)
 print
 
Author.objects.filter(pk__in=Book.objects.filter(~Q(bound='hardcover')).values_list('author_id'))
 [, ]
 print
 
Author.objects.filter(pk__in=Book.objects.filter(~Q(bound='hardcover')).values_list('author_id')).query
 SELECT "tests_author"."id", "tests_author"."name" FROM "tests_author"
 WHERE "tests_author"."id" IN (SELECT U0."author_id" FROM "tests_book" U0
 WHERE NOT (U0."bound" = hardcover ))
 }}}

 Or, at least I hope that is what you wanted. The .exclude() can't do what
 you want, it is defined to remove all authors that have any hardcovers. I
 admit that the above query isn't the easiest to discover. This could maybe
 be documented, but I don't think that is a good idea, as:
   - finding this type of query from the documentation is hard.
   - especially as other queries like this would then logically need to be
 added, too.

 Please reopen if I am mistaken, or you disagree with my reasoning about
 documenting 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] #17611: django.contrib.gis raises exception on ./manage.py test

[Django]

#17611: django.contrib.gis raises exception on ./manage.py test
--+--
 Reporter:  andrey@…  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  GIS   |  Version:  SVN
 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 akaariai):

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


Comment:

 I am going to close this ticket, as it seems this should be invalid (as
 said in comment:1). I don't know why this was then reopened, a bit
 confusing... So if I am mistaken, please reopen.

-- 
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] #17628: makemessages command walks through directories that match ignore_patterns

[Django]

#17628: makemessages command walks through directories that match 
ignore_patterns
--+
 Reporter:  andreiko  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
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 claudep):

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


Comment:

 To make it work, I had to transform 'dir/*' style expressions to 'dir'.

 Accessorily, to capture sdtout during the test, I had to pass around
 sdtout to several functions. It would be much simpler if those were
 methods of a class (hey ramiro).

-- 
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] #17630: tag not closed properly

[Django]

#17630:  tag not closed properly
--+--
 Reporter:  kolba329  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.comments  |  Version:  1.3
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by kolba329):

 You're right, i missed that, sorry

-- 
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] #17630: tag not closed properly

[Django]

#17630:  tag not closed properly
--+--
 Reporter:  kolba329  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.comments  |  Version:  1.3
 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 Alex):

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


Comment:

 If you look closely, you'll see that it is closed on line 26.

-- 
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] #17630: tag not closed properly

[Django]

#17630:  tag not closed properly
--+
 Reporter:  kolba329  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.comments  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 In django.contrib.comments, the preview.html template has a  tag that
 is 'https://code.djangoproject.com/browser/django/trunk/django/contrib/comments/templates/comments/preview.html#L24

 I think browsers are catching and properly displaying the page anyways,
 but just good to fix.

 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 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] #17629: forms.ChoiceField throws TypeError if label argument not provided

[Django]

#17629: forms.ChoiceField throws TypeError if label argument not provided
-+--
 Reporter:  pydanny  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.3
 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 Alex):

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


Comment:

 This isn't a bug, the error you're seeing is probably {{{ "__init__ got
 multiple values for keyword argument 'choices'" }}}, because choices is
 the first positional argument.  You can't pass the label as a positional
 argument like that.

-- 
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] #17629: forms.ChoiceField throws TypeError if label argument not provided

[Django]

#17629: forms.ChoiceField throws TypeError if label argument not provided
-+--
 Reporter:  pydanny  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.3
 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 Alex):

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


Old description:

> GRID_TYPE_CHOICES = (("comparison", "Comparison"), ("gallery",
> "Gallery"))
>
>  * grid_type = forms.ChoiceField(_("Type"), choices=(("comparison",
> "Comparison"), ("gallery", "Gallery")) # throws a TypeError.
>  * grid_type = forms.ChoiceField(label=_("Type"),
> choices=GRID_TYPE_CHOICES) # Works fine

New description:

 {{{ GRID_TYPE_CHOICES = (("comparison", "Comparison"), ("gallery",
 "Gallery"))}}}

  * {{{ grid_type = forms.ChoiceField(_("Type"), choices=(("comparison",
 "Comparison"), ("gallery", "Gallery")) # throws a TypeError. }}}
  * {{{ grid_type = forms.ChoiceField(label=_("Type"),
 choices=GRID_TYPE_CHOICES) # Works fine }}}

--

Comment:

 Formatted for readability, please use preview in the 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 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] #17629: forms.ChoiceField throws TypeError if label argument not provided

[Django]

#17629: forms.ChoiceField throws TypeError if label argument not provided
+
 Reporter:  pydanny |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.3
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 GRID_TYPE_CHOICES = (("comparison", "Comparison"), ("gallery", "Gallery"))

  * grid_type = forms.ChoiceField(_("Type"), choices=(("comparison",
 "Comparison"), ("gallery", "Gallery")) # throws a TypeError.
  * grid_type = forms.ChoiceField(label=_("Type"),
 choices=GRID_TYPE_CHOICES) # Works fine

-- 
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] r17419 - django/trunk/django/template

[noreply]

Author: adrian
Date: 2012-02-02 09:03:32 -0800 (Thu, 02 Feb 2012)
New Revision: 17419

Modified:
   django/trunk/django/template/loader_tags.py
Log:
Fixed loader_tags.py to import token_kwargs from the correct module

Modified: django/trunk/django/template/loader_tags.py
===
--- django/trunk/django/template/loader_tags.py 2012-02-02 04:44:17 UTC (rev 
17418)
+++ django/trunk/django/template/loader_tags.py 2012-02-02 17:03:32 UTC (rev 
17419)
@@ -1,6 +1,5 @@
 from django.conf import settings
-from django.template.base import TemplateSyntaxError, Library, Node, TextNode
-from django.template.defaulttags import token_kwargs
+from django.template.base import TemplateSyntaxError, Library, Node, TextNode, 
token_kwargs
 from django.template.loader import get_template
 from django.utils.safestring import mark_safe
 

-- 
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] #17628: makemessages command walks through directories that match ignore_patterns

[Django]

#17628: makemessages command walks through directories that match 
ignore_patterns
--+
 Reporter:  andreiko  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Internationalization  |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 ./manage.py makemessages always walks through all directories in a tree,
 even if some directory's path matches an ignore pattern.

 So we perform meaningless time-consuming scan through .svn, .git and other
 possible deep directories that we would like to fully ignore:

 {{{
 $ ./manage.py makemessages -l ru -d django -v 2
 examining files with the extensions: .html
 processing language ru
 ignoring file .DS_Store in .
 ignoring file .gitignore in .
 ...
 ignoring file e974710282570831dbefad0e177403d07205ba in ./.git/objects/07
 ignoring file da4359b0e24cb164eace2ac312af8fafff2127 in ./.git/objects/08
 ignoring file f195d5a9e0cf3542ef36028fa4820d8cdf560a in ./.git/objects/08
 ignoring file 26c086ebf3d6fee600fccddaf6bbc6a7f347a1 in ./.git/objects/0a
 ...
 }}}

 Suggested patch changes behavior of "walk" function defined in
 makemessages.py to skip directories which path matches some ignore
 pattern.

-- 
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] #17613: Add validation method for cache keys

[Django]

#17613: Add validation method for cache keys
-+
 Reporter:  vzima|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Cache system)  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by vzima):

 Replying to [comment:3 russellm]:

 The basic problem I tried to solve are cases when you do not have cache
 keys under your control or your key validity does not match requirements
 of memcache. There are three basic approaches for that - check it up front
 and avoid cache, hash the identifier, or try it and catch the exception.

  * I headed for the first solution to add a method you can use to check
 your key before you try to use it, to minimise impact on current
 implementation. I still think this is valid requirement as you would have
 to do that in your code anyway. This solution also allows the possibility
 to write this function specifically for each backend as nobody can assert
 that memcache will be the only cache library used on production.

  * You can always hash the identifier and make unique cache key, but in
 most cases this would be much slower than just check for length. Simple
 truncation could be fast enough, but it does not guarantee that the key
 will be unique.

  * Define a single exception that would be raised from any backend if
 problematic key is used would be probably a best solution. Warnings still
 can happen in django backends. I am not quite sure though, how much
 memcache libraries differ in their exceptions.

 Decision whether to avoid caching or use another key function is dependent
 on what is cached. Sometimes it might be better to avoid caching if your
 key can not be used, I just want to add support for such cases.

 > The first is with the implementation -- you raise an exception, which is
 then caught as a warning. Why not just raise the warning in the first
 place?
 Yes, I should have done that.
 > Django's cache backends raise warnings.
 You would have to set warnings filter to "error" so they will be actually
 raised and memcache backend raises memcache exceptions instead of these
 warnings, so it will not help you on production anyway.

 Note 1: You may encounter problems with key length when you do not except
 them. Assume you check you identifier for length of 247, with no prefix
 this will create keys of length 250. But once you increase your cache
 version from 9 to 10, some of these keys might turn length 251 and
 memcache starts to raise exceptions. As the cache prefixes and versions
 are defined in settings, you can never be sure the keys will not get too
 long.

 Note 2: Originally, I found this problem by using invalid keys in
 `cache.get` method, which docstring says: "... If the key does not exist,
 return default...". If you use invalid key, then it does not exist and I
 expect `get` to either return default value or raise Type exception as
 `dict` does.

-- 
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.