date:20101207

[Changeset] r14855 - django/trunk/django/db/backends/oracle

2010-12-07 Thread noreply

Author: ikelly
Date: 2010-12-08 01:56:43 -0600 (Wed, 08 Dec 2010)
New Revision: 14855

Modified:
   django/trunk/django/db/backends/oracle/base.py
Log:
Replaced an ImportError with ImproperlyConfigured in the Oracle backend.

Modified: django/trunk/django/db/backends/oracle/base.py
===
--- django/trunk/django/db/backends/oracle/base.py  2010-12-08 04:03:30 UTC 
(rev 14854)
+++ django/trunk/django/db/backends/oracle/base.py  2010-12-08 07:56:43 UTC 
(rev 14855)
@@ -18,8 +18,11 @@
 if platform.system().upper().startswith('CYGWIN'):
 try:
 import ctypes
-except ImportError:
-raise ImportError("ctypes not found. The Oracle backend requires 
ctypes to operate correctly under Cygwin.")
+except ImportError, e:
+from django.core.exceptions import ImproperlyConfigured
+raise ImproperlyConfigured("Error loading ctypes: %s; "
+   "the Oracle backend requires ctypes to "
+   "operate correctly under Cygwin." % e)
 kernel32 = ctypes.CDLL('kernel32')
 for name, value in environ:
 kernel32.SetEnvironmentVariableA(name, value)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #1908: Having an app name the same as project name breaks manage.py ( unable to import projectname.settings )

2010-12-07 Thread Django

#1908: Having an app name the same as project name breaks manage.py ( unable to
import projectname.settings )
-+--
  Reporter:  si...@simon.net.nz  | Owner:  adrian
Status:  reopened| Milestone:
 Component:  django-admin.py |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by techtonik):

 * cc: techtonik (removed)
 * cc: techto...@gmail.com (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-upda...@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] #1908: Having an app name the same as project name breaks manage.py ( unable to import projectname.settings )

2010-12-07 Thread Django

#1908: Having an app name the same as project name breaks manage.py ( unable to
import projectname.settings )
-+--
  Reporter:  si...@simon.net.nz  | Owner:  adrian
Status:  reopened| Milestone:
 Component:  django-admin.py |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by techtonik):

 * cc: techtonik (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-upda...@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] #14041: Templates in function calls for sitemap

2010-12-07 Thread Django

#14041: Templates in function calls for sitemap
+---
  Reporter:  owcarnia   | Owner:
 
Status:  new| Milestone:  1.3   
 
 Component:  Contrib apps   |   Version:  1.2   
 
Resolution: |  Keywords:  sitemaps, 
sprintdec2010
 Stage:  Ready for checkin  | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * stage:  Accepted => Ready for checkin

Comment:

 Although the docs need some markup fixes, this is basically ready.

-- 
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-upda...@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] #14101: Localized DecimalField doesn't accept localized input

2010-12-07 Thread Django

#14101: Localized DecimalField doesn't accept localized input
---+
  Reporter:  dfoerster | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Internationalization  |   Version:  1.2 
Resolution:|  Keywords:  localize
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by charettes):

 * cc: charett...@gmail.com (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-upda...@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] #14101: Localized DecimalField doesn't accept localized input

2010-12-07 Thread Django

#14101: Localized DecimalField doesn't accept localized input
---+
  Reporter:  dfoerster | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Internationalization  |   Version:  1.2 
Resolution:|  Keywords:  localize
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by charettes):

 Any update on this ticket and mitchetls's approach? The DecimalField bug
 part (haven't tested the datimefield issue) is still present both in trunk
 and 1.2.3.

-- 
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-upda...@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] #1908: Having an app name the same as project name breaks manage.py ( unable to import projectname.settings )

2010-12-07 Thread Django

#1908: Having an app name the same as project name breaks manage.py ( unable to
import projectname.settings )
-+--
  Reporter:  si...@simon.net.nz  | Owner:  adrian
Status:  reopened| Milestone:
 Component:  django-admin.py |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by andialbrecht):

 * cc: albrecht.a...@gmail.com (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-upda...@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] #1908: Having an app name the same as project name breaks manage.py ( unable to import projectname.settings )

2010-12-07 Thread Django

#1908: Having an app name the same as project name breaks manage.py ( unable to
import projectname.settings )
-+--
  Reporter:  si...@simon.net.nz  | Owner:  adrian
Status:  reopened| Milestone:
 Component:  django-admin.py |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by andialbrecht):

 And another case is when you're unhappy and checkout a project into a
 directory named like a app in this project. IMO should provide better
 information (at least a hint) why it failed. As mentioned in comment:4
 it's a pain to find this 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-upda...@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] #14041: Templates in function calls for sitemap

2010-12-07 Thread Django

#14041: Templates in function calls for sitemap
---+
  Reporter:  owcarnia  | Owner: 
Status:  new   | Milestone:  1.3
 Component:  Contrib apps  |   Version:  1.2
Resolution:|  Keywords:  sitemaps, sprintdec2010
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by julien):

  * milestone:  => 1.3

Comment:

 Replying to [comment:4 julien]:
 > This patch adds the template customisation to box the `index` and
 `sitemap` views. While I was at it I wrote some tests for the `index`
 view, which didn't have any until now.

 Whoops, I meant to say "both", not "box". Cheekily pushing to the 1.3
 milestone :)

-- 
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-upda...@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] #5925: Unable to use urlresolvers (url, reverse ) feature in redirect argument of decorator user_passes_test

2010-12-07 Thread Django

#5925: Unable to use urlresolvers (url,reverse ) feature in redirect argument of
decorator user_passes_test
-+--
  Reporter:  anonymous   | Owner:  SmileyChris  
  
Status:  assigned| Milestone:  1.3  
  
 Component:  Core framework  |   Version:  SVN  
  
Resolution:  |  Keywords:  
urlresolver,reverse,decorator,url,permalink
 Stage:  Design decision needed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  1
  
Needs_better_patch:  1   |  
-+--
Comment (by charettes):

 Is this going to make 1.3? It's really useful when extending ModelAdmin
 and defining named urls within get_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-upda...@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] r14854 - django/branches/releases/1.2.X/tests/regressiontests/admin_scripts

2010-12-07 Thread noreply

Author: Alex
Date: 2010-12-07 22:03:30 -0600 (Tue, 07 Dec 2010)
New Revision: 14854

Modified:
   django/branches/releases/1.2.X/tests/regressiontests/admin_scripts/tests.py
Log:
[1.2.X] Ensure that a Popen object is closed promptly during the tests. 
Backport [14853].

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/admin_scripts/tests.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/admin_scripts/tests.py 
2010-12-08 04:03:07 UTC (rev 14853)
+++ django/branches/releases/1.2.X/tests/regressiontests/admin_scripts/tests.py 
2010-12-08 04:03:30 UTC (rev 14854)
@@ -119,6 +119,7 @@
 from subprocess import Popen, PIPE
 p = Popen(cmd, shell=True, stdin=PIPE, stdout=PIPE, stderr=PIPE)
 stdin, stdout, stderr = (p.stdin, p.stdout, p.stderr)
+p.wait()
 except ImportError:
 stdin, stdout, stderr = os.popen3(cmd)
 out, err = stdout.read(), stderr.read()

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r14853 - django/trunk/tests/regressiontests/admin_scripts

2010-12-07 Thread noreply

Author: Alex
Date: 2010-12-07 22:03:07 -0600 (Tue, 07 Dec 2010)
New Revision: 14853

Modified:
   django/trunk/tests/regressiontests/admin_scripts/tests.py
Log:
Ensure that a Popen object is closed promptly during the tests.

Modified: django/trunk/tests/regressiontests/admin_scripts/tests.py
===
--- django/trunk/tests/regressiontests/admin_scripts/tests.py   2010-12-08 
00:27:07 UTC (rev 14852)
+++ django/trunk/tests/regressiontests/admin_scripts/tests.py   2010-12-08 
04:03:07 UTC (rev 14853)
@@ -119,6 +119,7 @@
 from subprocess import Popen, PIPE
 p = Popen(cmd, shell=True, stdin=PIPE, stdout=PIPE, stderr=PIPE)
 stdin, stdout, stderr = (p.stdin, p.stdout, p.stderr)
+p.wait()
 except ImportError:
 stdin, stdout, stderr = os.popen3(cmd)
 out, err = stdout.read(), stderr.read()

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14802: feature request: add a method to Fields that is used to render the field as read-only

2010-12-07 Thread Django

#14802: feature request: add a method to Fields that is used to render the 
field as
read-only
-+--
  Reporter:  nickname123 | Owner:  cogat
  
Status:  new | Milestone:   
  
 Component:  django.contrib.admin|   Version:  1.2  
  
Resolution:  |  Keywords:  sprintdec2010 
hidden_widget
 Stage:  Design decision needed  | Has_patch:  0
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by nickname123):

 A "to readonly html string" method on the field is a better idea.  I
 misread your suggestion somewhat earlier.  Like I said above, I hadn't put
 too much thought into the idea because I wasn't sure how other people
 would react to the feature request.  Glad you gave some input =).

-- 
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-upda...@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] #14802: feature request: add a method to Fields that is used to render the field as read-only

2010-12-07 Thread Django

#14802: feature request: add a method to Fields that is used to render the 
field as
read-only
-+--
  Reporter:  nickname123 | Owner:  cogat
  
Status:  new | Milestone:   
  
 Component:  django.contrib.admin|   Version:  1.2  
  
Resolution:  |  Keywords:  sprintdec2010 
hidden_widget
 Stage:  Design decision needed  | Has_patch:  0
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by nickname123):

 Replying to [comment:6 cogat]:
 > I'll have a crack at this.

 [[BR]]

 Cool =).

-- 
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-upda...@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] #14802: feature request: add a method to Fields that is used to render the field as read-only

2010-12-07 Thread Django

#14802: feature request: add a method to Fields that is used to render the
field as
read-only
-+--
Reporter: nickname123 | Owner: cogat

Status: new | Milestone:

Component: django.contrib.admin| Version: 1.2

Resolution: | Keywords: sprintdec2010
hidden_widget
Stage: Design decision needed | Has_patch: 0

Needs_docs: 0 | Needs_tests: 0

Needs_better_patch: 0 |
-+--
Comment (by nickname123):

Replying to [comment:3 cogat]:
> Just to clarify, a widget in Django is its representation of an HTML
input element, so it doesn't make sense to use it for anything that
doesn't involve displaying and handling an input element. So for read-only
fields there's no need to use a widget.
>
> Given this, I think you're asking for each Field to have a method that
is called by admin that renders the field as a read-only HTML. That's
something I could get behind (it's better to attach field display to
fields than to models, and there are currently silly special-cases for
rendering BooleanFields as icons in the current code) but it needs a
design decision. Particularly, would the same method, or a variation on
it, be used to render the field in admin list views? What about mechanisms
for requiring external javascript/css files needed by the rendering? What
about specifying read-only fields (so the same method can be used) in non-
admin forms?
>
> However, without a patch this won't make it into 1.3, so I'll remove the
milestone.
[[BR]]

In regards to your comment about widgets being the wrong term... the html
input tag does have a readonly attribute
(http://www.w3schools.com/tags/att_input_readonly.asp). I was talking
about using this since widgets are the current way of displaying form
fields that are not readonly. This seemed to be the "correct" way to do
it.

However, I did not put much thought into how it would be best achieved
because I was not sure if the feature had been left out of Django on
purpose.

A "to html" method might be a better idea, but I am still in favor using a
widget. I think a widget gives a little more abstraction and fits better
with the current design. Using a widget opposed to a method on the model
would have the benefit of being easily overridden too. I think it is a
nifty feature to be able to override the default widgets on the model
forms used by the admin interface and there is no reason not to allow the
same level of tweaking with readonly fields.

(http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.formfield_overrides
and http://docs.djangoproject.com/en/dev/topics/forms/modelforms
/#overriding-the-default-field-types-or-widgets)

--
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-upda...@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] #14862: bad links

2010-12-07 Thread Django

#14862: bad links
+---
  Reporter:  kurdy  | Owner: 
Status:  new| Milestone: 
 Component:  Uncategorized  |   Version:  1.2
Resolution: |  Keywords: 
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by adamv):

  * owner:  adamv =>

Comment:

 These links look correct in the docs themselves; perhaps the website
 didn't generate the docs correctly on check-in? The docs build correctly
 locally.

-- 
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-upda...@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] #13805: Unable to use .raw() in multi-db environment

2010-12-07 Thread Django

#13805: Unable to use .raw() in multi-db environment
+---
  Reporter:  liangent   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  worksforme |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 Such an method already exists:
 {{{
 M.objects.db_manager('dbname').raw('...')
 }}}

 `raw()` isn't a queryset method, it's on the manager only. This is because
 you can't arbitrarily stick raw() on the end of any query, because the
 query might be filtered or otherwise modified in a way that raw() won't
 interact with.

 You can call using() on the end of a raw() because a raw() queryset has
 already locked out other filter()-type options.

-- 
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-upda...@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] #14863: default INSTALLED_APPS out of date

2010-12-07 Thread Django

#14863: default INSTALLED_APPS out of date
---+
 Reporter:  tgm|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 django.contrib.messages

 should be added to the list just before
 http://docs.djangoproject.com/en/dev/intro/tutorial01/#s-creating-a-project

-- 
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-upda...@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] #13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency

2010-12-07 Thread Django

#13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency
---+
  Reporter:  carljm| Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:|  Keywords:  session accessed vary 
cookie
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by carljm):

 Replying to [comment:15 christandiono]:
 > I have to say that, while changing the behavior of
 CACHE_MIDDLEWARE_ANONYMOUS_ONLY might seem like the route to take (and I'd
 certainly like it that way), I'm not sure it is: SessionMiddleware uses a
 different session per anonymous user because there are some sites that
 might actually require different sessions per anonymous user.

 Sure. If the session data is actually accessed during a request, then
 Vary: Cookie should be set on that response, and the cache middleware
 should respect it. Nothing here is questioning that, or the usefulness of
 anonymous sessions in general.

 But when nothing in a given request cycle has ever accessed the session,
 that particular response is not session-dependent and should be cached
 once for all users; for CACHE_MIDDLEWARE_ANONYMOUS_ONLY _itself_ to
 trigger the addition of Vary: Cookie is pointless and self-defeating.

 The thing you're missing, I think, is that the addition of Vary: Cookie
 should not be dependent on whether a session exists that is specific to a
 given browser session. If you have the session middleware enabled, that
 will always be true, and should be so. Regardless, a particular request
 that does not access the session data should not set Vary: Cookie.

 Sharing anonymous sessions, as you propose, seems to me to make anonymous
 sessions useless. Avoiding the creation of a session until login time
 might be interesting on its own merits as a feature request, but is a
 totally separate issue from this bug.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14862: bad links

2010-12-07 Thread Django

#14862: bad links
+---
  Reporter:  kurdy  | Owner:  adamv
Status:  new| Milestone:   
 Component:  Uncategorized  |   Version:  1.2  
Resolution: |  Keywords:   
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by adamv):

  * owner:  nobody => adamv
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 I can take a look at this tonight if no one gets to it 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-upda...@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] r14852 - django/trunk/docs/ref

2010-12-07 Thread noreply

Author: gabrielhurley
Date: 2010-12-07 18:27:07 -0600 (Tue, 07 Dec 2010)
New Revision: 14852

Modified:
   django/trunk/docs/ref/template-response.txt
Log:
Fixed #14855 -- General cleanup of the new TemplateResponse docs (grammar, 
spelling, reST). Thanks to adamv for the report and patch.

Modified: django/trunk/docs/ref/template-response.txt
===
--- django/trunk/docs/ref/template-response.txt 2010-12-07 14:59:57 UTC (rev 
14851)
+++ django/trunk/docs/ref/template-response.txt 2010-12-08 00:27:07 UTC (rev 
14852)
@@ -7,10 +7,10 @@
 .. module:: django.template.response
:synopsis: Classes dealing with lazy-rendered HTTP responses.
 
-Standard HttpResponse objects are static structures. They are provided
-with a block of pre-rendered content at time of construction, and
-while that content can be modified, it isn't in a form that makes it
-easy to perform modifications.
+Standard :class:`~django.http.HttpResponse` objects are static structures.
+They are provided with a block of pre-rendered content at time of
+construction, and while that content can be modified, it isn't in a form that
+makes it easy to perform modifications.
 
 However, it can sometimes be beneficial to allow decorators or
 middleware to modify a response *after* it has been constructed by the
@@ -18,13 +18,13 @@
 or put additional data into the context.
 
 TemplateResponse provides a way to do just that. Unlike basic
-HttpResponse objects, TemplateResponse objects retain the details of
-the template and context that was provided by the view to compute the
-response. The final output of the response is not computed until
+:class:`~django.http.HttpResponse` objects, TemplateResponse objects retain
+the details of the template and context that was provided by the view to
+compute the response. The final output of the response is not computed until
 it is needed, later in the response process.
 
-TemplateResponse objects
-
+SimpleTemplateResponse objects
+==
 
 .. class:: SimpleTemplateResponse()
 
@@ -33,9 +33,9 @@
 
 .. attribute:: SimpleTemplateResponse.template_name
 
-The name of the template to be rendered. Accepts
-:class:`django.template.Template` object, path to template or list
-of paths.
+The name of the template to be rendered. Accepts a
+:class:`~django.template.Template` object, a path to a template or list
+of template paths.
 
 Example: ``['foo.html', 'path/to/bar.html']``
 
@@ -46,12 +46,12 @@
 
 Example: ``{'foo': 123}``
 
-.. attr:: SimpleTemplateResponse.rendered_content:
+.. attribute:: SimpleTemplateResponse.rendered_content
 
 The current rendered value of the response content, using the current
 template and context data.
 
-.. attr:: SimpleTemplateResponse.is_rendered:
+.. attribute:: SimpleTemplateResponse.is_rendered
 
 A boolean indicating whether the response content has been rendered.
 
@@ -61,29 +61,30 @@
 
 .. method:: SimpleTemplateResponse.__init__(template, context=None, 
mimetype=None, status=None, content_type=None)
 
-Instantiates an
+Instantiates a
 :class:`~django.template.response.SimpleTemplateResponse` object
 with the given template, context, MIME type and HTTP status.
 
-``template`` is a full name of a template, or a sequence of
-template names. :class:`django.template.Template` instances can
-also be used.
+``template``
+The full name of a template, or a sequence of template names.
+:class:`~django.template.Template` instances can also be used.
 
-``context`` is a dictionary of values to add to the template
-context. By default, this is an empty dictionary.
-:class:`~django.template.Context` objects are also accepted as
-``context`` values.
+``context``
+A dictionary of values to add to the template context. By default,
+this is an empty dictionary. :class:`~django.template.Context` objects
+are also accepted as ``context`` values.
 
-``status`` is the HTTP Status code for the response.
+``status``
+The HTTP Status code for the response.
 
-``content_type`` is an alias for ``mimetype``. Historically, this
-parameter was only called ``mimetype``, but since this is actually
-the value included in the HTTP ``Content-Type`` header, it can
-also include the character set encoding, which makes it more than
-just a MIME type specification. If ``mimetype`` is specified (not
-``None``), that value is used. Otherwise, ``content_type`` is
-used. If neither is given, the ``DEFAULT_CONTENT_TYPE`` setting is
-used.
+``content_type``
+An alias for ``mimetype``. Historically, this parameter was only called
+``mimetype``, but since this is actually the value included in the HTTP
+``Content-Type`` header, it can also include the character set 
encoding,
+which makes it more than

Re: [Django] #14861: Importing settings in a module that contains a logging Handler causes circular import.

2010-12-07 Thread Django

#14861: Importing settings in a module that contains a logging Handler causes
circular import.
+---
  Reporter:  donspaulding   | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Documentation
  * needs_tests:  => 0
  * milestone:  => 1.3
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

Comment:

 I don't think there's much we can do here beyond having a documentation
 note warning of the problem.

-- 
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-upda...@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] #14862: bad links

2010-12-07 Thread Django

#14862: bad links
---+
 Reporter:  kurdy  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 On http://docs.djangoproject.com/en/dev/topics/forms/index/

 links in:

 About this document

 This document provides an introduction to Django’s form handling features.
 For a more detailed look at specific areas of the forms API, see The Forms
 API, Form fields, and Form and field validation.

 end dead

-- 
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-upda...@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] #13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency

2010-12-07 Thread Django

#13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency
---+
  Reporter:  carljm| Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:|  Keywords:  session accessed vary 
cookie
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by christandiono):

 Er, make that "if ANONYMOUS_SHARE_SESSION and
 request.user.is_anonymouse(), don't set Vary: Cookie".

-- 
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-upda...@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] #13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency

2010-12-07 Thread Django

#13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency
---+
  Reporter:  carljm| Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:|  Keywords:  session accessed vary 
cookie
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by christandiono):

 I have to say that, while changing the behavior of
 CACHE_MIDDLEWARE_ANONYMOUS_ONLY might seem like the route to take (and I'd
 certainly like it that way), I'm not sure it is: SessionMiddleware uses a
 different session per anonymous user because there are some sites that
 might actually require different sessions per anonymous user. Instead, I
 think there should be a new setting that causes SessionMiddleware to
 consider all anonymous users to be part of the same session, or not create
 sessions for anonymous users. Something like "if ANONYMOUS_SHARE_SESSION,
 don't set Vary: Cookie".

 CACHE_MIDDLEWARE_ANONYMOUS_ONLY doesn't kill anonymous caching efficiency;
 it's that we're trying to use it in a way it's not necessarily meant to be
 used...

-- 
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-upda...@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] #8190: Utilise help_text for TabularInline in Admin

2010-12-07 Thread Django

#8190: Utilise help_text for TabularInline in Admin
---+
  Reporter:  glenjamin | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by net147):

 * cc: net...@gmail.com (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-upda...@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] #14861: Importing settings in a module that contains a logging Handler causes circular import.

2010-12-07 Thread Django

#14861: Importing settings in a module that contains a logging Handler causes
circular import.
---+
 Reporter:  donspaulding   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 If `settings.py` contains the following config for LOGGING:

 {{{
 LOGGING = {
   'version': 1,
   'handlers': {
 'custom_handler': {
   'level': 'INFO',
   'class': 'myproject.logconfig.MyHandler',
 }
   }
 }
 }}}

 and `myproject/logconfig.py` has the following line before the `MyHandler`
 definition:

 {{{
 from django.conf import settings
 }}}

 The dictconfig module spits out a none-too-helpful traceback:

 {{{
 Traceback (most recent call last):
   File "manage.py", line 11, in 
 execute_manager(settings)
   File
 "/home/don/myproject/src/django/django/core/management/__init__.py", line
 438, in execute_manager
 utility.execute()
   File
 "/home/don/myproject/src/django/django/core/management/__init__.py", line
 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File
 "/home/don/myproject/src/django/django/core/management/__init__.py", line
 252, in fetch_command
 app_name = get_commands()[subcommand]
   File
 "/home/don/myproject/src/django/django/core/management/__init__.py", line
 101, in get_commands
 apps = settings.INSTALLED_APPS
   File "/home/don/myproject/src/django/django/utils/functional.py", line
 276, in __getattr__
 self._setup()
   File "/home/don/myproject/src/django/django/conf/__init__.py", line 41,
 in _setup
 self._wrapped = Settings(settings_module)
   File "/home/don/myproject/src/django/django/conf/__init__.py", line 126,
 in __init__
 logging_config_func(self.LOGGING)
   File "/home/don/myproject/src/django/django/utils/dictconfig.py", line
 553, in dictConfig
 dictConfigClass(config).configure()
   File "/home/don/myproject/src/django/django/utils/dictconfig.py", line
 352, in configure
 '%r: %s' % (name, e))
 ValueError: Unable to configure handler 'custom_handler': Unable to
 configure handler 'custom_handler': 'module' object has no attribute
 'logconfig'
 }}}

 The problem is easily rectified once you realize that it's a circular
 import.  Apart from lazily loading the logging config, I'm not even sure
 there's an appropriate code fix.  I'm mainly filing this bug to see if a
 note can be placed alongside the logging configuration docs that warns of
 the potential problem.

-- 
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-upda...@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] #14301: django crashes on email address that passed validate_email() (utf8-tld)

2010-12-07 Thread Django

#14301: django crashes on email address that passed validate_email()  (utf8-tld)
---+
  Reporter:  harm  | Owner:  nobody
Status:  reopened  | Milestone:  1.3   
 Component:  django.core.mail  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by claudep):

  * needs_better_patch:  1 => 0
  * has_patch:  0 => 1

Comment:

 Just attached a patch using the idea on comment 12 from andialbrecht. I
 choose to use the encode-at-the-last-moment approach. Note that only the
 addresses really used by SMTP to send the messages are idna encoded, not
 the addresses in the message headers.

-- 
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-upda...@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] #7231: New "join" parameter for the "extra" QuerySet method

2010-12-07 Thread Django

#7231: New "join" parameter for the "extra" QuerySet method
---+
  Reporter:  Davide "Design" Muzzarelli| Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:  wontfix   |  Keywords:  queryset 
extra left join
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  1 |  
---+
Changes (by bendavis78):

 * cc: bendavi...@gmail.com (added)

Comment:

 Adding my vote for re-opening this patch.  I've been using this patch for
 nearly two years, and have found it to be useful in several different
 cases.  I agree with jonozzz that it completes the .extra() functionality,
 and allows for more flexibility than raw() can provide.  For example, if
 I'm dynamically building my query using django,  and I need to add custom
 joins to the existing queryset,  it's much cleaner to use .extra() instead
 of .raw().

-- 
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-upda...@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] #14860: Various PL localflavor fields don't handle EMPTY_VALUES correctly

2010-12-07 Thread Django

#14860: Various PL localflavor fields don't handle EMPTY_VALUES correctly
+---
 Reporter:  idangazit   |   Owner:  idangazit 
   Status:  new |   Milestone:
Component:  django.contrib.localflavor  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 Fields with required=False should not choke while cleaning any value in
 EMPTY_VALUES (from django.core.validators):

 EMPTY_VALUES = (None, , [], (), {})

-- 
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-upda...@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] #14858: Bug in admin change_form template produces javascript error when adding new object with first_field of type DateTimeField.

2010-12-07 Thread Django

#14858: Bug in admin change_form template produces javascript error when adding 
new
object with first_field of type DateTimeField.
---+
  Reporter:  mkelley33 | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  django.contrib.admin  |   Version:  1.2
 
Resolution:|  Keywords:  admin templates 
javascript error
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Old description:

> '''Scenario:'''
>
> 1. User fires up admin site in browser (bug is not browser specific), and
> goes to admin/app_name/model_name/
> 2. User clicks the add button in upper-right-hand corner.
> 3. The change_form.html template is rendered, and ready to add a new
> object.
> 4. Then the user's browser complains and throws an error, because the
> user
>(for whatever--probably strange and arguably wrong--reason) made
> created_datetime
>of type DateTimeField be the first_field.
>

> '''Error or Bug:'''
>
> {{{
> Error: document.getElementById("id_created_date") is null
> Source File: http://127.0.0.1:8000/admin/app_name/model_name/add/
> }}}
>

> '''Cause:'''
>
> The DateTimeField outputs two fields:
>
> 1. created_date_0
> 2. created_date_1
>
> '''Solution:'''
>
> See attached patch file.

New description:

 '''Scenario:'''

  1. User fires up admin site in browser (bug is not browser specific), and
 goes to admin/app_name/model_name/
  2. User clicks the add button in upper-right-hand corner.
  3. The change_form.html template is rendered, and ready to add a new
 object.
  4. Then the user's browser complains and throws an error, because the
 user (for whatever--probably strange and arguably wrong--reason) made
 created_datetime of type DateTimeField be the first_field.


 '''Error or Bug:'''

 {{{
 Error: document.getElementById("id_created_date") is null
 Source File: http://127.0.0.1:8000/admin/app_name/model_name/add/
 }}}


 '''Cause:'''

 The DateTimeField outputs two fields:

  1. created_date_0
  2. created_date_1

 '''Solution:'''

 See attached patch file.

Comment:

 This had already been reported as #14364. Will try to reproduce with the
 more detailed instructions above before deciding final triage status.

-- 
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-upda...@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] #14859: Various IT localflavor fields don't handle EMPTY_VALUES correctly

2010-12-07 Thread Django

#14859: Various IT localflavor fields don't handle EMPTY_VALUES correctly
+---
 Reporter:  idangazit   |   Owner:  idangazit 
   Status:  new |   Milestone:
Component:  django.contrib.localflavor  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 Fields with required=False should not choke while cleaning any value in
 EMPTY_VALUES (from django.core.validators):

 EMPTY_VALUES = (None, '', [], (), {})

-- 
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-upda...@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] #13721: pass extra content-type values to file upload handlers

2010-12-07 Thread Django

#13721: pass extra content-type values to file upload handlers
---+
  Reporter:  wkornewald| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  File uploads/storage  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by lrekucki):

  * needs_docs:  0 => 1
  * needs_tests:  0 => 1
  * stage:  Design decision needed => Accepted

Comment:

 Probably a simple test case and some docs for people that need this. I see
 no obvious reason not to do this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14858: Bug in admin change_form template produces javascript error when adding new object with first_field of type DateTimeField.

2010-12-07 Thread Django

#14858: Bug in admin change_form template produces javascript error when adding 
new
object with first_field of type DateTimeField.
--+-
 Reporter:  mkelley33 |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:  admin templates javascript error  |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 '''Scenario:'''

 1. User fires up admin site in browser (bug is not browser specific), and
 goes to admin/app_name/model_name/
 2. User clicks the add button in upper-right-hand corner.
 3. The change_form.html template is rendered, and ready to add a new
 object.
 4. Then the user's browser complains and throws an error, because the user
(for whatever--probably strange and arguably wrong--reason) made
 created_datetime
of type DateTimeField be the first_field.


 '''Error or Bug:'''

 {{{
 Error: document.getElementById("id_created_date") is null
 Source File: http://127.0.0.1:8000/admin/app_name/model_name/add/
 }}}


 '''Cause:'''

 The DateTimeField outputs two fields:

 1. created_date_0
 2. created_date_1

 '''Solution:'''

 See attached patch file.

-- 
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-upda...@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] #13721: pass extra content-type values to file upload handlers

2010-12-07 Thread Django

#13721: pass extra content-type values to file upload handlers
-+--
  Reporter:  wkornewald  | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  File uploads/storage|   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by wkornewald):

  * has_patch:  0 => 1

Comment:

 What does it take to get this committed into trunk? This change is
 absolutely necessary for App Engine's Blobstore and it's a really harmless
 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-upda...@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] #14857: [patch] has_results cleanup

2010-12-07 Thread Django

#14857: [patch] has_results cleanup
---+
 Reporter:  wkornewald |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 The attached patch moves the SQL-specific code (just three lines) from
 sql.Query to SQLCompiler. This allows to override the has_results()
 behavior in the backend which is needed for NoSQL support. It would be
 nice if you could commit the patch. 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-upda...@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] #1908: Having an app name the same as project name breaks manage.py ( unable to import projectname.settings )

2010-12-07 Thread Django

#1908: Having an app name the same as project name breaks manage.py ( unable to
import projectname.settings )
-+--
  Reporter:  si...@simon.net.nz  | Owner:  adrian
Status:  reopened| Milestone:
 Component:  django-admin.py |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by techtonik):

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

Comment:

 There is one more case not caught by manage.py and it is very hard to
 debug. Inside project directory you can't have a package similarly named.
 Repeatable on Python 2.5/2.7, Django 1.1.2/1.2.3

 {{{
 > python django-admin.py startproject fudge
 > cd fudge
 > python manage.py runserver
 Validating models...
 0 errors found

 Django version 1.1.2 SVN-14851, using settings 'fudge.settings'
 Development server is running at http://127.0.0.1:8000/
 Quit the server with CTRL-BREAK.
 }}}
 Now create child fudge/ directory with `__init__.py` inside.
 {{{
 >mkdir fudge
 >echo #>fudge\__init__.py
 >python manage.py runserver --traceback -v 2
 Error: Could not import settings 'fudge.settings' (Is it on sys.path? Does
 it have syntax errors?): No module named settings
 }}}

 I've wasted some precious hours troubleshooting new Rietveld installation
 due to this bug. Note that traceback is not displayed even though it is
 requested explicitly.

-- 
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-upda...@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] #13805: Unable to use .raw() in multi-db environment

2010-12-07 Thread Django

#13805: Unable to use .raw() in multi-db environment
+---
  Reporter:  liangent   | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by limscoder):

  * has_patch:  0 => 1

Comment:

 I attached a patch that implements the following signature: .raw(sql,
 params, using=default).

-- 
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-upda...@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] #14856: [patch] cleanup of ForeignKey.db_type

2010-12-07 Thread Django

#14856: [patch] cleanup of ForeignKey.db_type
--+-
 Reporter:  wkornewald|   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 The attached patch cleans up the db_type() function for ForeignKey. It
 adds a Field.related_db_type() method which returns the db_type for the
 ForeignKey pointing at that field. Previously, ForeignKey.db_type() had
 hard-coded isinstance() checks.

-- 
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-upda...@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] #13805: Unable to use .raw() in multi-db environment

2010-12-07 Thread Django

#13805: Unable to use .raw() in multi-db environment
+---
  Reporter:  liangent   | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by limscoder):

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

Comment:

 I have the same issue with 1.2.

 The code M.objects.using('dbname').raw('...') causes the error: 'QuerySet'
 object has no attribute 'raw'.

 The 'raw' method needs some way to specify which database to use. Perhaps
 a signature such as: .raw(sql, params, database=default)

-- 
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-upda...@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] #5217: Settings are unable to be imported if project name is the same as the parent directory

2010-12-07 Thread Django

#5217: Settings are unable to be imported if project name is the same as the
parent directory
-+--
  Reporter:  spe.stani...@gmail.com  | Owner:  jacob
Status:  closed  | Milestone:   
 Component:  Documentation   |   Version:  SVN  
Resolution:  duplicate   |  Keywords:   
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by techtonik):

 Wrong duplicate, the problem is in #1908 and it is repeatable with Django
 1.1.2 and Python 2.7

-- 
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-upda...@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] #14855: Tweak reST in new TemplateResponse docs

2010-12-07 Thread Django

#14855: Tweak reST in new TemplateResponse docs
+---
  Reporter:  adamv  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by adamv):

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

Comment:

 As a side note, in these docs and the existing "HttpResponse" doc, it
 might be worth rewriting the note for the content_type/mimetype parameter,
 to remove the "historical note", make content_type current, and have a
 separate entry for mimetype that says it is a deprecated parameter.

-- 
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-upda...@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] #14855: Tweak reST in new TemplateResponse docs

2010-12-07 Thread Django

#14855: Tweak reST in new TemplateResponse docs
---+
 Reporter:  adamv  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Some reST, formatting, spelling tweaks for the new TemplateResponse docs.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14662: auth and contenttypes post-syncdb handlers ignore 'db' option

2010-12-07 Thread Django

#14662: auth and contenttypes post-syncdb handlers ignore 'db' option
---+
  Reporter:  marcop| Owner:  nobody
Status:  closed| Milestone:  1.3   
 Component:  Contrib apps  |   Version:  SVN   
Resolution:  invalid   |  Keywords:  management muti_db
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by russellm):

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

Comment:

 The contenttype and auth post_syncdb handlers ignore --db by design --
 they should be (and are) using the router to determine where content types
 should be written.

 If running `sycndb` on `other` causes an error because `default` doesn't
 exist, then that means you have a dependency in your database setup, and
 you need to run `sycndb` on `default` first. #14799 was the manifestation
 of this problem in the test suite.

 Similarly, createsuperuser shoudn't be overriding the default routing
 behavior for the User model.

-- 
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-upda...@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] #14854: Follow PEP 8 -- Style Guide for Python Code

2010-12-07 Thread Django

#14854: Follow PEP 8 -- Style Guide for Python Code
-+--
  Reporter:  sorl| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.2   
Resolution:  wontfix |  Keywords:  pep8  
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 Ok so finally for some metrics.
 Lines of code was collected by issuing (at top level of distribution
 packages):
 {{{
 find -name "*.py" | xargs wc -l
 }}}

 Lines that have more than 79 characters were collected issuing (at top
 level of distribution packages):
 {{{
find -name "*.py" | xargs awk '{ if (length($0) > 79) printf("%s:%s\n",
 FILENAME, FNR);}' | wc -l
 }}}

 Results:
 ||What|| LOCS   || Lines > 79 chars || Ratio
 ||Django trunk|| 101106 || 4525 || 4.48%
 ||Turbo Gears dev || 8781   || 296  || 3.37%
 ||Pylons latest   || 10378  || 218  || 2.10%
 ||Zope 3.4.0c1|| 269273 || 4626 || 1.72%
 ||Twisted 10.2.0  || 269535 || 2946 || 1.09%
 ||Grok trunk  || 7352   || 26   || 0.35%

-- 
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-upda...@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] r14851 - django/trunk/docs/topics/http

2010-12-07 Thread noreply

Author: russellm
Date: 2010-12-07 08:59:57 -0600 (Tue, 07 Dec 2010)
New Revision: 14851

Modified:
   django/trunk/docs/topics/http/middleware.txt
Log:
Corrected typo in middleware docs. Thanks to matt_c for the report.

Modified: django/trunk/docs/topics/http/middleware.txt
===
--- django/trunk/docs/topics/http/middleware.txt2010-12-07 13:57:01 UTC 
(rev 14850)
+++ django/trunk/docs/topics/http/middleware.txt2010-12-07 14:59:57 UTC 
(rev 14851)
@@ -112,11 +112,11 @@
 Django view.
 
 ``process_template_response()`` must return an
-:class:`~django.template.response.SimpleTemplateResponse` (or it's subclass)
+:class:`~django.template.response.SimpleTemplateResponse` (or its subclass)
 object. It could alter the given ``response`` by changing
 ``response.template_name`` and ``response.template_context``, or it could
 create and return a brand-new
-:class:`~django.template.response.SimpleTemplateResponse` (or it's subclass)
+:class:`~django.template.response.SimpleTemplateResponse` (or its subclass)
 instance.
 
 ``process_template_response()`` will only be called if the response

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14844: i18n blocktrans tag pluralization feature limited by gettext constraints and unique local tag context

2010-12-07 Thread Django

#14844: i18n blocktrans tag pluralization feature limited by gettext constraints
and unique local tag context
---+
  Reporter:  ramiro| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Internationalization  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by jezdez):

 Replying to [comment:4 claudep]:
 > Unless verbose_name_plural itself is fixed (but how can it be fixed if
 the plural count is not known beforehand?), the solution proposed by
 jezdez is unfortunately still wrong for many languages.

 Yeah, assuming the fix is possible.

-- 
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-upda...@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] #14844: i18n blocktrans tag pluralization feature limited by gettext constraints and unique local tag context

2010-12-07 Thread Django

#14844: i18n blocktrans tag pluralization feature limited by gettext constraints
and unique local tag context
---+
  Reporter:  ramiro| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Internationalization  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by claudep):

 Unless verbose_name_plural itself is fixed (but how can it be fixed if the
 plural count is not known beforehand?), the solution proposed by jezdez is
 unfortunately still wrong for many languages.

-- 
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-upda...@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] #14844: i18n blocktrans tag pluralization feature limited by gettext constraints and unique local tag context

2010-12-07 Thread Django

#14844: i18n blocktrans tag pluralization feature limited by gettext constraints
and unique local tag context
---+
  Reporter:  ramiro| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Internationalization  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by jezdez):

 As a long term fix syntax I'd like to propose:

 {{{
 {% blocktrans with cl.opts.verbose_name as vname count cl.result_count as
 count %}
 {{ count }} {{ vname }}
 {% plural with cl.opts.verbose_name_plural as vname %}
 {{ count }} {{ vname }}
 {% endblocktrans %}
 }}}

-- 
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-upda...@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] #14854: Follow PEP 8 -- Style Guide for Python Code

2010-12-07 Thread Django

#14854: Follow PEP 8 -- Style Guide for Python Code
-+--
  Reporter:  sorl| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.2   
Resolution:  wontfix |  Keywords:  pep8  
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by sorl):

 Sure, I'd argue that readability can be good with longer lines but most of
 the time its not and its a sign that you should write it a bit
 differently. For example this code is not better off using long lines in
 my mind:

 
https://github.com/django/django/blob/master/django/views/generic/date_based.py#L269

 For what its worth I think grok code looks really nice as a comparison:
 http://svn.zope.org/repos/main/grok/trunk/src/grok/

-- 
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-upda...@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] #14827: Authentication Backends should be responsible for checking and setting passwords

2010-12-07 Thread Django

#14827: Authentication Backends should be responsible for checking and setting
passwords
-+--
  Reporter:  andornaut   | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Someday/Maybe   | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by jezdez):

 Replying to [comment:4 andornaut]:
 > Replying to [comment:3 jezdez]:
 > > So this is entirely possible right now by overriding the
 password_change view's `password_change_form` parameter with a subclass of
 `SetPasswordForm/PasswordChangeForm` that overrides its save() method to
 save the password somewhere else.
 >
 > The User model's `save()` method will still default to md5. Subclassing
 User in various places in order to override its `save()` seems like a less
 ideal solution.
 >
 > Additionally, this change does not need to be disruptive. It could
 default to the current behavior if the `AuthenticationBackend` doesn't
 provide save and check password functionality.

 While the waterfall approach for checking credentials works pretty good, I
 don't think this should be applied to saving passwords, too. It adds a bit
 of uncertainty to something rather important. Feel free to start a
 discussion on django-developers if you want to discuss this further.

-- 
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-upda...@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] #10827: django.auth create_permissions must clear the content type cache before creating permissions

2010-12-07 Thread Django

#10827: django.auth create_permissions must clear the content type cache before
creating permissions
-+--
  Reporter:  seanl   | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by PeterRussell):

 It seems that the reason that this happens is that the syncdb command is
 firing the post_syncdb signal for each application, as returned from
 get_apps() [source:/django/trunk/django/core/management/sql...@14849#l178
 here].  Get_apps appears to return apps in app-name order (see
 [source:/django/trunk/django/db/models/loading...@14849#l120 here]), and
 auth comes before contenttypes asciibetically.  It seems the right
 solution is probably to have a separate post_contenttypes_refreshed
 signal, and have create_permissions listen for that.  It would also be
 great if updating permissions could fire its own signal, so you can update
 groups etc based on that. (We've been having a somewhat similar 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-upda...@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] #14854: Follow PEP 8 -- Style Guide for Python Code

2010-12-07 Thread Django

#14854: Follow PEP 8 -- Style Guide for Python Code
-+--
  Reporter:  sorl| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.2   
Resolution:  wontfix |  Keywords:  pep8  
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 Closing wontfix, for two reasons.

 Firstly, the opening comments of PEP8 has a whole section entitled "A
 foolish consistency is the hobgoblin of little minds". This ticket is
 exactly the kind of prescriptive nonsense that that comment was directed
 at. Overall readability is more important than concrete adherence to a
 rulebook. Sometimes the 79 character limit is an impediment to
 readability. When this happens is entirely a matter of judgement, but
 pointing at PEP8 as a limit that must be enforced at all cost completely
 misses the point of PEP8.

 Secondly, and more importantly, there is no course of action for this
 ticket -- something that the ticket description itself acknowledges.

-- 
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-upda...@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] #14854: Follow PEP 8 -- Style Guide for Python Code

2010-12-07 Thread Django

#14854: Follow PEP 8 -- Style Guide for Python Code
+---
 Reporter:  sorl|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  pep8|   Stage:  Unreviewed
Has_patch:  0   |  
+---
 There is currently a lot of Django code that violates the PEP 8 style
 guide with respect to "Maximum Line Length - Limit all lines to a maximum
 of 79 characters.". I don't think this is a problem for "old" code and
 there is no need to go fix it unless you have got nothing better to do.
 How ever for recent commits there is no valid reason not to follow this
 recommendation from my standpoint. It is almost as if this has grown into
 an own django-long-lines cult, people will look at Django code and copy
 these bad long-lines examples. In particular I was looking at the Class
 Based Generic views which is a recent commit and it contains quite a few
 lines longer than 79 characters.

-- 
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-upda...@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] #14451: add related_name to contrib.auth.models.User for 'groups'

2010-12-07 Thread Django

#14451: add related_name to contrib.auth.models.User for 'groups'
+---
  Reporter:  tvon   | Owner:  anonymous
Status:  assigned   | Milestone:  2.0  
 Component:  Uncategorized  |   Version:  1.2  
Resolution: |  Keywords:   
 Stage:  Someday/Maybe  | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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.

55 matches

Mail list logo