date:20130515

Re: [Django] #20407: use of touple instead of list in settings.configure explanation

2013-05-15 Thread Django

#20407: use of touple instead of list in settings.configure explanation
---+--
 Reporter:  amirwilf@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.5
 Severity:  Normal |   Resolution:  wontfix
 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 claudep):

 Are you sure your tuple was a real tuple and not a mere string like
 `('/only/path/')`? If you can reproduce it consistently, feel free to
 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19326: Add a first method to the QuerySet

2013-05-15 Thread Django

#19326: Add a first method to the QuerySet
-+-
 Reporter:  Wim Feijen   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  first|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by carbonXT):

 How about adding a test that `first()` and `last()` work as expected on
 empty querysets? Other than that the patch looks good to me.

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

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

Re: [Django] #19611: User Admin breaks on submit with form validation error

2013-05-15 Thread Django

#19611: User Admin breaks on submit with form validation error
--+--
 Reporter:  gcc   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by anonymous):

 * version:  1.4 => 1.5


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

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

[Django] #20415: broken SRID in gis.admin javascript when "USE_THOUSAND_SEPARATOR = True"

2013-05-15 Thread Django

#20415: broken SRID in gis.admin javascript when "USE_THOUSAND_SEPARATOR = True"
+--
 Reporter:  pierremarc07@…  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  GIS |Version:  1.5
 Severity:  Normal  |   Keywords:  gis, admin, srid
 Triage Stage:  Unreviewed  |  Has patch:  1
Easy pickings:  0   |  UI/UX:  0
+--
 broken SRID in gis.admin javascript when "USE_THOUSAND_SEPARATOR = True"

 > geodjango_mpoly.get_ewkt = function(feat){return 'SRID=900 913;' +
 geodjango_mpoly.wkt_f.write(feat);}

 the following change in contrib/gis/templates/gis/admin/openlayers.js
 fixed the problem

 {{{
 - {{ module }}.get_ewkt = function(feat){return 'SRID={{ srid }};' + {{
 module }}.wkt_f.write(feat);}
 + {{ module }}.get_ewkt = function(feat){return 'SRID={% localize off %}{{
 srid }}{% endlocalize %};' + {{ module }}.wkt_f.write(feat);}
 }}}

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

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

Re: [Django] #20410: Small Typo in Form wizard documentation

2013-05-15 Thread Django

#20410: Small Typo in Form wizard documentation
---+--
 Reporter:  tom@…  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by timo):

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


Comment:

 Code works as is according to comment on the pull request.

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

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

[Django] #20414: Handling of numbers under oracle is slow

2013-05-15 Thread Django

#20414: Handling of numbers under oracle is slow
--+
 Reporter:  shai  |  Owner:  shai
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:  oracle
 Triage Stage:  Unreviewed|  performance
Easy pickings:  0 |  Has patch:  1
  |  UI/UX:  0
--+
 With current code, for all number columns, the Oracle backend asks
 cx_Oracle to return the numbers as strings, and then transforms them back
 to numbers on the way out. All this is done because Oracle supports higher
 precision (and a wider range of integers) than the Python `float` type;
 some values, if they are to be reported accurately, must be returned as
 `decimal.Decimal`s, and cx_Oracle doesn't apparently do that on its own.

 With cx_Oracle 5, though, it is possible to use a much better approach, on
 a per-column (rather than per-row) basis, selecting the right output type
 when there is enough information to do so, and making most of the
 decisions once-per-query instead of once-per-row.

 An original patch for this was written by Ian Kelly; I improved it and
 made a pull-request in the stretch towards 1.5, but there was no ticket
 for it and so it was never merged. I hope we can finally merge it into
 1.6.

 There was a little saga of discussions around this (mostly Anssi, Ian and
 myself, https://groups.google.com/d/topic/django-
 developers/4BNkJyGez9A/discussion). Some other issues are also mentioned
 there. But this is the main one.

 So now there is a ticket. Things changed, and the pull-request needed
 updating. The new one is at https://github.com/django/django/pull/1071.

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

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

[django/django] 318877: Fix bug introduced in contrib.gis in 74f3884ae0

2013-05-15 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 31887751746088d99b2f607f929c0c4a02978740
  
https://github.com/django/django/commit/31887751746088d99b2f607f929c0c4a02978740
  Author: Mike Fogel 
  Date:   2013-05-15 (Wed, 15 May 2013)

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

  Log Message:
  ---
  Fix bug introduced in contrib.gis in 74f3884ae0


  Commit: 63f6ee817ec281b14e1a5fbcdc356cfcab67280b
  
https://github.com/django/django/commit/63f6ee817ec281b14e1a5fbcdc356cfcab67280b
  Author: Alex Gaynor 
  Date:   2013-05-15 (Wed, 15 May 2013)

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

  Log Message:
  ---
  Merge pull request #1070 from mfogel/ticket_20413

Fix bug introduced in contrib.gis in 74f3884ae0


Compare: https://github.com/django/django/compare/c0c3b65de99d...63f6ee817ec2

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

Re: [Django] #20413: respect Query.get_meta()

2013-05-15 Thread Django

#20413: respect Query.get_meta()
--+
 Reporter:  carbonXT  |  Owner:  carbonXT
 Type:  Bug   | Status:  closed
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal| Resolution:  fixed
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+

Comment (by Alex Gaynor ):

 In [changeset:"c0c3b65de99d638efcb971702a88be42f388989a"]:
 {{{
 #!CommitTicketReference repository=""
 revision="c0c3b65de99d638efcb971702a88be42f388989a"
 Merge pull request #1069 from mfogel/ticket_20413

 Fixed #20413 - Respect Query.get_meta()
 }}}

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

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

Re: [Django] #20413: respect Query.get_meta()

2013-05-15 Thread Django

#20413: respect Query.get_meta()
--+
 Reporter:  carbonXT  |  Owner:  carbonXT
 Type:  Bug   | Status:  closed
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal| Resolution:  fixed
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+
Changes (by Mike Fogel ):

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


Comment:

 In [changeset:"74f3884ae04ea57baee9b04ab0b5658a97cfd296"]:
 {{{
 #!CommitTicketReference repository=""
 revision="74f3884ae04ea57baee9b04ab0b5658a97cfd296"
 Fixed #20413 - Respect Query.get_meta()
 }}}

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

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

[django/django] 74f388: Fixed #20413 - Respect Query.get_meta()

2013-05-15 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 74f3884ae04ea57baee9b04ab0b5658a97cfd296
  
https://github.com/django/django/commit/74f3884ae04ea57baee9b04ab0b5658a97cfd296
  Author: Mike Fogel 
  Date:   2013-05-15 (Wed, 15 May 2013)

  Changed paths:
M django/contrib/gis/db/models/sql/compiler.py
M django/db/models/query.py
M django/db/models/sql/compiler.py
M django/db/models/sql/query.py
M django/db/models/sql/subqueries.py

  Log Message:
  ---
  Fixed #20413 - Respect Query.get_meta()


  Commit: c0c3b65de99d638efcb971702a88be42f388989a
  
https://github.com/django/django/commit/c0c3b65de99d638efcb971702a88be42f388989a
  Author: Alex Gaynor 
  Date:   2013-05-15 (Wed, 15 May 2013)

  Changed paths:
M django/contrib/gis/db/models/sql/compiler.py
M django/db/models/query.py
M django/db/models/sql/compiler.py
M django/db/models/sql/query.py
M django/db/models/sql/subqueries.py

  Log Message:
  ---
  Merge pull request #1069 from mfogel/ticket_20413

Fixed #20413 - Respect Query.get_meta()


Compare: https://github.com/django/django/compare/ebfb71c64a78...c0c3b65de99d

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

[Django] #20413: respect Query.get_meta()

2013-05-15 Thread Django

#20413: respect Query.get_meta()
--+--
 Reporter:  carbonXT  |  Owner:  carbonXT
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+--
 In `django.db.models.sql.query.Query` there's a `get_meta(self)` method
 that's present to aid in subclassing `Query`. See
 
https://github.com/django/django/blob/master/django/db/models/sql/query.py#L206.
 Problem is, `Query` itself as well as its subclasses aren't using this
 method everywhere they could be... rather they're going around it and
 accessing its default return value directly. This breaks subclassing
 `Query` and overriding `get_meta`.

 I will submit a pull request shortly with mods to `Query` and friends to
 respect this method.

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

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

[Django] #20412: Loader that searches templates in directory tree starting by its leave.

2013-05-15 Thread Django

#20412: Loader that searches templates in directory tree starting by its leave.
-+---
 Reporter:  anonymous|  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Template system  |Version:  1.5
 Severity:  Normal   |   Keywords:  templates
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+---
 == Summary ==

 Suggestion to implement a dynamic template loader, where the origin of the
 template (where it is when it is searched for rendering), counts for where
 it is searched.

 This solves the problem of template name collision, and allows for
 "overloading" of templates within apps.

 == Example of the problem ==

 Consider the following example of app structure:

 {{{
 root/
  manage.py
  main/
   __init__.py
   settings.py
   urls.py
   views.py
   templates/
 base.html
 base/
  header.html
  secondary_header.html
   app1/
__init__.py
base_extension.html
base/
 secondary_header.html
 }}}

 with

 {{{
 #base.html
 {% include "header.html" %}
 {% block secondary_header %}{% include "base/secondary_header.html"
 %}{% endblock %}

 #base_extension.html
 {% extends "base.html" %}
 {% block secondary_header %}{% include "base/secondary_header.html"
 %}{% endblock %}
 }}}

 My suggestion is to create a loader that:

 if base.html is called (in main), it includes

 {{{
 main/base/secondary_header.html
 }}}

 if base_extension.html is called (in app1), it includes

 {{{
 main/app1/base/secondary_header.html
 }}}

 The current implementation always finds the secondary_header.html which
 appears first in the INSTALLED_APPS. So if the app1 is not prepared for
 being added at last in INSTALLED_APPS, there can be a name collision and
 the app1 (which would expect its own sec_header.html) has the
 sec_header.html from the main.

 This occurs because all the current template loaders searches for the
 first occurrence of the template linearly in INSTALLED_APPS.

 == Suggestion ==

 My suggestion is to have a loader that searches in the tree of the app
 calling the template with {%include%}: first searches in the templates of
 the app of the template (e.g. main/app1/templates/base). If none was
 found, it then searches in the level below (main/templates):

 search "main/app1/templates"
 if not found:
 search "main/templates"
 if not found:
 raise TemplateNotFound
 return template

 this search can be recursive in the app tree, and this tree can easily be
 retrieved from the INSTALLED_APPS.

 Simplifying in one sentence: the current approach searches linearly in
 INSTALLED_APPS. This approach searches recursively in the apps tree until
 either it reaches the root (template not found) or finding the template.

 == Discussion ==

 There are (at least) two reasons in favor:

 1. this is what django uses in most situations, the directory tree. In
 the current implementation, template names can collide between apps and
 the order of INSTALLED_APPS is important for template loading. The current
 implementation "suggests" that each template has to have the name of the
 app for avoiding collision. In this loader there is no collision with
 other apps, the directory tree defines the apps dependencies.

 2. because it allows "overloading" of templates, as presented in the
 example I presented, where an app can now use the base.html (by extending
 it), but would still use its own secondary_header.

 And (at least) two reasons against:

 1. the current implementation of loaders uses caching. I believe that
 in this implementation is more tricky, because the caching must be not
 only for a specific template name, but also from where it was called in
 the directory/apps tree.

 2. All the template related code (render, search, etc) only has one
 argument, the template name. This change leads to major problems in
 adjusting the code for this case.

 Nevertheless, I believe the two reasons in favor are two important
 advantages in programing in 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20411: Invalid Referer header blows up on CSRF protection middleware

2013-05-15 Thread Django

#20411: Invalid Referer header blows up on CSRF protection middleware
---+-
 Reporter:  edevil |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  HTTP handling  |Version:  1.5
 Severity:  Normal |   Keywords:  referer valueerror csrf
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 If a client sends an invalid Referer header such as
 'http://http://xxx.pt/', the CSRF middleware will blow up with an error:

 {{{
 ERROR 2013-05-15 17:38:56,542 django.request:212 22023 140475533584128
 Internal Server Error: /
 Traceback (most recent call last):
   File "/servers/python-environments/discosite/local/lib/python2.7/site-
 packages/django/core/handlers/base.py", line 109, in get_response
 response = middleware_method(request, callback, callback_args,
 callback_kwargs)
   File "/servers/python-environments/discosite/local/lib/python2.7/site-
 packages/django/middleware/csrf.py", line 148, in process_view
 if not same_origin(referer, good_referer):
   File "/servers/python-environments/discosite/local/lib/python2.7/site-
 packages/django/utils/http.py", line 229, in same_origin
 return (p1.scheme, p1.hostname, p1.port) == (p2.scheme, p2.hostname,
 p2.port)
   File "/usr/lib/python2.7/urlparse.py", line 110, in port
 port = int(port, 10)
 ValueError: invalid literal for int() with base 10: ''
 }}}

 Either we catch the Exception or we are more careful when comparing.

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

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

Re: [Django] #18481: IOErrors from FILES are not wrapped with UnreadablePostError

2013-05-15 Thread Django

#18481: IOErrors from FILES are not wrapped with UnreadablePostError
---+
 Reporter:  KyleMac|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by anonymous):

 What's missing?

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

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

Re: [Django] #19891: Travis CI support

2013-05-15 Thread Django

#19891: Travis CI support
-+-
 Reporter:  marko@…  |Owner:  dokterbob
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Testing framework|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  Travis, CI, testing  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by dokterbob):

 TLDR; Single commit everytime Travis tests break should be no problem, but
 if it is will work on Travis repo.

 @apollo13 The talk just now at DjangoCon made me remember this issue and
 read the related thread on the mailinglist. Have had no time to actually
 discuss on the dev' list but will present some arguments here.

 Personally I don't think it's elegant having a seperate repository just to
 keep a couple of commits out of the public timeline. Most Travis issues
 can be easily fixed in a fork/pull request as the exact same tests are run
 under the exact same circumstances there - part of the point of having
 Travis there in the first place.

 Having a seperate repo with just a config file potentially makes the tests
 more fragile as a change to the Travis config could cause tests to fail
 for no clearly apparent reason.

 If I could talk you guys into having Travis support in the main Django
 repo I will to the following:

 1. Pick up old work; rebase my branch to current master.
 2. Disable e-mail and IRC notifications for core dev's piece of mind.
 3. Run the tests again a couple of times to see if anything breaks.
 4. Create a single cute litte patch so there'll no 'fixing Travis' in the
 public timeline for now.

 Anyways, if the core devs do decide to go with a split-repo approach to
 Travis I'm willing to work on it during DjangoCon EU and will either
 finish it or leave it 'open' by the beginning of the sprints (will take
 train on friday). What I need to do this is:

 1. (Temporary) access (directly or indirectly, through pull req's) to a
 `travis-support` GH repo.
 2. A quick overview of what happened on this since the latest sprint from
 apollo13.
 3. Clear instructions on what the new approach will entail, what the goals
 are and what the conditions are under which it will be committed.

 Having Travis for Django still seems like a really good idea which could
 significantly increase the (quality of) contributions. In any case, I'm
 walking around on DjangoCon until friday afternoon. If you have questions
 or want to work on me with this one, poke me. If you are a core dev and
 want to discuss, poke me. If you're not a core dev, poke a core dev to get
 this in (preferably before the sprints). Then, during the sprints, we'll
 see quick enough whether Travis will prove to be a curse or a blessing but
 I'm counting on the latter to be the case.

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

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

Re: [Django] #19891: Travis CI support

2013-05-15 Thread Django

#19891: Travis CI support
-+-
 Reporter:  marko@…  |Owner:  dokterbob
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Testing framework|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  Travis, CI, testing  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by anonymous):

 TLDR; Single commit everytime Travis tests break should be no problem, but
 if it is will work on Travis repo.

 @apollo13 The talk just now at DjangoCon made me remember this issue and
 read the related thread on the mailinglist. Have had no time to actually
 discuss on the dev' list but will present some arguments here.

 Personally I don't think it's elegant having a seperate repository just to
 keep a couple of commits out of the public timeline. Most Travis issues
 can be easily fixed in a fork/pull request as the exact same tests are run
 under the exact same circumstances there - part of the point of having
 Travis there in the first place.

 Having a seperate repo with just a config file potentially makes the tests
 more fragile as a change to the Travis config could cause tests to fail
 for no clearly apparent reason.

 If I could talk you guys into having Travis support in the main Django
 repo I will to the following:

 1. Pick up old work; rebase my branch to current master.
 2. Disable e-mail and IRC notifications for core dev's piece of mind.
 3. Run the tests again a couple of times to see if anything breaks.
 4. Create a single cute litte patch so there'll no 'fixing Travis' in the
 public timeline for now.

 Anyways, if the core devs do decide to go with a split-repo approach to
 Travis I'm willing to work on it during DjangoCon EU and will either
 finish it or leave it 'open' by the beginning of the sprints (will take
 train on friday). What I need to do this is:

 1. (Temporary) access (directly or indirectly, through pull req's) to a
 `travis-support` GH repo.
 2. A quick overview of what happened on this since the latest sprint from
 apollo13.
 3. Clear instructions on what the new approach will entail, what the goals
 are and what the conditions are under which it will be committed.

 Having Travis for Django still seems like a really good idea which could
 significantly increase the (quality of) contributions. In any case, I'm
 walking around on DjangoCon until friday afternoon. If you have questions
 or want to work on me with this one, poke me. If you are a core dev and
 want to discuss, poke me. If you're not a core dev, poke a core dev to get
 this in (preferably before the sprints). Then, during the sprints, we'll
 see quick enough whether Travis will prove to be a curse or a blessing but
 I'm counting on the latter to be the case.

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

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

[Django] #20410: Small Typo in Form wizard documentation

2013-05-15 Thread Django

#20410: Small Typo in Form wizard documentation
---+
 Reporter:  tom@…  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 One of the code snippets has a typo.

 See pull request: https://github.com/django/django/pull/1068

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

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

Re: [Django] #20205: positiveintegerfield null=True, blank=True

2013-05-15 Thread Django

#20205: positiveintegerfield null=True, blank=True
-+-
 Reporter:  anonymous|Owner:  AmiZya
 Type:  Uncategorized|   Status:  assigned
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by areski):

 I think the problem is in the empty values allowed on IntegerField, this
 makes the full_clean to not detect that empty string '' is not valid. I
 will appreciate feedbacks

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

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

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

2013-05-15 Thread Django

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

Comment (by aaugustin):

 Here's the currenty behavior of the cache backends when `cache.set()` is
 called with `timeout=None` explicitly:
 - memcached has `def set(..., timeout=0, ...)`, and then there's this
 line: `timeout = timeout or self.default_timeout`
 - locmem/filebased/db have `def set(..., timeout=None, ...)`, and then
 there's `if timeout is None: timeout = self.default_timeout`

 For all backends except memcached `None` is a guard value that's intended
 to be replaced by the default timeout. It isn't intended to be passed
 explicitly (even though, obviously, that works). I don't know why
 memcached is implemented differently, but as far as I can tell, the intent
 is the same.

 Docs say that the "timeout argument is optional" and never show an example
 of passing None.

 Therefore, I repeat my support in using `None` for no expiration. Negative
 integers feels like C, not Python; and once we define an API we'll be
 stuck with it for the foreseeable future.

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

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

Re: [Django] #20409: Investigate how unique_for_date works with DateTimeFields when USE_TZ is True

2013-05-15 Thread Django

#20409: Investigate how unique_for_date works with DateTimeFields when USE_TZ is
True
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  new => assigned
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20409: Investigate how unique_for_date works with DateTimeFields when USE_TZ is True

2013-05-15 Thread Django

#20409: Investigate how unique_for_date works with DateTimeFields when USE_TZ is
True
--+---
 Reporter:  aaugustin |  Owner:  aaugustin
 Type:  Cleanup/optimization  | Status:  new
Component:  Database layer (models, ORM)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+---
 I'm not convinced `unique_for_date` works with `DateTimeField` when
 `USE_TZ = True`.

 In general I'm highly skeptical of APIs that accept dates or datetimes
 indifferently; they don't work well in a timezone-aware world.

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

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

[django/django] ebfb71: Fixed previous commit. (Don't commit from DjangCon...

2013-05-15 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ebfb71c64a786620947c9d598fd1ebae2958acff
  
https://github.com/django/django/commit/ebfb71c64a786620947c9d598fd1ebae2958acff
  Author: Florian Apolloner 
  Date:   2013-05-15 (Wed, 15 May 2013)

  Changed paths:
M django/contrib/gis/tests/geoadmin/tests.py

  Log Message:
  ---
  Fixed previous commit. (Don't commit from DjangCon!)



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

[django/django] f6d1ca: Don't unregister OSMGeoAdmin, other tests rely on ...

2013-05-15 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f6d1ca56c9d2583c894a44841d109a597ac019bd
  
https://github.com/django/django/commit/f6d1ca56c9d2583c894a44841d109a597ac019bd
  Author: Florian Apolloner 
  Date:   2013-05-15 (Wed, 15 May 2013)

  Changed paths:
M django/contrib/gis/tests/geoadmin/tests.py

  Log Message:
  ---
  Don't unregister OSMGeoAdmin, other tests rely on it.



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

[django/django] c8dcee: Improved the timezone middleware example slightly.

2013-05-15 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: c8dcee9a423fa3f31a2303e7ec20a924775730a2
  
https://github.com/django/django/commit/c8dcee9a423fa3f31a2303e7ec20a924775730a2
  Author: Aymeric Augustin 
  Date:   2013-05-15 (Wed, 15 May 2013)

  Changed paths:
M docs/topics/i18n/timezones.txt

  Log Message:
  ---
  Improved the timezone middleware example slightly.

This change avoids having the timezone leak from a request to the next.



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

Re: [Django] #20393: django.db.models.query.QuerySet.repr should not have side-effects

2013-05-15 Thread Django

#20393: django.db.models.query.QuerySet.__repr__ should not have side-effects
-+-
 Reporter:  justin@… |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:  QuerySet, repr,  |  Unreviewed
  side-effect|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by lukeplant):

 I should have added - feel free to persuade us otherwise on the
 DevelopersMailingList

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

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

Re: [Django] #20287: BaseContext (and it's subclasses) lack emulation of dictionary items()

2013-05-15 Thread Django

#20287: BaseContext (and it's subclasses) lack emulation of dictionary items()
-+-
 Reporter:  Keryn Knight |Owner:  cannona
   |   Status:  assigned
 Type:  New feature  |  Version:  master
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by cannona):

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


Comment:

 Any feedback on this patch is welcome.

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

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

Re: [Django] #20404: Add a keys() method to ContextList

2013-05-15 Thread Django

#20404: Add a keys() method to ContextList
---+
 Reporter:  gcc|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by gcc):

 Created a pull request: https://github.com/django/django/pull/1065

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

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

Re: [Django] #20407: use of touple instead of list in settings.configure explanation

2013-05-15 Thread Django

#20407: use of touple instead of list in settings.configure explanation
---+--
 Reporter:  amirwilf@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.5
 Severity:  Normal |   Resolution:  wontfix
 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 anonymous):

 I get what you're saying but on the other hand, when I tried using a tuple
 it couldn't find the template and when I used a list it did - I didn't go
 too deep into the code to understand why or if this only happened to me
 for some reason.

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

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

Re: [Django] #19326: Add a first method to the QuerySet

2013-05-15 Thread Django

#19326: Add a first method to the QuerySet
-+-
 Reporter:  Wim Feijen   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  first|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by selwin):

 I made a pull request implementing these features here:
 https://github.com/django/django/pull/1056 . Let me know if there's
 anything else that I need to change.

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

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

Re: [Django] #20407: use of touple instead of list in settings.configure explanation

2013-05-15 Thread Django

#20407: use of touple instead of list in settings.configure explanation
---+--
 Reporter:  amirwilf@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.5
 Severity:  Normal |   Resolution:  wontfix
 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 timo):

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


Comment:

 You may use either - tuples can't be changed (immutable) while lists can
 be; both are iterables. This is Python basics though, so I'm not sure it
 belongs in the Django docs.

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

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

Re: [Django] #20406: manage.py generate nginx/apache/uWSGI/gunicorn sample config

2013-05-15 Thread Django

#20406: manage.py generate nginx/apache/uWSGI/gunicorn sample config
-+-
 Reporter:  est  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * status:  new => closed
 * needs_better_patch:   => 0
 * component:  Uncategorized => Core (Management commands)
 * needs_tests:   => 0
 * type:  Uncategorized => New feature
 * needs_docs:   => 0
 * resolution:   => wontfix


Comment:

 Deployment is hard to standardize, because you have so many different
 parameters to take into account.

 I don't say that we should not do it, but nothing prevent you from
 creating a package outside of core Django to achieve this, and when/if it
 is popular and recognized as a very useful addition, we can then conceive
 integrating it in 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20408: values_list(flat=True) returns ValuesListQuerySet, not list

2013-05-15 Thread Django

#20408: values_list(flat=True) returns ValuesListQuerySet, not list
-+-
 Reporter:  marktranchant|  Owner:  nobody
 Type:   | Status:  new
  Cleanup/optimization   |Version:  1.4
Component:  Documentation|   Keywords:  values_list queryset
 Severity:  Normal   |  list
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  1|  UI/UX:  0
-+-
 The documentation should be updated to clarify that the structure returned
 by a values_list queryset with flat=True is not a plain list, but a
 ValuesListQuerySet. Alternatively, the code should actually output a list.

 I spent a while struggling to understand why I couldn't use the Python
 x.count(y) function on the output of such a query before realizing that I
 wasn't working with a Python list:

 {{{
 > rlist = Rpt.objects.values_list('status', flat=True)
 > type(rlist)
   django.db.models.query.ValuesListQuerySet
 > rlist.count(1)
   TypeError: count() takes exactly 1 argument (2 given)
 > rlist2 = list(Rpt.objects.values_list('status', flat=True))
 > rlist2.count(1)
   6
 }}}

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

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

Re: [Django] #20165: Doc test example may lead to programmer errors

2013-05-15 Thread Django

#20165: Doc test example may lead to programmer errors
--+
 Reporter:  lorinh|Owner:  lorinh
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  1
--+

Comment (by Tim Graham ):

 In [changeset:"7f4269229cd6ca0ef94a34fd045e3ced9bdd57d0"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7f4269229cd6ca0ef94a34fd045e3ced9bdd57d0"
 [1.5.x] Fixed #20165 - Updated testing example to use
 django.test.TestCase.

 Thanks Lorin Hochstein.

 Backport of 84d8b247d2 from master.
 }}}

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

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

[django/django] 7f4269: [1.5.x] Fixed #20165 - Updated testing example to ...

2013-05-15 Thread GitHub

  Branch: refs/heads/stable/1.5.x
  Home:   https://github.com/django/django
  Commit: 7f4269229cd6ca0ef94a34fd045e3ced9bdd57d0
  
https://github.com/django/django/commit/7f4269229cd6ca0ef94a34fd045e3ced9bdd57d0
  Author: Tim Graham 
  Date:   2013-05-15 (Wed, 15 May 2013)

  Changed paths:
M docs/topics/testing/overview.txt

  Log Message:
  ---
  [1.5.x] Fixed #20165 - Updated testing example to use django.test.TestCase.

Thanks Lorin Hochstein.

Backport of 84d8b247d2 from master.



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

Re: [Django] #20165: Doc test example may lead to programmer errors

2013-05-15 Thread Django

#20165: Doc test example may lead to programmer errors
--+
 Reporter:  lorinh|Owner:  lorinh
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  1
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"84d8b247d20aafb376368dc458f277ad2cd71ecd"]:
 {{{
 #!CommitTicketReference repository=""
 revision="84d8b247d20aafb376368dc458f277ad2cd71ecd"
 Fixed #20165 - Updated testing example to use django.test.TestCase.

 Thanks Lorin Hochstein.
 }}}

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

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

[django/django] 84d8b2: Fixed #20165 - Updated testing example to use djan...

2013-05-15 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 84d8b247d20aafb376368dc458f277ad2cd71ecd
  
https://github.com/django/django/commit/84d8b247d20aafb376368dc458f277ad2cd71ecd
  Author: Tim Graham 
  Date:   2013-05-15 (Wed, 15 May 2013)

  Changed paths:
M docs/topics/testing/overview.txt

  Log Message:
  ---
  Fixed #20165 - Updated testing example to use django.test.TestCase.

Thanks Lorin Hochstein.



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

[Django] #20407: use of touple instead of list in settings.configure explanation

2013-05-15 Thread Django

#20407: use of touple instead of list in settings.configure explanation
---+
 Reporter:  amirwilf@… |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hey,

 I'm was trying to use Django templates and wanted to know how to configure
 the settings manually and I found this page:
 https://docs.djangoproject.com/en/dev/topics/settings/

 In "django.conf.settings.configure(default_settings, **settings)", in the
 example it says to define:
 "TEMPLATE_DIRS='''(/home/web-apps/myapp', '/home/web-
 apps/base)'''"

 from my tests and this page:
 http://www.djangobook.com/en/2.0/appendixD.html

 it says to define:
 "TEMPLATE_DIRS='''[/home/web-apps/myapp', '/home/web-
 apps/base]'''"

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

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

Re: [Django] #20342: Replace CBV lookup arguments with single `lookup_field` argument.

2013-05-15 Thread Django

#20342: Replace CBV lookup arguments with single `lookup_field` argument.
-+-
 Reporter:  tomchristie  |Owner:
 Type:   |  tomchristie
  Cleanup/optimization   |   Status:  new
Component:  Generic views|  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by HM):

 I usually wind up with long, complex urls and looking up more than one
 thing actually, so would prefer something like:

 {{{
 # key: kwarg, value: model field

 lookups = {
 'pk': 'pk',
 'slug': 'slug',
 'otherkey': 'othermodel__serialno',
 'owner': 'owner__username',
 'year': 'year_published'
 }
 }}}

 and then either a separate function to set them, run during dispatch(), or
 one dynamic function per item.

 The default `lookups` would then be `{'pk': 'pk', 'slug': 'slug'}`

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

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

[django/django] 4ecc6d: Removed unicode literals from PIL compat.

2013-05-15 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 4ecc6da20b00b2d00a8cc158056a10bf0a259d07
  
https://github.com/django/django/commit/4ecc6da20b00b2d00a8cc158056a10bf0a259d07
  Author: Florian Apolloner 
  Date:   2013-05-15 (Wed, 15 May 2013)

  Changed paths:
M django/utils/image.py

  Log Message:
  ---
  Removed unicode literals from PIL compat.



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

39 matches

Mail list logo