[Django] #22387: admin.SimpleListFilter No exception message supplied

[Django]

#22387: admin.SimpleListFilter No exception message supplied
--+
 Reporter:  drumchaps@…   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Uncategorized |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There is no error to raise when implementing a SimpleListFilter and not
 overriding the queryset method.

 NotImplementedError at /path_to/admin/
 No exception message supplied

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

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

[Django] #22386: squashmigrations needs documentation

[Django]

#22386: squashmigrations needs documentation
-+
 Reporter:  kmtracey@…   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Migrations   |Version:  1.7-beta-1
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Andrew on IRC noted he thought it was documented, but it's not currently
 got any.

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

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

Re: [Django] #22384: Deprecate Django string magic in URLs and the ability to reverse by dotted path

[Django]

#22384: Deprecate Django string magic in URLs and the ability to reverse by 
dotted
path
--+
 Reporter:  timo  |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (URLs)   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Gwildor):

 I agree that reversing by dotted-path-to-view is "a bad idea". I would
 even say it's just ridiculous, and I didn't even knew it existed.
 Obviously you should just use the url name. What would actually happen
 when you have two urls to the same view? Anyway, I'm all for deprecating
 that feature.

 On the other hand, I'm not entirely convinced about deprecating the
 dotted-path-to-view in url feature. There are a lot of settings and other
 things in Django which work that way, and it's a nice feature which
 prevents the imports from cluttering for the people who are still pro
 FBV's. Unless it opens up the possibility of removing the necessity of
 calling `as_view()` on every CBV in the urls. If deprecating this feature
 is part of a bigger plan to migrate to cleaner urls for CBV's, then I'm
 all for it.

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

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

[Django] #22385: PDF documentation link incorrect

[Django]

#22385: PDF documentation link incorrect
+
 Reporter:  ismaelruizmartin@…  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Documentation   |Version:  1.6
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Hello,

 In many of the documentations pages in 1.6 version, the link to the PDF
 documentation

 http://media.readthedocs.org/pdf/django/1.6.x/django.pdf

 is not providing the expected document.

 Best wishes

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

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

Re: [Django] #22384: Deprecate Django string magic in URLs and the ability to reverse by dotted path

[Django]

#22384: Deprecate Django string magic in URLs and the ability to reverse by 
dotted
path
--+
 Reporter:  timo  |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (URLs)   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by aaugustin):

 2.0 is a pretty good target for the final removal of this feature.

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

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

Re: [Django] #22377: SQL Logging throws an exception when fields have utf-8 characters

[Django]

#22377: SQL Logging throws an exception when fields have utf-8 characters
-+-
 Reporter:  rolanvc@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:  sql logging for  |  Unreviewed
  utf-8  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * status:  new => closed
 * type:  Uncategorized => Bug
 * resolution:   => needsinfo


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

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

Re: [Django] #22384: Deprecate Django string magic in URLs and the ability to reverse by dotted path

[Django]

#22384: Deprecate Django string magic in URLs and the ability to reverse by 
dotted
path
--+
 Reporter:  timo  |Owner:  timo
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (URLs)   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 +1 from me.

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

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

Re: [Django] #22384: Deprecate Django string magic in URLs and the ability to reverse by dotted path

[Django]

#22384: Deprecate Django string magic in URLs and the ability to reverse by 
dotted
path
-+-
 Reporter:  timo |Owner:  timo
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Core (URLs)  |   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 timo):

 I plan to work on this, but will wait to ensure that there are no -1's to
 the idea, raising it on the mailing list if necessary.

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

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

[Django] #22384: Deprecate Django string magic in URLs and the ability to reverse by dotted path

[Django]

#22384: Deprecate Django string magic in URLs and the ability to reverse by 
dotted
path
+
   Reporter:  timo  |  Owner:  timo
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (URLs)   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Now that we've deprecated `patterns()` and recommended actually importing
 your views module and referencing your view functions (or classes)
 directly (#22218), I think it's time to deprecate the "Django String
 Magic" (as Carl termed it) that lets you use strings in `url()`, e.g.
 `url('^$', 'myapp.views.myview')`. As well as reverse by dotted path, e.g.
 `reverse('myapp.views.myview')`.

 Marc mentioned in that ticket "Reversing by dotted path to view is just a
 bad idea."

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

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

Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

[Django]

#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  loic84
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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|
-+-
Changes (by loic84):

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


Comment:

 There's no documentation yet and I still want to add more tests, but the
 latest effort for this issue is at
 https://github.com/django/django/pull/2500.

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

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

Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

[Django]

#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  loic84
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 Bitten too.

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

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

Re: [Django] #22305: MaxLengthValidator doesn't take database encoding into account

[Django]

#22305: MaxLengthValidator doesn't take database encoding into account
+--
 Reporter:  joeri   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.6
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by joeri):

 * cc: joeri (added)
 * status:  closed => new
 * resolution:  worksforme =>


Comment:

 Hi,

 I was a bit incomplete in my ticket. We are using PostgreSQL 9.1 and we
 traced the problem to the database charset, which was set to `SQL_ASCII`
 (for some reason `template0` charset was set to this and used to create
 the db). You would still expect everything to work on the db end, or that
 your `ModelForm` catches the error.

 Edge case, so maybe a note in the docs would suffice.

 Here's the unit tests that I ran against a PostgreSQL db with `SQL_ASCII`
 encoding:

 {{{
 # -*- coding: utf-8 -*-
 from django.test import TestCase
 from django.db import models
 from django.forms.models import modelform_factory


 class Pizza(models.Model):
 name = models.CharField(max_length=10)  # Short pizza names ftw.


 class MyTests(TestCase):
 def test_form_to_db(self):
 form = modelform_factory(Pizza)
 pizza_name = u'mozzarélla'
 f = form(data={'name': pizza_name})

 self.assertTrue(f.is_valid())
 f.save()  # Gives an error
 }}}

 And here's the result of the test:

 {{{
 $ python src/manage.py test
 Creating test database for alias 'default'...
 E
 ==
 ERROR: test_form_to_db (tests.MyTests)
 --
 Traceback (most recent call last):
   File "/home/joeri/playground/django-1.6/ticket22305/tests.py", line 18,
 in test_form
 f.save()
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/forms/models.py", line 446, in save
 construct=False)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/forms/models.py", line 99, in save_instance
 instance.save()
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 545, in save
 force_update=force_update, update_fields=update_fields)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 573, in save_base
 updated = self._save_table(raw, cls, force_insert, force_update,
 using, update_fields)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 654, in _save_table
 result = self._do_insert(cls._base_manager, using, fields, update_pk,
 raw)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 687, in _do_insert
 using=using, raw=raw)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/models/manager.py", line 232, in _insert
 return insert_query(self.model, objs, fields, **kwargs)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 1511, in insert_query
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 899, in execute_sql
 cursor.execute(sql, params)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/backends/util.py", line 53, in execute
 return self.cursor.execute(sql, params)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/utils.py", line 99, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/joeri/playground/django-1.6/env/local/lib/python2.7/site-
 packages/django/db/backends/util.py", line 53, in execute
 return self.cursor.execute(sql, params)
 DataError: value too long for type character varying(10)
 }}}

 Reopening the ticket.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web 

[Django] #22383: Django form auto add requried tag

[Django]

#22383: Django form auto add requried tag
-+
 Reporter:  abhishek.garg@…  |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Forms|Version:  1.6
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Hi,
 When we use django forms, it would be nice if it automatically add the
 required tag to the input fields which are required for database entry,
 this way the user won't even be able to submit the form, instead of
 getting back the form with errors that "missing field" .

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

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

Re: [Django] #22106: catalogs of django.views.i18n.javascript_catalog overwrite each other (was: Make django.views.i18n.javascript_catalog more flexible)

[Django]

#22106: catalogs of django.views.i18n.javascript_catalog overwrite each other
-+-
 Reporter:  moritzs  |Owner:  moritzs
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  jsi18n javascript|  Unreviewed
  catalog|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by moritzs):

 * type:  Cleanup/optimization => Bug


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

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

Re: [Django] #5437: Make GDAL optional for GIS test runner

[Django]

#5437: Make GDAL optional for GIS test runner
-+
 Reporter:  rcoup|Owner:  vlal
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  testing  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by claudep):

 Thanks for the patch. But frankly, when I see that, I'm really tempted to
 make GDAL a required part of our GIS infrastructure. I think that in the
 past, GDAL was not so easily installable, but that limitation may be moot
 now. It might be worth debating this on django-dev mailing list.

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

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

Re: [Django] #22378: \d in urls examples in documentation is missleading.

[Django]

#22378: \d in urls examples in documentation is missleading.
--+
 Reporter:  tomwys|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by tomwys):

 Hurl approach is interesting, but it is not resolving issues with
 re.UNICODE (but could after some modifications).

 Also `[0-9]+` is not solving all problems, because you can add leading
 zeros "0001". Correct regex would be `([1-9][0-9]*)` or `([1-9][0-9]*)|0`
 if you want to support `0`. But no one would like to use regexps like that
 in all of their urls.

 Other approach would be to introduce more advanced parsing mechanism that
 not only validates data, but also converts it to objects and back to
 strings (something like to_python in models). There are several examples
 of such parsers that would make sense:
 * integer
 * float
 * decimal
 * date
 * time
 * datetime

 Also some of users may want to add more advanced custom parsers like:
 * date range (where first date must be earlier)
 * integer range (same as above)
 * GPS coordinate
 * list of slugs (ie. for tags)

 Advantages of this approach:
 * more robust - it is guaranteed to receive assumed value without
 complicated regexps,
 * more elastic - you can write your views and templates without assuming
 in what format date will be stored in url,
 * removes from views repetitive tasks like parsing date from url.

 Example syntax:

 {{{

 url(r'^articles/(\d{4})/$', 'news.views.year_archive'),
 # becomes:
 url([r'^articles/', year, '/$'], 'news.views.year_archive')),

 url(r'^(?P\d+)/$', views.detail, name='detail'),
 # becomes:
 url(r'^', integer('question_id'), r'^/$'], views.detail, name='detail'),

 url(r'^weeklyreports/(?P\d{4})/(?P\d{2})/(?P\d+)/$',
 'weeklyreports', name='weeklyreports'),
 # becomes:
 url([r'^weeklyreports/', date('report_date, '/MM/DD'), r'/$'],
 'weeklyreports', name='weeklyreports'),
 }}}

 This could be combined with Hurl approach.

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

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

[Django] #22382: ManyRelatedManager's get_prefetch_queryset doesn't validate the prefetch types

[Django]

#22382: ManyRelatedManager's get_prefetch_queryset doesn't validate the prefetch
types
--+
 Reporter:  Keryn Knight    |  Owner:  nobody
 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
--+
 
[https://github.com/django/django/blob/a2407c9577c400bf9931ff1db1d7757afa378162/django/db/models/fields/related.py#L898
 the return value] for `get_prefetch_queryset` includes two lambda
 functions, one for
 
[https://github.com/django/django/blob/a2407c9577c400bf9931ff1db1d7757afa378162/django/db/models/query.py#L1909
 setting the resulting tuple] as a key in the `rel_obj_cache` and another
 for
 
[https://github.com/django/django/blob/a2407c9577c400bf9931ff1db1d7757afa378162/django/db/models/query.py#L1913
 getting it back later].

 The
 
[https://github.com/django/django/blob/a2407c9577c400bf9931ff1db1d7757afa378162/django/db/models/fields/related.py#L900
 one which is used for retrieving] the data uses `getattr` while the other
 pulls the data from the `_prefetch_related_val_...` attribute returned as
 part of the `QuerySet.extra` call. The prefetched values do not
 necessarily correlate to the intended types, however, and so values can
 end up mismatched.

 By way of example, and how I discovered this, [https://github.com/dcramer
 /django-uuidfield django-uuidfield] returns a `StringUUID` in it's
 [https://github.com/dcramer/django-
 uuidfield/blob/master/uuidfield/fields.py#L138 to_python] method, which is
 what ends up being returned
 
[https://github.com/django/django/blob/a2407c9577c400bf9931ff1db1d7757afa378162/django/db/models/fields/related.py#L900
 as instance_attr] - something like
 `(UUID('7d917781c54e4fdfa551a693c3782380'),)` but the
 
[https://github.com/django/django/blob/a2407c9577c400bf9931ff1db1d7757afa378162/django/db/models/fields/related.py#L899
 rel_obj_attr] doesn't take into account the `to_python` for the relation,
 and so returns `(u'7d917781c54e4fdfa551a693c3782380',)` - the naive
 strings from the database.

 Thus, the key `(u'7d917781c54e4fdfa551a693c3782380',)` never exists in the
 `rel_obj_cache`, and Django assumes everything went well (because it just
 sets a default of `[]`). Future queries to the relation
 (`x.relation.all()`) will yield nothing - they won't trigger a query
 because they've been prefetched, but they won't be populated because of
 the type mismatch in the dictionary keys.

 Arguably the problem exists downstream in `django-uuidfield`, but the
 problem *also* exists in Django, and may exist as an edge-case in other
 third party fields - I've marked it as master, but the type-mismatch issue
 exists from 1.4 (attrgetter version) to 1.6 (list comprehension version)
 and looks to still be there in master (generator expression version)

 The fix that seems to work for me is transforming:
 {{{
 lambda result: tuple(getattr(result, '_prefetch_related_val_%s' %
 f.attname) for f in fk.local_related_fields),
 }}}
 into:
 {{{
 lambda result: tuple(f.rel.get_related_field().to_python(getattr(result,
 '_prefetch_related_val_%s' % f.attname)) for f in
 fk.local_related_fields),
 }}}

 I'm not sure if any of the equivalent methods on other classes would be
 affected.

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

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

Re: [Django] #22378: \d in urls examples in documentation is missleading.

[Django]

#22378: \d in urls examples in documentation is missleading.
--+
 Reporter:  tomwys|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by mjtamlyn):

 A related, but more complex issue is the matter of `\w` with `re.UNICODE`.
 I can see that some projects may wish to accept characters like `è` in
 URLs, others may be unwittingly doing so. I believe we had this discussion
 recently regarding username validation.

 I think a specific note about `\w` and `\d` in the URL documentation would
 be advisable. In particular, the "correct" regex for capturing a slug
 field should also be mentioned.

 This also relates to some of my comments on
 https://code.djangoproject.com/ticket/22218#comment:2 regarding providing
 a non-regex based approach to URL resolving in core where novice
 developers are not required to think about these problems.

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

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

Re: [Django] #5437: Make GDAL optional for GIS test runner

[Django]

#5437: Make GDAL optional for GIS test runner
-+
 Reporter:  rcoup|Owner:  vlal
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  testing  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by vlal):

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


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

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

Re: [Django] #5437: Make GDAL optional for GIS test runner

[Django]

#5437: Make GDAL optional for GIS test runner
-+
 Reporter:  rcoup|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  testing  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by vlal):

 Issued [https://github.com/django/django/pull/2516 Pull Request #5437].
 Verified tests either pass or skip when necessary.

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

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

[Django] #22381: small improvement of css media="print"

[Django]

#22381: small improvement of css media="print"
--+
 Reporter:  zio.pietro.53@…   |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:  css
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Hello,

 can you, please, adjust a bit css for printing documentation? Right
 navigation column
 isn't printed (it's OK, I think nobody has clickable paper) but of this
 one remains
 on paper solid painted empty column (width 13mm). Looks ugly (especially
 on b/w printing)
 and it's vaste of ink/toner and space. Thanks

 I think this little problem isn't version dependent.

 Regards
 Pietro

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

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

Re: [Django] #22380: Error in GeoDjango tests example. Missing SECRET_KEY

[Django]

#22380: Error in GeoDjango tests example. Missing SECRET_KEY
--+
 Reporter:  vlal  |Owner:  vlal
 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:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Claude Paroz ):

 In [changeset:"4ad4a236de1726eac6da1f865c9f2f80e080794f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="4ad4a236de1726eac6da1f865c9f2f80e080794f"
 [1.7.x] Fixed #22380 -- Missing SECRET_KEY variable in sample settings
 file for testing

 Backport of 8f621b83e9 from master.
 }}}

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

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

[django/django] 4ad4a2: [1.7.x] Fixed #22380 -- Missing SECRET_KEY variabl...

[GitHub]

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 4ad4a236de1726eac6da1f865c9f2f80e080794f
  
https://github.com/django/django/commit/4ad4a236de1726eac6da1f865c9f2f80e080794f
  Author: Vishal Lal 
  Date:   2014-04-04 (Fri, 04 Apr 2014)

  Changed paths:
M docs/ref/contrib/gis/testing.txt

  Log Message:
  ---
  [1.7.x] Fixed #22380 -- Missing SECRET_KEY variable in sample settings file 
for testing

Backport of 8f621b83e9 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/533e640ee8f67_6777ebfd346748c%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] 8f621b: Fixed #22380 -- Missing SECRET_KEY variable in sam...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 8f621b83e9e68aa79d2e83b71b4f8217e05af12c
  
https://github.com/django/django/commit/8f621b83e9e68aa79d2e83b71b4f8217e05af12c
  Author: Vishal Lal 
  Date:   2014-04-04 (Fri, 04 Apr 2014)

  Changed paths:
M docs/ref/contrib/gis/testing.txt

  Log Message:
  ---
  Fixed #22380 -- Missing SECRET_KEY variable in sample settings file for 
testing


  Commit: 248b9bb5544c1cf0b9f36091f0608814dedac6b5
  
https://github.com/django/django/commit/248b9bb5544c1cf0b9f36091f0608814dedac6b5
  Author: Claude Paroz 
  Date:   2014-04-04 (Fri, 04 Apr 2014)

  Changed paths:
M docs/ref/contrib/gis/testing.txt

  Log Message:
  ---
  Merge pull request #2514 from vlal/ticket_22380

Fixed #22380 -- Missing SECRET_KEY variable in sample settings file for ...


Compare: https://github.com/django/django/compare/c28beb429107...248b9bb5544c

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/533e638fdfcf4_7134e67d3c214a1%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22380: Error in GeoDjango tests example. Missing SECRET_KEY

[Django]

#22380: Error in GeoDjango tests example. Missing SECRET_KEY
--+
 Reporter:  vlal  |Owner:  vlal
 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:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Vishal Lal ):

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


Comment:

 In [changeset:"8f621b83e9e68aa79d2e83b71b4f8217e05af12c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8f621b83e9e68aa79d2e83b71b4f8217e05af12c"
 Fixed #22380 -- Missing SECRET_KEY variable in sample settings file for
 testing
 }}}

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

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

Re: [Django] #22380: Error in GeoDjango tests example. Missing SECRET_KEY

[Django]

#22380: Error in GeoDjango tests example. Missing SECRET_KEY
--+
 Reporter:  vlal  |Owner:  vlal
 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:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Claude Paroz ):

 In [changeset:"248b9bb5544c1cf0b9f36091f0608814dedac6b5"]:
 {{{
 #!CommitTicketReference repository=""
 revision="248b9bb5544c1cf0b9f36091f0608814dedac6b5"
 Merge pull request #2514 from vlal/ticket_22380

 Fixed #22380 -- Missing SECRET_KEY variable in sample settings file for
 ...
 }}}

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

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

Re: [Django] #22380: Error in GeoDjango tests example. Missing SECRET_KEY

[Django]

#22380: Error in GeoDjango tests example. Missing SECRET_KEY
--+
 Reporter:  vlal  |Owner:  vlal
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by claudep):

 * stage:  Unreviewed => Accepted


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

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