Re: [Django] #10929: Support a default value for Sum (and possibly other aggregation functions)

[Django]

#10929: Support a default value for Sum (and possibly other aggregation 
functions)
-+-
 Reporter:  nolan|Owner:
 Type:  New feature  |   Status:  new
Component:  ORM aggregation  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  aggregate annotate   | Triage Stage:  Accepted
  default|  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by mrmachine):

 * cc: real.human@… (added)
 * version:  1.1-beta-1 => SVN
 * keywords:   => aggregate annotate default
 * needs_docs:  0 => 1
 * has_patch:  0 => 1
 * ui_ux:   => 0


Comment:

 Just added a patch with an initial implementation for this feature. It
 should work for all aggregates by wrapping the default `sql_template` in
 `COALESCE(%s, %%(default)s)`, if `params` has a `default` item. There's a
 basic test in there that checks the behaviour for `Avg` with and without a
 default. If there's positive feedback about the implementation, I'll have
 a go at adding documentation and any improvements to the implementation
 and tests that are suggested.

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

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

Re: [Django] #17094: DeletionMixin get_success_url parameter

[Django]

#17094: DeletionMixin get_success_url parameter
-+-
 Reporter:  alej0|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

 * stage:  Ready for checkin => Design decision needed


Comment:

 Sorry, I've been a bit too quick in my initial judgment. A case could be
 made that it's the code that needs changing. Indeed, the `delete()` method
 could technically pass the deleted object to the `get_success_url()`
 method as is currently documented. Marking as DDN as I'm personally not
 feeling strong about either way.

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

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

[Django] #17096: Strengthen the makemessages command's safe-guarding of po files

[Django]

#17096: Strengthen the makemessages command's safe-guarding of po files
-+-
   Reporter:  julien |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |Version:  1.3
  Component:  Core   |   Keywords:
  (Management commands)  |  Has patch:  0
   Severity:  Normal |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 It is common practice to set up a cron job to regularly run the
 `makemessages` command in order to update the 'django.po' file with the
 latest available translations. To limit the risk of data loss, the command
 first creates a temporary file, but then it simply copies the resulting
 content into the original file `[1]`. It seems there is still a risk to
 run into a race condition where another process would update that file at
 the same time and override the content initially populated by the
 `makemessages` command, or vice versa.

 I've discussed this with Alex Gaynor and Benjamin Peterson (Python core
 dev) about using some file-locking or safe-guarding strategies. Quoting
 Benjamin:

 "On posix systems, you can simply use os.rename to replace translations
 file with the temporary file; the operation is guaranteed to be
 atomic, so any Django process accessing it will be guaranteed to see
 either only the old translation file or the new one.

 Windows is far more painful, since it has no guarantees of atomic
 renaming. On Vista and after, there is a MoveFileTransacted. This has
 the problem of not supporting older versions of Windows and not being
 exposed directly by Python (though it is in pywin32). Usually then,
 you have to do something in the writing process like creating a lock
 file, writing to the main file, then deleting the lock file. The
 reader then has to check to make sure there is no lock file before
 commencing reading.

 Unittesting is not so fun either. You can take the approach of
 creating a bunch of readers and a bunch of writers and running them
 against each other for a few seconds. You can also mock out the file
 system calls and ensure that the writer and the reader and performing
 operations in the correct sequence."

 So, to strengthen the safe-guarding of po files, we could perhaps use a
 combination of a) comparing the file's before modification date-
 times in case it has simultaneously been modified by another process — if
 the date-time is different then the `makemessages` process should stop
 with a warning; and b) using `os.rename` to replace the destination file
 by a temporary file instead of directly writing into the destination file.

 If implementing the same support for Windows appears to be too hard, then
 maybe we could leave that off and revert to the current system, since the
 issue described here is most likely to occur in production environments
 and I've personally never heard of live Django sites deployed on Windows-
 based platforms.

 `[1]`
 
https://code.djangoproject.com/browser/django/trunk/django/core/management/commands/makemessages.py?rev=16864#L297

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

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

Re: [Django] #17095: "Dive Into Python's explanation" hyperlink is bad.

[Django]

#17095: "Dive Into Python's explanation" hyperlink is bad.
---+--
 Reporter:  JRemedios@…|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by julien):

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


Comment:

 Thanks for the report, although this has already been reported in #17028.

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

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

[Django] #17095: "Dive Into Python's explanation" hyperlink is bad.

[Django]

#17095: "Dive Into Python's explanation" hyperlink is bad.
---+
 Reporter:  JRemedios@…|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The "Dive Into Python's explanation" hyperlink does not work anymore.
 This is in the URL Dispatcher documentation page under the Notes of the
 first Example.

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

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

Re: [Django] #17094: DeletionMixin get_success_url parameter

[Django]

#17094: DeletionMixin get_success_url parameter
-+-
 Reporter:  alej0|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  0|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Ready for checkin
 * type:  Uncategorized => Bug
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Thanks, good catch. `obj` just needs to be removed from the doc
 (https://docs.djangoproject.com/en/dev/ref/class-based-
 views/#django.views.generic.edit.DeletionMixin.get_success_url).

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

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

Re: [Django] #17092: Internal Redirects with Apache

[Django]

#17092: Internal Redirects with Apache
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  HTTP handling|   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
-+-
Changes (by leanmeandonothingmachine):

 * cc: leanmeandonothingmachine (added)
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

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

[Django] #17094: DeletionMixin get_success_url parameter

[Django]

#17094: DeletionMixin get_success_url parameter
---+
 Reporter:  alej0  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In https://docs.djangoproject.com/en/1.3/ref/class-based-
 views/#django.views.generic.edit.DeletionMixin.get_success_url says that
 get_success_url get a parameter(obj) but this doesn't happen on the source
 code.

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

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

Re: [Django] #15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute '_table_row_index'

[Django]

#15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute
'_table_row_index'
---+--
 Reporter:  bmihelac   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 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 ramiro):

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


Old description:

> When trying to make documentation with make html, following exception is
> raised:
>
> {{{
> Exception occurred:
>   File "/Users/bmihelac/dev/django/src/sphinx/sphinx/writers/html.py",
> line 523, in visit_row
> self._table_row_index += 1
> AttributeError: DjangoHTMLTranslator instance has no attribute
> '_table_row_index'
> }}}
>
> # Sphinx version: 1.1pre/ce4bb37a1409
> # Python version: 2.6.6
> # Docutils version: 0.7 release
> # Jinja2 version: 2.5

New description:

 When trying to make documentation with make html, following exception is
 raised:

 {{{
 Exception occurred:
   File "/Users/bmihelac/dev/django/src/sphinx/sphinx/writers/html.py",
 line 523, in visit_row
 self._table_row_index += 1
 AttributeError: DjangoHTMLTranslator instance has no attribute
 '_table_row_index'
 }}}


  * Sphinx version: 1.1pre/ce4bb37a1409
  * Python version: 2.6.6
  * Docutils version: 0.7 release
  * Jinja2 version: 2.5

--

Comment:

 Please don't report different errors is the same ticket.

 There are two issues reported in this ticket:

 Fist, the

 {{{
 Exception occurred:
   File ".../sphinx/writers/html.py", line 522, in visit_row
 self._table_row_index += 1
 }}}

 error. It's triggered by a change between Sphinx 1.0.x and 1.1. We fixed
 (or rather worked around) it for our trunk docs in r16223 but we didn't
 backport it to the 1.3.x branch and now it's too late for us to change our
 custom HTML builder code in the 1.3.1 release tarball.

 Second, the
 {{{
 Exception occurred:
   File ".../sphinx/writers/html.py", line 120, in visit_desc_parameter
 self.body.append(self.param_separator)
 }}}

 error. This is a similar case: It also originates in a
 [https://bitbucket.org/birkenfeld/sphinx/changeset/5afc6092a568 change]
 introduced during the Sphinx 1.1 development cycle and in 1.0.8. We also
 had to workaround it (r16231) and didn't backport it to 1.3.x either.
 AFAICT is is a badly implemented change will try to open a ticket in
 Sphinx issue tracker so it is fixed for 1.1.x.

 In short: If you want to build the 1.3 or 1.3.1 Django docs use Sphinx
 1.0.7 or older.

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

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

Re: [Django] #17070: newly created templatetags module not loaded or recognized until server restart

[Django]

#17070: newly created templatetags module not loaded or recognized until server
restart
--+
 Reporter:  UltraAyla |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Template system   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  templatetag tags  | 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):

 * status:  closed => reopened
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Comment:

 I don't think this is really a bug related to deployment servers; in those
 cases you pretty much need to reload the server for all code changes.

 But I do think there is a valid bug here, and it's specifically related to
 cases where Django auto-discovers certain modules at startup and then
 caches what it discovers (templatetags and the admin). This has a bad
 interaction specifically with the runserver auto-reloader. In general the
 auto-reloader will reload the server automatically whenever code changes.
 If you add a new module and then import it in your code, that involves
 changing existing code, so the auto-reloader reloads. But if you add a new
 templatetag module and try to load and use it in a template, Django will
 never find it until you manually restart runserver. This is genuinely
 surprising behavior when you hit it.

 I'm not sure at this point what the fix would look like, or if there is
 even a good fix. We may in the end need to just wontfix this for lack of a
 good solution. But I think it should be left open at this point to see if
 anyone has good ideas for a fix, as it is a real issue.

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

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

Re: [Django] #17091: Djano 1.4 SimpleListFilter 'selected' option issue

[Django]

#17091: Djano 1.4 SimpleListFilter 'selected' option issue
-+-
 Reporter:  tejinderss@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  SimpleListFilter,| Triage Stage:  Design
  FilterSpec |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by julien):

 Could you please provide all your relevant admin and model definitions? I
 think this might be a case where the `SimpleListFilter` should *not* be
 used and where the Django documentation could be improved.

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

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

Re: [Django] #10200: loaddata command does not raise CommandError on errors

[Django]

#10200: loaddata command does not raise CommandError on errors
-+-
 Reporter:  lgs  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  exit status  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by yishaibeeri):

 * status:  closed => reopened
 * cc: yishaibeeri (added)
 * component:  Core (Serialization) => Core (Management commands)
 * version:  1.0 => SVN
 * keywords:   => exit status
 * resolution:  duplicate =>
 * stage:  Design decision needed => Accepted


Comment:

 Reopening, as the fix for #16026 did not, eventually, fix this issue. In
 trunk (as of rev 17029) the exit status of a failed loaddata invocation
 (e.g., bad value in a fixture causing a DatabaseError) is still 0.

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

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

Re: [Django] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

[Django]

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
 Reporter:  lev.maximov@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  USE_THOUSAND_SEPARATOR |  Needs documentation:  0
  prepopulated_fields|  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by aaugustin):

 Yes, that's how it works.

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

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

Re: [Django] #17085: Deprecate "add_to_builtins" and replace with API on Template

[Django]

#17085: Deprecate "add_to_builtins" and replace with API on Template
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:  duplicate
 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):

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


Comment:

 Closing this as dupe of #17093 since dealing with the add_to_builtins
 problem makes the most sense in the context of that refactor.

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

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

Re: [Django] #13958: There is an error, when a source file with backslash-r returns is interpreted by the Python error report page.

[Django]

#13958: There is an error, when a source file with backslash-r returns is
interpreted by the Python error report page.
-+--
 Reporter:  petrvanblokland  |Owner:  nessita
 Type:  Bug  |   Status:  reopened
Component:  Uncategorized|  Version:  1.2
 Severity:  Normal   |   Resolution:
 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 fredrik.kers@…):

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


Comment:

 Patch and unittest added

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

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

Re: [Django] #17093: Refactor django.template to quarantine global state

[Django]

#17093: Refactor django.template to quarantine global state
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Alex):

 * stage:  Unreviewed => Accepted


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

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

[Django] #17093: Refactor django.template to quarantine global state

[Django]

#17093: Refactor django.template to quarantine global state
+
   Reporter:  carljm|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Template system   |Version:  SVN
   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 |
+
 The template engine keeps a lot of global state around: the instantiated
 template loaders, the list of builtins, the cached list of loaded
 templatetag modules. This makes it inflexible for use as a library (you
 can't render different templates using different template loaders or
 directories or tag modules in the same process) and makes test isolation
 very difficult (for the same reasons).

 This can be fixed via a refactoring to introduce a `TemplateEngine` class
 to encapsulate all this state. We would still create a default module-
 level instance of `TemplateEngine` based on the settings, and backwards-
 compatibility wrappers for the current public API that delegate to the
 default engine. But this would then allow alternative instances of
 TemplateEngine to be created and used for library use and testing, that
 would be self-contained and independent from settings.

 In the long run, this type of refactoring is also necessary if we want to
 move towards "app-object" style configuration in place of global settings.

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

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

Re: [Django] #15667: Implement template-based widget rendering

[Django]

#15667: Implement template-based widget rendering
+
 Reporter:  brutasse|Owner:  brutasse
 Type:  New feature |   Status:  new
Component:  Forms   |  Version:
 Severity:  Normal  |   Resolution:
 Keywords:  form-rendering  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+

Comment (by carljm):

 This patch would also fix #16630. Not closing that as duplicate because
 it's more narrowly focused and can be done separately.

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

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

Re: [Django] #16630: Support for HTML5 input types

[Django]

#16630: Support for HTML5 input types
-+
 Reporter:  jonash   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  html5| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by carljm):

 This patch would be superseded/fixed if #15667 is merged. That shouldn't
 block this patch, as it's not clear when (or even if, depending on
 performance issues) we can do #15667 - just making a note for reference.

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

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

[Django] #17092: Internal Redirects with Apache

[Django]

#17092: Internal Redirects with Apache
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  HTTP handling |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The CGI specification allows for a CGI script to return a 'Location'
 header
 which refers to a location within the local web server. In Apache this is
 honoured when the Status returned by the CGI script is also 200. mod_wsgi
 also supports this. See
 http://code.google.com/p/modwsgi/issues/detail?id=14.

 [6164] added the host to all redirects. While this is good for 99.9% of
 use cases, this makes these sorts of internal redirects impossible with
 django. Would it be reasonable to change fix_location_header to only add
 the host if the response code is not 200? Or we could add a variable such
 as Response.add_host_to_location that defaults to True that could be used
 to control this behavior on a per response basis. I'd be happy to work on
 the path for this once I hear back which implementation would be more
 likely to be accepted.

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

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

Re: [Django] #17085: Deprecate "add_to_builtins" and replace with API on Template

[Django]

#17085: Deprecate "add_to_builtins" and replace with API on Template
-+
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by carljm):

 This ticket was based on the false premise that `add_to_builtins` was
 documented API - I really thought I'd seen it in a corner of the docs
 somewhere. Given that it's not, I think it should just be removed, and we
 don't need to add an API to replace it.

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

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

Re: [Django] #17086: humanize and markup tests modify global templatetags library state

[Django]

#17086: humanize and markup tests modify global templatetags library state
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.humanize  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by carljm):

 Part (b) here was pure fail, there's no monkeypatching needed; if the
 contrib/humanize tests are running, that means contrib/humanize is
 installed and the template tags are available. So this is a simple fix
 (just stop using add_to_builtins and use `{% load %}` instead).

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

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

Re: [Django] #16630: Support for HTML5 input types

[Django]

#16630: Support for HTML5 input types
-+
 Reporter:  jonash   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  html5| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by jonash):

 bump

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

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

Re: [Django] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

[Django]

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
 Reporter:  lev.maximov@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  USE_THOUSAND_SEPARATOR |  Needs documentation:  0
  prepopulated_fields|  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by anonymous):

 I tried to look for override_settings documentation but I didn't find
 enough. Is it correct the use of it as follows?

 {{{
 @override_settings(USE_THOUSAND_SEPARATOR = True, USE_L10N = True)
 def test_prepopulated_maxlength_localized(self):
 """
 Regression test for #15938: if USE_THOUSAND_SEPARATOR is set, make
 sure
 that maxLength (in the javascript) is rendered without separators.
 """

 response =
 self.client.get('/test_admin/admin/admin_views/prepopulatedpostlargeslug/add/')
 self.assertContains(response, "maxLength: 1000") # instead of
 1,000

 }}}

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

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

Re: [Django] #17029: django.dispatch.dispatcher.Signal should be pickleable

[Django]

#17029: django.dispatch.dispatcher.Signal should be pickleable
--+--
 Reporter:  d0ugal|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Other)  |  Version:  1.3
 Severity:  Normal|   Resolution:  wontfix
 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 Alex):

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


Comment:

 After speaking with Carl, I'm marking this as wontfix because it is non-
 obvious as to whether pickling a Signal should include the registered
 receivers, and how that interacts with the weak referencing, since there's
 no obvious semantic it seems better not to guess.

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

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

Re: [Django] #17081: runfcgi with daemonize=True requires aboslute path for pidfile parameter

[Django]

#17081: runfcgi with daemonize=True requires aboslute path for pidfile parameter
-+-
 Reporter:   |Owner:  nobody
  bernhard.hollaender@…  |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Uncategorized|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  runfcgi  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Alex):

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


Comment:

 As best I can tell this is because daemonize changes the cwd.  Marking as
 accepted because it sounds right and I have no idea how to run fcgi.

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

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

Re: [Django] #17004: transaction.commit_manually decorator masks exceptions

[Django]

#17004: transaction.commit_manually decorator masks exceptions
-+-
 Reporter:  msoulier@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  needsinfo
 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 Alex):

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


Comment:

 There isn't enough information to reproduce this issue.  I'm marking this
 as needsinfo, please reopen if you can provide a test case or a
 description of how to reproduce this issue.

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

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

Re: [Django] #16964: FileField files can't be opened in write mode if not closed before

[Django]

#16964: FileField files can't be opened in write mode if not closed before
--+
 Reporter:  jonash|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Alex):

 * stage:  Unreviewed => Accepted


Comment:

 It should probably only reopen (as opposed to seeking) if the mode is
 changed, patch is correct in principle.

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

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

Re: [Django] #13958: There is an error, when a source file with backslash-r returns is interpreted by the Python error report page.

[Django]

#13958: There is an error, when a source file with backslash-r returns is
interpreted by the Python error report page.
-+--
 Reporter:  petrvanblokland  |Owner:  nessita
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  1.2
 Severity:  Normal   |   Resolution:  needsinfo
 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 Alex):

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


Comment:

 Closing as needsinfo.  In order to accept this bug we need to know how to
 actually reproduce it, not just a statement of what looks wrong in the
 code and what 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17091: Djano 1.4 SimpleListFilter 'selected' option issue

[Django]

#17091: Djano 1.4 SimpleListFilter 'selected' option issue
-+-
 Reporter:  tejinderss@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  SimpleListFilter,| Triage Stage:  Design
  FilterSpec |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by tejinderss@…):

 I am using in operator to filter results by multiple status values, i.e.
 !?status!__in=0,30,40 filters results with status values 0, 30 and 40.
 Thats what i want. status_in (with single _) does not work as expected, it
 just redirects to ?e=1 without filtered results. Even the default filters
 use 2 _ notation. Like if i use default filter "Status", the url is
 ?status!__exact=30. Thats the default notation i guess and only !__ works.
 Here is the example of default django filter behavior.

  http://i.imgur.com/RwRTI.png

 Edit: Sorry for messed up formatting in previous reply.

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

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

Re: [Django] #17091: Djano 1.4 SimpleListFilter 'selected' option issue

[Django]

#17091: Djano 1.4 SimpleListFilter 'selected' option issue
-+-
 Reporter:  tejinderss@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  SimpleListFilter,| Triage Stage:  Design
  FilterSpec |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by anonymous):

 I am using in operator to filter results by multiple status values, i.e.
 ?status__in=0,30,40 filters results with status values 0, 30 and 40. Thats
 what i want. status_in (with single _) does not work as expected, it just
 redirects to ?e=1 without filtered results. Even the default filters use 2
 _ notation. Like if i use default filter "Status", the url is
 ?status__exact=30. Thats the default notation i guess and only __ works.
 Here is the example of default django filter behavior.

 http://i.imgur.com/RwRTI.png

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

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

Re: [Django] #15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute '_table_row_index'

[Django]

#15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute
'_table_row_index'
---+--
 Reporter:  bmihelac   |Owner:  nobody
 Type:  Bug|   Status:  reopened
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Thijs Triemstra ):

 * status:  closed => reopened
 * type:  Uncategorized => Bug
 * version:  SVN => 1.3
 * resolution:  invalid =>


Comment:

 {{{
 thijs@ubuntu:~$ cd Downloads/Django-1.3.1/docs/
 thijs@ubuntu:~/Downloads/Django-1.3.1/docs$ make html
 sphinx-build -b djangohtml -d _build/doctrees   . _build/html
 Making output directory...
 Running Sphinx v1.1
 loading pickled environment... not yet created
 building [djangohtml]: targets for 205 source files that are out of date
 updating environment: 205 added, 0 changed, 0 removed
 reading sources... [100%] topics/testing
 looking for now-outdated files... none found
 pickling environment... done
 checking consistency... done
 preparing documents... done
 writing output... [  5%] howto/apache-auth
 Exception occurred:
   File "/usr/local/lib/python2.7/site-
 packages/Sphinx-1.1-py2.7.egg/sphinx/writers/html.py", line 522, in
 visit_row
 self._table_row_index += 1
 AttributeError: DjangoHTMLTranslator instance has no attribute
 '_table_row_index'
 The full traceback has been saved in /tmp/sphinx-err-vX7RVN.log, if you
 want to report the issue to the developers.
 Please also report this if it was a user error, so that a better error
 message can be provided next time.
 Either send bugs to the mailing list at ,
 or report them in the tracker at
 . Thanks!
 make: *** [html] Error 1
 }}}

 That's with Python 2.7.1/Django 1.3.1/Ubuntu 11.04/Sphinx 1.1.

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

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

Re: [Django] #15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute '_table_row_index'

[Django]

#15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute
'_table_row_index'
---+--
 Reporter:  bmihelac   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Thijs Triemstra ):

 * cc: lists@… (added)


Comment:

 Also fails with Sphinx 1.1 (current stable version).

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

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

Re: [Django] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

[Django]

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
 Reporter:  lev.maximov@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  USE_THOUSAND_SEPARATOR |  Needs documentation:  0
  prepopulated_fields|  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by aaugustin):

 * needs_better_patch:  0 => 1


Comment:

 Patch doesn't apply cleanly and `test_prepopulated_maxlength_localized`
 should use the `override_settings` decorator.

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

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

Re: [Django] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

[Django]

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
 Reporter:  lev.maximov@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  USE_THOUSAND_SEPARATOR |  Needs documentation:  0
  prepopulated_fields|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by feel):

 * ui_ux:   => 0


Comment:

 I also report the same bug and the Lev's patch works well. Does it need to
 be flagged RFC?

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

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

[Changeset] r17029 - in django/trunk: django/utils tests/regressiontests/utils

[noreply]

Author: aaugustin
Date: 2011-10-23 08:19:09 -0700 (Sun, 23 Oct 2011)
New Revision: 17029

Modified:
   django/trunk/django/utils/feedgenerator.py
   django/trunk/tests/regressiontests/utils/feedgenerator.py
Log:
Fixed #14202 -- made the atom:link element optional in feeds.


Modified: django/trunk/django/utils/feedgenerator.py
===
--- django/trunk/django/utils/feedgenerator.py  2011-10-23 03:43:43 UTC (rev 
17028)
+++ django/trunk/django/utils/feedgenerator.py  2011-10-23 15:19:09 UTC (rev 
17029)
@@ -224,7 +224,9 @@
 handler.addQuickElement(u"title", self.feed['title'])
 handler.addQuickElement(u"link", self.feed['link'])
 handler.addQuickElement(u"description", self.feed['description'])
-handler.addQuickElement(u"atom:link", None, {u"rel": u"self", u"href": 
self.feed['feed_url']})
+if self.feed['feed_url'] is not None:
+handler.addQuickElement(u"atom:link", None,
+{u"rel": u"self", u"href": self.feed['feed_url']})
 if self.feed['language'] is not None:
 handler.addQuickElement(u"language", self.feed['language'])
 for cat in self.feed['categories']:

Modified: django/trunk/tests/regressiontests/utils/feedgenerator.py
===
--- django/trunk/tests/regressiontests/utils/feedgenerator.py   2011-10-23 
03:43:43 UTC (rev 17028)
+++ django/trunk/tests/regressiontests/utils/feedgenerator.py   2011-10-23 
15:19:09 UTC (rev 17029)
@@ -87,3 +87,16 @@
 atom_feed.mime_type, "application/atom+xml; charset=utf-8"
 )
 
+# Two regression tests for #14202
+
+def test_feed_without_feed_url_gets_rendered_without_atom_link(self):
+feed = feedgenerator.Rss201rev2Feed('title', '/link/', 'descr')
+self.assertEquals(feed.feed['feed_url'], None)
+feed_content = feed.writeString('utf-8')
+self.assertNotIn('', 
feed_content)

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

Re: [Django] #14202: Rss201rev2Feed bug

[Django]

#14202: Rss201rev2Feed bug
-+-
 Reporter:  ZalivinDenis@…   |Owner:  tmitchell
 Type:  Bug  |   Status:  closed
Component:  contrib.syndication  |  Version:  1.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Rss201rev2Feed,  | Triage Stage:  Accepted
  feedgenerator  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 In [17029]:
 {{{
 #!CommitTicketReference repository="" revision="17029"
 Fixed #14202 -- made the atom:link element optional in feeds.
 }}}

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

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

Re: [Django] #17085: Deprecate "add_to_builtins" and replace with API on Template

[Django]

#17085: Deprecate "add_to_builtins" and replace with API on Template
-+
 Reporter:  carljm   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by ptone):

 * stage:  Unreviewed => Accepted


Comment:

 add_to_builtins is not a documented function - but seems to have made it
 into use extensive in the wild.

 its primary use currently in Django is either:

 add the truly global builtin tags and filters in template/base.py

 add template tags into builtin space as a convenience for tests

 the API you propose sounds like a python level alternative to the load
 tag.

 From the context of the template, this is magic and far less explicit than
 using the load tag

 It looks like most of the wild use of add_to_builtins is to provide
 "convenience" by 3rd party apps to make their tags global.  But I would
 say that they should be re-documented as requiring the load tag in the
 users base.html if they want it everywhere

 I think a deprecation of add_to_builtins with a replacement of
 _add_to_builtins could be done to get the message.  But I think we should
 be encouraging more explicitness in the template space, not enabling less.

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

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

Re: [Django] #14202: Rss201rev2Feed bug

[Django]

#14202: Rss201rev2Feed bug
-+-
 Reporter:  ZalivinDenis@…   |Owner:  tmitchell
 Type:  Bug  |   Status:  assigned
Component:  contrib.syndication  |  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  Rss201rev2Feed,  | Triage Stage:  Accepted
  feedgenerator  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Since this isn't a major problem, per the backport policy, it isn't going
 to be fixed on trunk only, not in the stable banches.

 I'm going to commit the fix.

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

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

Re: [Django] #17082: contrib.auth html should be updated to used HTML5 features where possible (was: Login form should use HTML5 autofocus with JavaScript as fallback)

[Django]

#17082: contrib.auth html should be updated to used HTML5 features where 
possible
--+
 Reporter:  drhevans  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by ptone):

 * stage:  Unreviewed => Accepted


Comment:

 This would be part of a larger project of updating html in contrib.auth -
 and unlikely to be fixed in isolation.  A similar effort would also exist
 for contrib.admin (which need not be coupled to the change for auth, as it
 is much bigger). Such changes need to be backwards compatable, but my
 understanding of HTML5 is that this is relatively builtin by design.

 note: original summary:

 Login form should use HTML5 autofocus with JavaScript as fallback

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

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

Re: [Django] #14202: Rss201rev2Feed bug

[Django]

#14202: Rss201rev2Feed bug
-+-
 Reporter:  ZalivinDenis@…   |Owner:  tmitchell
 Type:  Bug  |   Status:  assigned
Component:  contrib.syndication  |  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  Rss201rev2Feed,  | Triage Stage:  Accepted
  feedgenerator  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

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


Comment:

 why is this still not fixed ? in 1.2.7 ? or even in 1.3.1 ?

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

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

Re: [Django] #17032: Tests for contrib.auth fail if login signals use templates

[Django]

#17032: Tests for contrib.auth fail if login signals use templates
-+-
 Reporter:  jMyles   |Owner:  jMyles
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  contrib.auth, tests  | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ptone):

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


Comment:

 I think the ultimate fix will be related to a full reorganization of the
 way tests are run in Django (this needs a ticket of its own).  There has
 been recent discussion in IRC about replacing the test runner with
 something closer to a standard unittest runner, nose etc and making tests
 even more atomic and less coupled to a full suite run.

 I think julien's explanation above is the best we have in the current
 situation.  To patch this for auth doesn't solve the bigger problem of the
 mingling integration and unit tests.

 as such I think this merits a wontfix.

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

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

Re: [Django] #17070: newly created templatetags module not loaded or recognized until server restart

[Django]

#17070: newly created templatetags module not loaded or recognized until server
restart
--+--
 Reporter:  UltraAyla |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Template system   |  Version:  1.3
 Severity:  Normal|   Resolution:  invalid
 Keywords:  templatetag tags  | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by ptone):

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


Comment:

 This is a general feature of a running server.  There are lots of areas in
 Django that are loaded when the first starts and are not reloaded during
 run.  The development server will auto-reload many things, and this is
 mentioned in the tutorial, but otherwise you need to restart a server
 process.  Because there are many methods of deploying Django - this
 becomes a deployment question, and difficult to document for all
 deployment options.  See for example docs on uWSGI for gradually
 restarting worker processes for example.

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

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

Re: [Django] #17091: Djano 1.4 SimpleListFilter 'selected' option issue

[Django]

#17091: Djano 1.4 SimpleListFilter 'selected' option issue
-+-
 Reporter:  tejinderss@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  SimpleListFilter,| Triage Stage:  Design
  FilterSpec |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by julien):

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


Comment:

 What is happening here is that your parameter name ends with "`__in`"
 which is interpreted as if the value passed is a list. So for example
 "`?status__in=0,30,40`" is interpreted as if the value passed is
 `[0,30,40]`, not `"0,30,40"`. To be honest, at this stage I'm not sure if
 it's a bug or a feature.

 If you renamed your parameter to "`status_in`" (with just one underscore)
 then it should just work. I'd like to understand your use case better
 though. Could you please explain your original motivation for having 2
 underscores in the parameter name?

 I'm keen to know to figure out whether we should treat it as a bug or
 rather as an opportunity to build a new feature around it. Thanks!

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

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

Re: [Django] #17089: Color of fonts used in code

[Django]

#17089: Color of fonts used in code
-+-
 Reporter:  colonelcoleslaw@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by idangazit):

 * component:  Djangoproject.com Web site => Documentation


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

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

Re: [Django] #17089: Color of fonts used in code

[Django]

#17089: Color of fonts used in code
-+-
 Reporter:  colonelcoleslaw@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Djangoproject.com|   Resolution:
  Web site   | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by idangazit):

 Apologies, unclear "next step":

 I'll leave this open to comment for a month. Absent engaged discussion,
 I'll make some decision on Dec 1st or the 1.4 deadline, whichever comes
 first.

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

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

Re: [Django] #17089: Color of fonts used in code

[Django]

#17089: Color of fonts used in code
-+-
 Reporter:  colonelcoleslaw@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Djangoproject.com|   Resolution:
  Web site   | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by idangazit):

 I'm not a huge fan of the green background for code samples, however I
 don't think it qualifies as "barely legible." I'm loath to touch something
 that has worked fine for many people, or at least, has failed to elicit
 comment from them.

 That being said, I've attached two screenshots, one depicting the current
 state of affairs, and one with a grey-background for code blocks.

 I'd like to see a docs style refactor in a future django, might as well
 think about this aspect now.

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

[Django] #17091: Djano 1.4 SimpleListFilter 'selected' option issue

[Django]

#17091: Djano 1.4 SimpleListFilter 'selected' option issue
---+--
 Reporter:  tejinderss@…   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  SVN
 Severity:  Normal |   Keywords:  SimpleListFilter, FilterSpec
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 I have written a SimpleListFilter, here is the code:
 http://dpaste.com/639578/

 It displays in the admin list properly, but i am having an issue, The
 selected option does not get highlighted in the custom filter. Only 'All'
 highlights but not the custom options. Here is the screenshot to
 illustrate that:

 http://imgur.com/IyrYk

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

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

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
-+-
 Reporter:  Honza_Kral   |Owner:
 Type:  Bug  |  jkocherhans
Component:  contrib.admin|   Status:  closed
 Severity:  Normal   |  Version:  SVN
 Keywords:  nfa-someday  |   Resolution:  fixed
  list_filter filterspec nfa-| Triage Stage:  Accepted
  changelist ep2008  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by julien):

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


Comment:

 Thanks for the report, but could you please open a new ticket? This one
 here is already overloaded with old discussions.

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

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

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
-+-
 Reporter:  Honza_Kral   |Owner:
 Type:  Bug  |  jkocherhans
Component:  contrib.admin|   Status:  reopened
 Severity:  Normal   |  Version:  SVN
 Keywords:  nfa-someday  |   Resolution:
  list_filter filterspec nfa-| Triage Stage:  Accepted
  changelist ep2008  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by tejinderss@…):

 * status:  closed => reopened
 * resolution:  fixed =>
 * type:  New feature => Bug


Comment:

 I have written a SimpleListFilter, here is the code:
 http://dpaste.com/639578/

 It displays in the admin list properly, but i am having an issue, The
 selected option does not get highlighted in the custom filter. Only 'All'
 highlights but not the custom options. Here is the screenshot to
 illustrate that:

 http://imgur.com/IyrYk

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

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