[Django] #16935: Misleading message 'super object has no attribute __getattr__' on AttributError during SimpleTemplateResponse.render

[Django]

#16935: Misleading message 'super object has no attribute __getattr__' on
AttributError during SimpleTemplateResponse.render
---+-
 Reporter:  isagalaev  |  Owner:  isagalaev
 Type:  Bug| Status:  new
Milestone: |  Component:  Template system
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+-
 Consider this code:

 {{{
 from django.template import Template
 from django.template.response import SimpleTemplateResponse

 class A(object):
 def __unicode__(self):
 return None.something

 def index(request):
 return SimpleTemplateResponse(Template('{{ var }}'), {'var': A()})
 }}}

 This code emulates a situation of any {{{AttributeError}}} raised during
 initial template rendering from within {{{SimpleTemplateReponse.render}}}.
 The real error "NoneType object has no attribute something" is masked by a
 very weird-looking "super object has no attribute __getattr__". The
 traceback also points inside SimpleTemplateResponse.__getattr__ which has
 no relation whatsoever to the real point of error.

-- 
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] #16934: Tutorial 3: error in html editing

[Django]

#16934: Tutorial 3: error in html editing
-+-
   Reporter: |  Owner:  nobody
  humphries.grant@…  | Status:  closed
   Type: |  Component:  Documentation
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution:  invalid|Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 The tutorial appears to be correct. Perhaps you have a typo or something
 missing in your own code. In any case, please do not use Trac for posting
 support questions -- instead use the django-users mailing list:
 http://groups.google.com/group/django-users

 Please do reopen this ticket if it appears that there is an actual error
 in the tutorial.

-- 
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] #16934: Tutorial 3: error in html editing

[Django]

#16934: Tutorial 3: error in html editing
-+-
   Reporter: |  Owner:  nobody
  humphries.grant@…  | Status:  new
   Type: |  Component:  Documentation
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by anonymous):

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


Comment:

 If someone could please respond to this as soon as possible it would be
 greatly appreciated

-- 
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] #16934: Tutorial 3: error in html editing

[Django]

#16934: Tutorial 3: error in html editing
---+---
 Reporter:  humphries.grant@…  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 In the section of tutorial 3 where we edit a new html file with:
 {% if latest_poll_list %}
 
 {% for poll in latest_poll_list %}
 {{ poll.question }}
 {% endfor %}
 
 {% else %}
 No polls are available.
 {% endif %}


 I kept getting an error saying that the {% else %} statement was an
 invalid block.

 I believe that it is supposed to be (% else %)  as opposed to {% else %}

-- 
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] #16929: The form for AUTH_PROFILE_MODULE should extend the basic User admin page

[Django]

#16929: The form for AUTH_PROFILE_MODULE should extend the basic User admin page
---+--
   Reporter:  jasper@… |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.auth
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:  auth, admin
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--
Changes (by charettes):

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


Comment:

 I think you can include the UserProfile admin inside the User admin doing
 the following:

 {{{
 #!python
 from django.contrib import Admin
 from django.contrib.auth.admin import UserAdmin
 from django.contrib.auth.models import User

 from my_user_profile_app import UserProfile

 # Define an inline admin descriptor for UserProfile model
 # which acts a bit like a singleton
 class UserProfileInline(admin.TabularInline):
 model = UserProfile
 fk_name = 'user'
 can_delete = False
 max_num = 1
 verbose_name_plural = _('profile')

 # Define a new User admin
 class UserAdmin(UserAdmin):
 inlines = (UserProfileInline, )

 # Re-register UserAdmin
 admin.site.unregister(User)
 admin.site.register(User, UserAdmin)
 }}}

-- 
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] r16904 - in django/trunk: django/contrib/formtools/wizard docs/ref/contrib/formtools

[noreply]

Author: ramiro
Date: 2011-09-25 18:37:57 -0700 (Sun, 25 Sep 2011)
New Revision: 16904

Modified:
   django/trunk/django/contrib/formtools/wizard/views.py
   django/trunk/docs/ref/contrib/formtools/form-wizard.txt
Log:
Fixed #16597 -- Added Sphinx cross-reference metadata to the form wizard docs. 
Thanks FunkyBob for the report and jkistler for the patch.

Also, additional fixes in that document and in the WizardView docstrings.

Modified: django/trunk/django/contrib/formtools/wizard/views.py
===
--- django/trunk/django/contrib/formtools/wizard/views.py   2011-09-25 
17:08:31 UTC (rev 16903)
+++ django/trunk/django/contrib/formtools/wizard/views.py   2011-09-26 
01:37:57 UTC (rev 16904)
@@ -124,7 +124,7 @@
   The key should be equal to the `step_name` in the `form_list` (or
   the str of the zero based counter - if no step_names added in the
   `form_list`)
-* `instance_dict` - contains a dictionary of instance objects. This 
list
+* `instance_dict` - contains a dictionary of instance objects. This
   is only used when `ModelForm`s are used. The key should be equal to
   the `step_name` in the `form_list`. Same rules as for `initial_dict`
   apply.
@@ -286,7 +286,7 @@
 
 def render_next_step(self, form, **kwargs):
 """
-THis method gets called when the next step/form should be rendered.
+This method gets called when the next step/form should be rendered.
 `form` contains the last/current form.
 """
 # get the form instance based on the data from the storage backend
@@ -349,14 +349,14 @@
 """
 Returns a object which will be passed to the form for `step`
 as `instance`. If no instance object was provied while initializing
-the form wizard, None be returned.
+the form wizard, None will be returned.
 """
 return self.instance_dict.get(step, None)
 
 def get_form_kwargs(self, step=None):
 """
 Returns the keyword arguments for instantiating the form
-(or formset) on given step.
+(or formset) on the given step.
 """
 return {}
 
@@ -404,7 +404,7 @@
 def render_revalidation_failure(self, step, form, **kwargs):
 """
 Gets called when a form doesn't validate when rendering the done
-view. By default, it changed the current step to failing forms step
+view. By default, it changes the current step to failing forms step
 and renders the form.
 """
 self.storage.current_step = step
@@ -428,7 +428,7 @@
 """
 Returns a merged dictionary of all step cleaned_data dictionaries.
 If a step contains a `FormSet`, the key will be prefixed with formset
-and contain a list of the formset' cleaned_data dictionaries.
+and contain a list of the formset cleaned_data dictionaries.
 """
 cleaned_data = {}
 for form_key in self.get_form_list():
@@ -532,7 +532,7 @@
 
 def render(self, form=None, **kwargs):
 """
-Returns a ``HttpResponse`` containing a all needed context data.
+Returns a ``HttpResponse`` containing all needed context data.
 """
 form = form or self.get_form()
 context = self.get_context_data(form, **kwargs)
@@ -540,7 +540,7 @@
 
 def done(self, form_list, **kwargs):
 """
-This method muss be overrided by a subclass to process to form data
+This method must be overridden by a subclass to process to form data
 after processing all steps.
 """
 raise NotImplementedError("Your %s class has not defined a done() "

Modified: django/trunk/docs/ref/contrib/formtools/form-wizard.txt
===
--- django/trunk/docs/ref/contrib/formtools/form-wizard.txt 2011-09-25 
17:08:31 UTC (rev 16903)
+++ django/trunk/docs/ref/contrib/formtools/form-wizard.txt 2011-09-26 
01:37:57 UTC (rev 16904)
@@ -90,9 +90,11 @@
 ---
 
 The next step is to create a
-:class:`django.contrib.formtools.wizard.view.WizardView` subclass. You can
-also use the :class:`SessionWizardView` or :class:`CookieWizardView` class
-which preselects the wizard storage backend.
+:class:`django.contrib.formtools.wizard.views.WizardView` subclass. You can
+also use the :class:`SessionWizardView` or :class:`CookieWizardView` classes
+which preselect the backend used for storing information during execution of 
the
+wizard (as their names indicate, server-side sessions and browser cookies
+respectively).
 
 .. note::
 
@@ -148,7 +150,8 @@
 default, every form uses a template called
 :file:`formtools/wizard/wizard_form.html`. You can change this template name
 by overriding either the :attr:`~WizardView.template_name` attribute or the
-:meth:`~WizardView.get_template_names()` 

Re: [Django] #16597: FormWizard doco mentions get_template_names() but does not document it.

[Django]

#16597: FormWizard doco mentions get_template_names() but does not document it.
-+-
   Reporter:  FunkyBob   |  Owner:  jkistler
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ramiro):

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


Comment:

 In [16904]:
 {{{
 #!CommitTicketReference repository="" revision="16904"
 Fixed #16597 -- Added Sphinx cross-reference metadata to the form wizard
 docs. Thanks FunkyBob for the report and jkistler for the patch.

 Also, additional fixes in that document and in the WizardView docstrings.
 }}}

-- 
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] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
-+-
   Reporter:  julien |  Owner:  ramiro
   Type:  New| Status:  closed
  feature|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by julien):

 Replying to [comment:41 kingtut]:
 > This is breaking apps that do not have add permissions (NoReverseMatch),
 e.g. django-mailchimp campaigns are always added remotely.

 Could you open a new ticket with a failing test case for this? 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] #15294: Use named urls instead of hard coded ones in admin views

[Django]

#15294: Use named urls instead of hard coded ones in admin views
-+-
   Reporter:  julien |  Owner:  ramiro
   Type:  New| Status:  closed
  feature|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by kingtut):

 This is breaking apps that do not have add permissions (NoReverseMatch),
 e.g. django-mailchimp campaigns are always added remotely.

 {{{
 if True in perms.values():
 info = (app_label, model._meta.module_name)
 model_dict = {
 'name': capfirst(model._meta.verbose_name_plural),
 'admin_url': mark_safe('%s/%s/' % (app_label,
 model.__name__.lower())),
 'admin_url': reverse('admin:%s_%s_changelist' % info,
 current_app=self.name),
 'add_url': reverse('admin:%s_%s_add' % info,
 current_app=self.name),
 }}}
 If the add or change permission is false, why bother resolving the url.
 Perhaps only include the 'add_url' when the 'add' permission exists?

 Or is is mandatory now that apps implement add, change and delete urls?

-- 
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] #16928: Django should officially switch to Git/Github for version control

[Django]

#16928: Django should officially switch to Git/Github for version control
---+---
   Reporter:  CannedCorn   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Uncategorized
Version:  1.3  |   Severity:  Normal
 Resolution:  invalid  |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+---

Comment (by russellm):

 Elaborating on (a) - the reasons *why* it won't happen are well
 documented, and have been discussed *many* times. Before you follow the
 advice in (b), please search the django-developers archive to get the
 historical context for this discussion.

-- 
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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
+---
   Reporter:  minarets  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   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:  1 |
+---

Comment (by julien):

 @ramiro: It works with all browsers, including Webkit-based ones, when
 using a plain `` widget. The problem here is that the javascript
 modifies the widget, in particular its `name` attribute. It's still
 unclear to me why Chrome behaves differently than other browsers, but it
 could be argued that Django's javascript is responsible for this issue and
 that it shouldn't be modifying the widget in such a way.

 By the way, the suggested workaround leaves the original `` widget
 alone, hides it, and uses the dynamically created 'from' and 'to' widgets
 only to handle the UI while updating the hidden widget in the background
 with the selected values, so that the browser only has to deal with a
 plain `` widget when submitting the form or when navigating to and
 away from the page.

-- 
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] #16916: Please document django.test.Client.defaults

[Django]

#16916: Please document django.test.Client.defaults
-+-
   Reporter: |  Owner:  nobody
  sailorfred@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by russellm):

 It is partially documented -- the !**extra argument is listed, and an
 example (using HTTP_X_REQUESTED_WITH) is provided in
 
[https://docs.djangoproject.com/en/1.3/topics/testing/#django.test.client.Client.get
 the API docs for the test client]. However, there is certainly room for a
 broad guide to the topic when the Test Client is introduced.

-- 
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] #16932: small problem with import django.conf.urls

[Django]

#16932: small problem with import django.conf.urls
---+---
   Reporter:  adamhammouda3@…  |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  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 but the tutorial is in fact correct since the
 functions in `django.conf.urls.defaults` have recently been moved to
 `django.conf.urls`. I assume you must be looking at the wrong version of
 the doc (i.e.  https://docs.djangoproject.com/en/dev/intro/tutorial03/
 instead of  https://docs.djangoproject.com/en/1.3/intro/tutorial03/).

 Now, this same (invalid) documentation bug has been reported multiple
 times in the last few days (i.e. in #16868, #16890). This is suggesting
 that it should be made more obvious on screen which version of the doc is
 being viewed. I've created this new ticket to specifically discuss this
 issue: #16933.

 Thanks again!

-- 
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] #16933: Make it more obvious on screen which version of the doc is being viewed

[Django]

#16933: Make it more obvious on screen which version of the doc is being viewed
-+-
 Reporter:  julien   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |Component:
Milestone:   |  Djangoproject.com Web site
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
 This came up as the same (invalid) doc bug in the tutorial was reported
 multiple times within just a few days (#16868, #16890 and #16932), likely
 because the reporters were looking at the wrong version of the
 documentation. This doesn't only affect newbies as I've also recently
 heard from an experienced Django developer that he got excited about a
 documented feature that he later realised he couldn't use in his
 environment because that feature hadn't been released yet (he was looking
 at the DEV doc without knowing). It's quite easy to get bitten by this,
 especially if you use Google to search the doc.

 One possible fix would be to add a nifty little block "DEV version" or
 "1.3 version" with a fixed position (e.g. stuck to the top of the
 viewport) as you scroll down the page.

 I'm choosing the component "Djangoproject.com Web site" (and not
 "Documentation") since this is where the change needs to happen, i.e. in:
 https://github.com/django/djangoproject.com

-- 
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] #16930: Class names ending with 'y' should be 'ie' in plural

[Django]

#16930: Class names ending with 'y' should be 'ie' in plural
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  duplicate  |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by kmtracey):

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


Comment:

 This is a dupe of a very old ticket, #569, that was closed wontfix. I
 don't think anything has changed in the interim to reverse that decision.
 Specify verbose_name_plural to get the correct plural shown in the admin.

-- 
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] #16931: "get_context_data" should follow MRO

[Django]

#16931: "get_context_data" should follow MRO
---+---
   Reporter:  linovia  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Generic views
Version:  1.3  |   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 linovia):

 * cc: linovia (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.

[Django] #16932: small problem with import django.conf.urls

[Django]

#16932: small problem with import django.conf.urls
-+---
 Reporter:  adamhammouda3@…  |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Documentation
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+---
 In lines (eg in polls/urls.py from your tutorial) where you say "from
 django.conf.urls import patterns, include, url", you should say "from
 django.conf.urls.defaults .  Probably just a minor oversight from the
 latest release, but urls is a directory from which you cannot access the
 specified functions --defaults.py has the functions specified.

-- 
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] #16931: "get_context_data" should follow MRO

[Django]

#16931: "get_context_data" should follow MRO
---+---
   Reporter:  linovia  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Generic views
Version:  1.3  |   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):

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


Old description:

> Actually, mixins do not allow to cumulate the context building.
>
> For example:
>
> class CommentMixin(FormMixin, SingleObjectMixin):
> pass
>
> In that case, we expect both FormMixin and SingleObjectMixin to build
> their context.
> However, as none of them use super in their get_context_data do use
> super, we only get the FormMixin context.
>
> The reason to use super here is not to call the parent get_context_data
> but the next class in MRO.
>
> {{{
> class A(object):
> def a(self):
> print "A"
> if hasattr(super(A, self), 'a'):
> super(A, self).a()
>

> class B(object):
> def a(self):
> print "B"
> if hasattr(super(B, self), 'a'):
> super(B, self).a()
>

> class C(object):
> def a(self):
> print "C"
>

> class D(B, A):
> pass
>

> class E(C, A):
> pass
>

> print "MRO:", [x.__name__ for x in D.__mro__]
> d = D()
> d.a()
>
> print "MRO:", [x.__name__ for x in E.__mro__]
> e = E()
> e.a()
> }}}
>
> With that example, one can see that d calls both B then A while e only
> calls C.
>
> While this might usually be unnoticed, it prevents Mixin to be chained.
> For example, mixing a single object item with a list (for a shop: one
> category with the associated products, for a bug tracker: a milestone
> with the associated tickets) or a single item with a form such as a post
> with a comment form.

New description:

 Actually, mixins do not allow to cumulate the context building.

 For example:
 {{{
 class CommentMixin(FormMixin, SingleObjectMixin):
 pass
 }}}
 In that case, we expect both FormMixin and SingleObjectMixin to build
 their context.
 However, as none of them use super in their get_context_data do use super,
 we only get the FormMixin context.

 The reason to use super here is not to call the parent get_context_data
 but the next class in MRO.

 {{{
 class A(object):
 def a(self):
 print "A"
 if hasattr(super(A, self), 'a'):
 super(A, self).a()


 class B(object):
 def a(self):
 print "B"
 if hasattr(super(B, self), 'a'):
 super(B, self).a()


 class C(object):
 def a(self):
 print "C"


 class D(B, A):
 pass


 class E(C, A):
 pass


 print "MRO:", [x.__name__ for x in D.__mro__]
 d = D()
 d.a()

 print "MRO:", [x.__name__ for x in E.__mro__]
 e = E()
 e.a()
 }}}

 With that example, one can see that d calls both B then A while e only
 calls C.

 While this might usually be unnoticed, it prevents Mixin to be chained.
 For example, mixing a single object item with a list (for a shop: one
 category with the associated products, for a bug tracker: a milestone with
 the associated tickets) or a single item with a form such as a post with a
 comment form.

--

-- 
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] #16931: "get_context_data" should follow MRO

[Django]

#16931: "get_context_data" should follow MRO
-+---
 Reporter:  linovia  |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Generic views
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+---
 Actually, mixins do not allow to cumulate the context building.

 For example:

 class CommentMixin(FormMixin, SingleObjectMixin):
 pass

 In that case, we expect both FormMixin and SingleObjectMixin to build
 their context.
 However, as none of them use super in their get_context_data do use super,
 we only get the FormMixin context.

 The reason to use super here is not to call the parent get_context_data
 but the next class in MRO.

 {{{
 class A(object):
 def a(self):
 print "A"
 if hasattr(super(A, self), 'a'):
 super(A, self).a()


 class B(object):
 def a(self):
 print "B"
 if hasattr(super(B, self), 'a'):
 super(B, self).a()


 class C(object):
 def a(self):
 print "C"


 class D(B, A):
 pass


 class E(C, A):
 pass


 print "MRO:", [x.__name__ for x in D.__mro__]
 d = D()
 d.a()

 print "MRO:", [x.__name__ for x in E.__mro__]
 e = E()
 e.a()
 }}}

 With that example, one can see that d calls both B then A while e only
 calls C.

 While this might usually be unnoticed, it prevents Mixin to be chained.
 For example, mixing a single object item with a list (for a shop: one
 category with the associated products, for a bug tracker: a milestone with
 the associated tickets) or a single item with a form such as a post with a
 comment form.

-- 
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] #10828: deleting all forms within a formset is not possible

[Django]

#10828: deleting all forms within a formset is not possible
+
   Reporter:  patrickk  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Forms
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  1 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+

Comment (by claudep):

 Thanks ramiro, I was probably misled by the title of the ticket which
 might rather be "Unable to access cleaned_data for deleted forms of a
 formset"...

 Anyway, the patch I proposed in #5524 should resolve this issue as well.

-- 
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] #16929: The form for AUTH_PROFILE_MODULE should extend the basic User admin page

[Django]

#16929: The form for AUTH_PROFILE_MODULE should extend the basic User admin page
-+--
 Reporter:  jasper@… |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  contrib.auth
  Version:  1.3  |   Severity:  Normal
 Keywords:  auth, admin  |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+--
 I've been struggling to get this done, failing in the end and reverting to
 two separate admin sections; one for users and one for user profiles. It
 seems that the only way to properly include the UserProfile admin inside
 the User admin is by overwriting the standard User admin template and
 view. If that's really the case, I'd say it makes sense to, instead,
 automatically extend the User admin with the form that belongs to the
 AUTH_PROFILE_MODULE model, since there is a one to one relationship
 between the two anyway.

-- 
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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
+---
   Reporter:  minarets  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   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:  1 |
+---

Comment (by ramiro):

 I'd like to suggest to the contributors that see this issue to also make
 sure they report it to their browser vendors (Webkit-based ones as can be
 gleaned from the comments posted) so such a problem is triaged and
 possibly fixed by them ASAP considering it can cause data corruption.

 I'd go even further and change the type value (''Bug'') of this ticket,
 unfortunately we don't have a value for such field that is more correct to
 describe the workaround Julien has implemented.

-- 
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] #16924: 'date' template filter displays certain timezones incorrectly

[Django]

#16924: 'date' template filter displays certain timezones incorrectly
-+-
   Reporter:  mrgriscom  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  template, date,
   Triage Stage:  Accepted   |  filter, timezone
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  1
-+-
Changes (by ramiro):

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


Comment:

 In [16903]:
 {{{
 #!CommitTicketReference repository="" revision="16903"
 Fixed #16924 -- Corrected `date` template filter handling of negative
 (West of UTC) timezone offsets.

 The 'O' format specifier output was incorrect. Thanks mrgriscom and
 Aymeric Augustin.
 }}}

-- 
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] r16903 - in django/trunk: django/utils tests/regressiontests/utils

[noreply]

Author: ramiro
Date: 2011-09-25 10:08:31 -0700 (Sun, 25 Sep 2011)
New Revision: 16903

Modified:
   django/trunk/django/utils/dateformat.py
   django/trunk/django/utils/tzinfo.py
   django/trunk/tests/regressiontests/utils/dateformat.py
Log:
Fixed #16924 -- Corrected `date` template filter handling of negative (West of 
UTC) timezone offsets.

The 'O' format specifier output was incorrect. Thanks mrgriscom and Aymeric 
Augustin.

Modified: django/trunk/django/utils/dateformat.py
===
--- django/trunk/django/utils/dateformat.py 2011-09-25 05:21:29 UTC (rev 
16902)
+++ django/trunk/django/utils/dateformat.py 2011-09-25 17:08:31 UTC (rev 
16903)
@@ -182,9 +182,11 @@
 return MONTHS_AP[self.data.month]
 
 def O(self):
-"Difference to Greenwich time in hours; e.g. '+0200'"
+"Difference to Greenwich time in hours; e.g. '+0200', '-0430'"
 seconds = self.Z()
-return u"%+03d%02d" % (seconds // 3600, (seconds // 60) % 60)
+sign = '-' if seconds < 0 else '+'
+seconds = abs(seconds)
+return u"%s%02d%02d" % (sign, seconds // 3600, (seconds // 60) % 60)
 
 def r(self):
 "RFC 2822 formatted date; e.g. 'Thu, 21 Dec 2000 16:01:07 +0200'"
@@ -275,8 +277,10 @@
 if not self.timezone:
 return 0
 offset = self.timezone.utcoffset(self.data)
-# Only days can be negative, so negative offsets have days=-1 and
-# seconds positive. Positive offsets have days=0
+# `offset` is a datetime.timedelta. For negative values (to the west of
+# UTC) only days can be negative (days=-1) and seconds are always
+# positive. e.g. UTC-1 -> timedelta(days=-1, seconds=82800, 
microseconds=0)
+# Positive offsets have days=0
 return offset.days * 86400 + offset.seconds
 
 def format(value, format_string):

Modified: django/trunk/django/utils/tzinfo.py
===
--- django/trunk/django/utils/tzinfo.py 2011-09-25 05:21:29 UTC (rev 16902)
+++ django/trunk/django/utils/tzinfo.py 2011-09-25 17:08:31 UTC (rev 16903)
@@ -13,7 +13,7 @@
 else:
 self.__offset = timedelta(minutes=offset)
 
-sign = offset < 0 and '-' or '+'
+sign = '-' if offset < 0 else '+'
 self.__name = u"%s%02d%02d" % (sign, abs(offset) / 60., abs(offset) % 
60)
 
 def __repr__(self):

Modified: django/trunk/tests/regressiontests/utils/dateformat.py
===
--- django/trunk/tests/regressiontests/utils/dateformat.py  2011-09-25 
05:21:29 UTC (rev 16902)
+++ django/trunk/tests/regressiontests/utils/dateformat.py  2011-09-25 
17:08:31 UTC (rev 16903)
@@ -127,3 +127,9 @@
 self.assertEqual(dateformat.format(summertime, 'O'), u'+0200')
 self.assertEqual(dateformat.format(wintertime, 'I'), u'0')
 self.assertEqual(dateformat.format(wintertime, 'O'), u'+0100')
+
+# Ticket #16924 -- We don't need timezone support to test this
+# 3h30m to the west of UTC
+tz = FixedOffset(-3*60 - 30)
+dt = datetime(2009, 5, 16, 5, 30, 30, tzinfo=tz)
+self.assertEqual(dateformat.format(dt, 'O'), u'-0330')

-- 
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] #16928: Django should officially switch to Git/Github for version control

[Django]

#16928: Django should officially switch to Git/Github for version control
---+---
   Reporter:  CannedCorn   |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Uncategorized
Version:  1.3  |   Severity:  Normal
 Resolution:  invalid  |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+---
Changes (by Alex):

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


Comment:

 a) This really probably isn't going to happen.

 b) Were is to, the ticket tracker is definitely not the appropriate place
 to suggest it, that would be the 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 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] #13956: Indefinite args for simpletags and inclusion tags

[Django]

#13956: Indefinite args for simpletags and inclusion tags
-+-
   Reporter:  melinath   |  Owner:  julien
   Type:  New| Status:  new
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  simple_tag,
 Resolution: |  simpletag
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by julien):

 Thanks a lot for the review and PEP8 cleanup, Jannis! I'll write a bit of
 documentation before pushing it in.

-- 
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] #16928: Django should officially switch to Git/Github for version control

[Django]

#16928: Django should officially switch to Git/Github for version control
-+---
 Reporter:  CannedCorn   |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Uncategorized
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  1
UI/UX:  0|
-+---
 I think there would be a lot more participation in the project if it was
 hosted on Github. Not like there isn't enough already but it just helps
 visibility.

-- 
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] #13956: Indefinite args for simpletags and inclusion tags

[Django]

#13956: Indefinite args for simpletags and inclusion tags
-+-
   Reporter:  melinath   |  Owner:  julien
   Type:  New| Status:  new
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  simple_tag,
 Resolution: |  simpletag
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

 * stage:  Accepted => Ready for checkin


Comment:

 LGTM, 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] #16926: Custom SQL with Windows or Mac end-of-lines fail with Python 3

[Django]

#16926: Custom SQL with Windows or Mac end-of-lines fail with Python 3
+--
   Reporter:  adsworth  |  Owner:  adsworth
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Python 3
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  1 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--

Comment (by aaugustin):

 In fact, I was surprised by the `'rbU'` pattern that appears nowhere else
 in Django, because the `b` and `U` flags are contradictory.

 It is intentional but apparently hackish: see the commit message of
 https://bitbucket.org/loewis/django-3k-old/changeset/0d7900201511

 It would be a good idea to check with MvL before changing this code again.

-- 
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] #16926: Custom SQL with Windows or Mac end-of-lines fail with Python 3

[Django]

#16926: Custom SQL with Windows or Mac end-of-lines fail with Python 3
+--
   Reporter:  adsworth  |  Owner:  adsworth
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Python 3
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  1 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--

Comment (by adsworth):

 In theory, yes.
 A py3k string, does not have a decode method though. So we need to pass
 the encoding parameter in case of py3k and call decode in case of py2.
 I'll create a new patch.

-- 
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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
+---
   Reporter:  minarets  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   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:  1 |
+---

Comment (by bpeschier):

 OSX 10.6:
  * Safari 5.1 ✓
  * !WebKit nightly (2011-09-25) ✓
  * Firefox 7.0 ✓
  * Aurora 8.0a2 ✓
  * Chrome 14.0 ✓
  * Chrome Canary 16.0 ✓
  * Opera 11.51 ✓
  * Camino 2.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] #16916: Please document django.test.Client.defaults (was: Please document django.test.Class.defaults)

[Django]

#16916: Please document django.test.Client.defaults
-+-
   Reporter: |  Owner:  nobody
  sailorfred@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Old description:

> The documentation makes it clear that I can provide an HTTP_USER_AGENT to
> the test client's methods, but it would have been nice to have it
> documented that the defaults exist, and how useful they are.

New description:

 The documentation makes it clear that I can provide an `HTTP_USER_AGENT`
 to the test client's methods, but it would have been nice to have it
 documented that the defaults exist, and how useful they are.

--

Comment:

 Defaults can also be passed in `Client.__init__`. Basically, these values
 just update the WSGI `environ` dictionary. There is no fixed list.

 The values from the keywords argument to the`get`/`post`/etc. methods have
 precedence, then those passed in `__init__`, and then the defaults.

 Indeed, this isn't documented.

-- 
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] #16919: Pass user to set_password_form in GET requests

[Django]

#16919: Pass user to set_password_form in GET requests
+--
   Reporter:  jaimeirurzun  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Milestone:|  Component:  contrib.auth
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
Changes (by aaugustin):

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


Comment:

 Technically, the patch works.

 However, I can't figure out a practical use case for prepopulating a
 password field that doesn't have security issues. I'd like to make sure
 this change doesn't encourage bad practices.

 Could you explain what you're trying to achieve?

-- 
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] #16792: DO NOT TRIAGE: This is a test ticket for Detracify

[Django]

#16792: DO NOT TRIAGE: This is a test ticket for Detracify
-+-
   Reporter:  robopony   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Uncategorized
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Apparently, the detracify has been active only on Sept. 9th. Nothing
 happened in the GitHub repo since then.

 Feel free to re-open this ticket, or open a new one, if you want to do
 more tests.

-- 
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] #16926: Custom SQL with Windows or Mac end-of-lines fail with Python 3

[Django]

#16926: Custom SQL with Windows or Mac end-of-lines fail with Python 3
+--
   Reporter:  adsworth  |  Owner:  adsworth
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Python 3
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  1 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
Changes (by aaugustin):

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


Comment:

 I think this is an artifact of the 2to3 conversion.

 Trunk has:
 {{{
 fp = open(sql_file, 'U')
 }}}
 while the py3k branch has:
 {{{
 fp = open(sql_file, 'rbU')
 }}}
 As far as I can tell, it should be enough to change the mode flag to `'U'`
 in the py3k branch.

-- 
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] #16925: disconnect signal before checking test success

[Django]

#16925: disconnect signal before checking test success
+--
   Reporter:  adsworth  |  Owner:  adsworth
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Python 3
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 aaugustin):

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


Comment:

 The best best way to ensure the signal gets disconnected is to use a try /
 finally. See attached patch.

 I'm not sure how to run the tests under Python 3 — I checked out the py3k
 branch, but runtests.py fails with this error:
 {{{
   File "runtests.py", line 118
 print "Importing application %s" % module_name
^
 SyntaxError: invalid syntax
 }}}

 If the new patch works for you, feel free to mark the ticket as 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.