Re: [Django] #12417: Add signing and signed cookies to Django

[Django]

#12417: Add signing and signed cookies to Django
-+--
  Reporter:  simon   | Owner:  simon
Status:  new | Milestone:  1.3  
 Component:  Core framework  |   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #12901: Forms _get_validations_exclusions is still not backwards compatible

[Django]

#12901: Forms _get_validations_exclusions is still not backwards compatible
--+-
  Reporter:  SmileyChris  | Owner:  nobody
Status:  reopened | Milestone:  1.2   
 Component:  Forms|   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Changes (by ammarr):

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

-- 
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] #3349: If an ImportError occurs within some loaders a rather confusing exception is raised.

[Django]

#3349: If an ImportError occurs within some loaders a rather confusing exception
is raised.
+---
  Reporter:  Chris Wagner   | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Template system|   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Changes (by andrewbadr):

  * owner:  andrewbadr => nobody

-- 
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] #12312: MultiLineString OGRGeometry dimensions change on transform

[Django]

#12312: MultiLineString OGRGeometry dimensions change on transform
---+
  Reporter:  yourcelf  | Owner:  jbronn 
Status:  reopened  | Milestone: 
 Component:  GIS   |   Version:  SVN
Resolution:|  Keywords:  gdal OGRGeometry 3D
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by jbronn):

 Replying to [comment:5 yourcelf]:
 > Apologies if there was confusion: the reported dimension (e.g.
 ``coord_dim``) is not the problem this bug report is about.  The problem
 this bug report is about is the returned WKT string.

 Thanks for clarifying yourcelf, I see exactly what you're talking about
 now.  This doesn't occur on 1.7, but I'm seeing it on 1.5 (and, I'm also
 assuming 1.6).  Thus, this smells to me still like a manifestation of the
 original bug I found in OGR -- even though I'm changing the coordinate
 dimension back to what it should be, it's coordinates still have Z values
 set internally (to 0.0, instead of NULL) after the transform, and the WKT
 serialization code may be "dumb" and look to see if it's NULL rather than
 verifying w/the coordinate dimension.

 I'll see if I can find a workaround again inside GeoDjango, but there may
 be nothing I can do, as the solution would be to fix the WKT serialization
 code in 1.5.X and 1.6.X branches of GDAL.  Unfortunately, I may have to
 close as invalid if that's the case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #12648: [PATCH]User send_email change from send_mail to EmailMessage

[Django]

#12648: [PATCH]User send_email change from send_mail to EmailMessage
-+--
  Reporter:  galuszkak   | Owner:  galuszkak
 
Status:  closed  | Milestone:   
 
 Component:  Authentication  |   Version:  SVN  
 
Resolution:  invalid |  Keywords:  send_mail, email, 
send_email, EmailMessage
 Stage:  Unreviewed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 send_mail() is nothing but
 
[http://code.djangoproject.com/browser/django/trunk/django/core/mail/__init__.py#L44
 a light wrapper around EmailMessage]. Your assertion that send_mail fails,
 but EmailMessage works doesn't make any sense.

 *If* there is something going wrong, the problem is a lot more complex
 than what you're describing. However, I have lots of evidence that this is
 working fine, not the least of which is a fully passing test suite and
 production code that is successfully sending lots of mail.

 So - I'm marking this invalid again. If you want to debug this, take it to
 Django-users. Once it has been nailed down to a *specific* problem, bring
 it back to Trac.

-- 
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] #7722: EMail Message with CC - Carbon Copy

[Django]

#7722: EMail Message with CC - Carbon Copy
-+--
  Reporter:  roberto.digirolamo   | Owner:  
nobody
Status:  new | Milestone:   
 
 Component:  django.core.mail|   Version:  
SVN   
Resolution:  |  Keywords:   
 
 Stage:  Design decision needed  | Has_patch:  
1 
Needs_docs:  1   |   Needs_tests:  
1 
Needs_better_patch:  0   |  
-+--
Comment (by danny...@toldme.com):

 Gert speaks for me, and I think he speaks for many others.

 +1 here!

 Thanks,
 -danny

-- 
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] #12312: MultiLineString OGRGeometry dimensions change on transform

[Django]

#12312: MultiLineString OGRGeometry dimensions change on transform
---+
  Reporter:  yourcelf  | Owner:  jbronn 
Status:  reopened  | Milestone: 
 Component:  GIS   |   Version:  SVN
Resolution:|  Keywords:  gdal OGRGeometry 3D
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by yourcelf):

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

Comment:

 Replying to [comment:4 jbronn]:

 Apologies if there was confusion: the reported dimension (e.g.
 ``coord_dim``) is not the problem this bug report is about.  The problem
 this bug report is about is the returned WKT string.

 If I create a 2D OGRGeometry object, e.g. ``OGRGeometry("MULTILINESTRING
 ((0 0,1 1,2 2))")``, and then call ``transform``, the object will
 subsequently return 3D WKT (e.g. ``MULTILINESTRING ((0 0 0,1 1 0,2 2
 0))``) strings when I call ``wkt``.

 This is a problem because postgis will refuse to accept wrongly-
 dimensioned WKT for updates and inserts, even if the third dimension is
 zero.  Thus, if I attempt to transform a geometry, I can't subsequently
 write it to the database without modification.  This may still be an
 upstream problem, and if so, I'll happily post it there, but it has a real
 downstream effect right now.

 I'll attach an updated patch that uses the "coord_dim" property instead of
 the "dimension" property.

-- 
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] #11002: Databrowse does not have map widgets for GIS fields.

[Django]

#11002: Databrowse does not have map widgets for GIS fields.
-+--
  Reporter:  ingenieroariel  | Owner:  jbronn
Status:  assigned| Milestone:  1.3   
 Component:  GIS |   Version:  SVN   
Resolution:  |  Keywords:  databrowse
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

  * status:  new => assigned
  * milestone:  1.2 => 1.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] #9806: GeometryField crashes contrib.gis.admin

[Django]

#9806: GeometryField crashes contrib.gis.admin
-+--
  Reporter:  ingenieroariel  | Owner:  jbronn   
Status:  assigned| Milestone:  1.3  
 Component:  GIS |   Version:  1.0  
Resolution:  |  Keywords:  admin, gis, GeometryField
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Changes (by jbronn):

  * milestone:  1.2 => 1.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] #5472: Implement Individual Map Widgets for Geometry Fields

[Django]

#5472: Implement Individual Map Widgets for Geometry Fields
---+
  Reporter:  p | Owner:  p  

Status:  assigned  | Milestone:  1.3

 Component:  GIS   |   Version:  SVN

Resolution:|  Keywords:  openlayers javascript map maps 
mapping widget forms
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  1  

Needs_better_patch:  0 |  
---+
Changes (by jbronn):

  * milestone:  => 1.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.

[Changeset] r12588 - django/trunk/docs/intro

[noreply]

Author: jbronn
Date: 2010-02-24 16:11:49 -0600 (Wed, 24 Feb 2010)
New Revision: 12588

Modified:
   django/trunk/docs/intro/tutorial03.txt
Log:
Fixed #12958 -- Fixed typo I introduced in r12527.  Thanks, mitchf.


Modified: django/trunk/docs/intro/tutorial03.txt
===
--- django/trunk/docs/intro/tutorial03.txt  2010-02-24 21:59:27 UTC (rev 
12587)
+++ django/trunk/docs/intro/tutorial03.txt  2010-02-24 22:11:49 UTC (rev 
12588)
@@ -261,7 +261,7 @@
 {% if latest_poll_list %}
 
 {% for poll in latest_poll_list %}
-{{ poll.question }}<
+{{ poll.question }}
 {% endfor %}
 
 {% else %}

-- 
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] #12828: Invalid SQL in GIS DB

[Django]

#12828: Invalid SQL in GIS DB
-+--
  Reporter:  joliveiri...@gmail.com  | Owner:  nobody 
Status:  closed  | Milestone:  1.2
 Component:  GIS |   Version:  1.1
Resolution:  fixed   |  Keywords:  invalid SQL
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  1  
Needs_better_patch:  0   |  
-+--
Comment (by jbronn):

 FYI, this bug does not affect trunk, as it was revamped appropriately when
 multidb merged into trunk.  I kept ticket as a reminder to fix in 1.1.X,
 it's really a duplicate of #11741.

-- 
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] r12587 - in django/branches/releases/1.1.X/django/contrib/gis/db: backend/mysql backend/oracle backend/postgis backend/spatialite models/sql

[noreply]

Author: jbronn
Date: 2010-02-24 15:59:27 -0600 (Wed, 24 Feb 2010)
New Revision: 12587

Modified:
   django/branches/releases/1.1.X/django/contrib/gis/db/backend/mysql/query.py
   django/branches/releases/1.1.X/django/contrib/gis/db/backend/oracle/query.py
   django/branches/releases/1.1.X/django/contrib/gis/db/backend/postgis/query.py
   
django/branches/releases/1.1.X/django/contrib/gis/db/backend/spatialite/query.py
   django/branches/releases/1.1.X/django/contrib/gis/db/models/sql/where.py
Log:
[1.1.X] Fixed #12828 -- The table quoting function is now argument 
`get_geo_where_clause`.


Modified: 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/mysql/query.py
===
--- django/branches/releases/1.1.X/django/contrib/gis/db/backend/mysql/query.py 
2010-02-24 21:58:01 UTC (rev 12586)
+++ django/branches/releases/1.1.X/django/contrib/gis/db/backend/mysql/query.py 
2010-02-24 21:59:27 UTC (rev 12587)
@@ -7,9 +7,6 @@
  indices may only be used on MyISAM tables -- if you need 
  transactions, take a look at PostGIS.
 """
-from django.db import connection
-qn = connection.ops.quote_name
-
 # To ease implementation, WKT is passed to/from MySQL.
 GEOM_FROM_TEXT = 'GeomFromText'
 GEOM_FROM_WKB = 'GeomFromWKB'
@@ -40,7 +37,7 @@
 MYSQL_GIS_TERMS += MISC_TERMS
 MYSQL_GIS_TERMS = dict((term, None) for term in MYSQL_GIS_TERMS) # Making 
dictionary 
 
-def get_geo_where_clause(table_alias, name, lookup_type, geo_annot):
+def get_geo_where_clause(table_alias, name, lookup_type, geo_annot, qn):
 "Returns the SQL WHERE clause for use in MySQL spatial SQL construction."
 # Getting the quoted field as `geo_col`.
 geo_col = '%s.%s' % (qn(table_alias), qn(name))

Modified: 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/oracle/query.py
===
--- 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/oracle/query.py
2010-02-24 21:58:01 UTC (rev 12586)
+++ 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/oracle/query.py
2010-02-24 21:59:27 UTC (rev 12587)
@@ -9,10 +9,8 @@
 """
 import re
 from decimal import Decimal
-from django.db import connection
 from django.contrib.gis.db.backend.util import SpatialFunction
 from django.contrib.gis.measure import Distance
-qn = connection.ops.quote_name
 
 # The GML, distance, transform, and union procedures.
 AREA = 'SDO_GEOM.SDO_AREA'
@@ -110,7 +108,7 @@
 ORACLE_SPATIAL_TERMS = dict((term, None) for term in ORACLE_SPATIAL_TERMS) # 
Making dictionary for fast lookups
 
  The `get_geo_where_clause` function for Oracle 
-def get_geo_where_clause(table_alias, name, lookup_type, geo_annot):
+def get_geo_where_clause(table_alias, name, lookup_type, geo_annot, qn):
 "Returns the SQL WHERE clause for use in Oracle spatial SQL construction."
 # Getting the quoted table name as `geo_col`.
 geo_col = '%s.%s' % (qn(table_alias), qn(name))

Modified: 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/postgis/query.py
===
--- 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/postgis/query.py   
2010-02-24 21:58:01 UTC (rev 12586)
+++ 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/postgis/query.py   
2010-02-24 21:59:27 UTC (rev 12587)
@@ -5,13 +5,10 @@
 
 import re
 from decimal import Decimal
-from django.db import connection
 from django.conf import settings
 from django.contrib.gis.measure import Distance
 from django.contrib.gis.db.backend.util import SpatialOperation, 
SpatialFunction
 
-qn = connection.ops.quote_name
-
 # Get the PostGIS version information.
 # To avoid the need to do a database query to determine the PostGIS version
 # each time the server starts up, one can optionally specify a
@@ -250,7 +247,7 @@
 else: return exactly_two(val)
 
  The `get_geo_where_clause` function for PostGIS. 
-def get_geo_where_clause(table_alias, name, lookup_type, geo_annot):
+def get_geo_where_clause(table_alias, name, lookup_type, geo_annot, qn):
 "Returns the SQL WHERE clause for use in PostGIS SQL construction."
 # Getting the quoted field as `geo_col`.
 geo_col = '%s.%s' % (qn(table_alias), qn(name))

Modified: 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/spatialite/query.py
===
--- 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/spatialite/query.py
2010-02-24 21:58:01 UTC (rev 12586)
+++ 
django/branches/releases/1.1.X/django/contrib/gis/db/backend/spatialite/query.py
2010-02-24 21:59:27 UTC (rev 12587)
@@ -4,10 +4,8 @@
 """
 import re
 from decimal import Decimal
-from django.db import connection
 from django.contrib.gis.measure import Distance
 from django.contrib.gis.db.backend.util import SpatialOperation, 
SpatialFunction
-qn = connection.ops.quot

[Changeset] r12586 - django/trunk/django/views

[noreply]

Author: jkocherhans
Date: 2010-02-24 15:58:01 -0600 (Wed, 24 Feb 2010)
New Revision: 12586

Modified:
   django/trunk/django/views/debug.py
Log:
Fixed #10216. Only try to gather template exception info if the exception is a 
Django TemplateSyntaxError. Thanks, Alex Gaynor.

Modified: django/trunk/django/views/debug.py
===
--- django/trunk/django/views/debug.py  2010-02-24 21:26:11 UTC (rev 12585)
+++ django/trunk/django/views/debug.py  2010-02-24 21:58:01 UTC (rev 12586)
@@ -1,15 +1,17 @@
+import datetime
 import os
 import re
 import sys
-import datetime
 
 from django.conf import settings
-from django.template import Template, Context, TemplateDoesNotExist
+from django.http import HttpResponse, HttpResponseServerError, 
HttpResponseNotFound
+from django.template import (Template, Context, TemplateDoesNotExist,
+TemplateSyntaxError)
 from django.utils.html import escape
 from django.utils.importlib import import_module
-from django.http import HttpResponse, HttpResponseServerError, 
HttpResponseNotFound
 from django.utils.encoding import smart_unicode, smart_str
 
+
 HIDDEN_SETTINGS = re.compile('SECRET|PASSWORD|PROFANITIES_LIST')
 
 def linebreak_iter(template_source):
@@ -100,7 +102,8 @@
 'loader': loader_name,
 'templates': template_list,
 })
-if settings.TEMPLATE_DEBUG and hasattr(self.exc_value, 'source'):
+if (settings.TEMPLATE_DEBUG and hasattr(self.exc_value, 'source') and
+isinstance(self.exc_value, TemplateSyntaxError)):
 self.get_template_exception_info()
 
 frames = self.get_traceback_frames()

-- 
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] #12958: Typo in code sample

[Django]

#12958: Typo in code sample
+---
  Reporter:  mitchf | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:  typo  
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * keywords:  => typo
  * needs_docs:  => 0
  * has_patch:  0 => 1
  * stage:  Unreviewed => Ready for checkin

-- 
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] #12312: MultiLineString OGRGeometry dimensions change on transform

[Django]

#12312: MultiLineString OGRGeometry dimensions change on transform
---+
  Reporter:  yourcelf  | Owner:  jbronn 
Status:  closed| Milestone: 
 Component:  GIS   |   Version:  SVN
Resolution:  invalid   |  Keywords:  gdal OGRGeometry 3D
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

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

Comment:

 The `coord_dim` property is what you're looking for, as it's what
 specifies the coordinate dimension.  `dimension` on the other hand calls
 [http://www.gdal.org/ogr/ogr__api_8h.html#94b633e1acd208c258ad49f8d4fd4104
 OGR_G_GetDimension], which returns 0 for points, 1 for lines, and 2 for
 surfaces.  I guess it considers MultiLineStrings 'surfaces', but you
 should take that up w/the GDAL developers, as it's returning the right
 result from GDAL.

-- 
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] #12439: geos and gdal libraries need to be prefixed by 'cyg' under cygwin

[Django]

#12439: geos and gdal libraries need to be prefixed by 'cyg' under cygwin
-+--
  Reporter:  kiorky   | Owner:  nobody
Status:  closed  | Milestone:
 Component:  GIS |   Version:  1.1   
Resolution:  wontfix |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

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

Comment:

 Replying to [comment:5 kiorky]:
 > We don't ask you to support cygwin but to commit a trivial patch to make
 it easy for cygwin users to run geodjango by default.

 As documented in the
 [http://docs.djangoproject.com/en/dev/internals/contributing/#id1
 contributing docs], do not reopen tickets marked wontfix by a core
 committer.

 You are the only cygwin user.  Putting in conditionals for cygwin implies
 it's supported.  This is easily worked around using the built-in settings
 I described.

-- 
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] r12585 - django/branches/releases/1.1.X/django/contrib/gis/db/models

[noreply]

Author: jbronn
Date: 2010-02-24 15:26:11 -0600 (Wed, 24 Feb 2010)
New Revision: 12585

Modified:
   django/branches/releases/1.1.X/django/contrib/gis/db/models/proxy.py
Log:
[1.1.X] Fixed #11353 -- `GeometryProxy` descriptor no longer chokes when 
accessed from a class rather than an instance, thanks yml and Tobu; removed 
unnecessary imports from `types` and cleaned up whitespace.

Backport of r12584 from trunk.


Modified: django/branches/releases/1.1.X/django/contrib/gis/db/models/proxy.py
===
--- django/branches/releases/1.1.X/django/contrib/gis/db/models/proxy.py
2010-02-24 21:20:02 UTC (rev 12584)
+++ django/branches/releases/1.1.X/django/contrib/gis/db/models/proxy.py
2010-02-24 21:26:11 UTC (rev 12585)
@@ -1,42 +1,44 @@
 """
- The GeometryProxy object, allows for lazy-geometries.  The proxy uses
- Python descriptors for instantiating and setting Geometry objects
- corresponding to geographic model fields.
+The GeometryProxy object, allows for lazy-geometries.  The proxy uses
+Python descriptors for instantiating and setting Geometry objects
+corresponding to geographic model fields.
 
- Thanks to Robert Coup for providing this functionality (see #4322).
+Thanks to Robert Coup for providing this functionality (see #4322).
 """
 
-from types import NoneType, StringType, UnicodeType
-
-class GeometryProxy(object): 
-def __init__(self, klass, field): 
+class GeometryProxy(object):
+def __init__(self, klass, field):
 """
-Proxy initializes on the given Geometry class (not an instance) and 
+Proxy initializes on the given Geometry class (not an instance) and
 the GeometryField.
 """
-self._field = field 
+self._field = field
 self._klass = klass
- 
-def __get__(self, obj, type=None): 
+
+def __get__(self, obj, type=None):
 """
 This accessor retrieves the geometry, initializing it using the 
geometry
-class specified during initialization and the HEXEWKB value of the 
field.  
+class specified during initialization and the HEXEWKB value of the 
field.
 Currently, only GEOS or OGR geometries are supported.
 """
+if obj is None:
+# Accessed on a class, not an instance
+return self
+
 # Getting the value of the field.
-geom_value = obj.__dict__[self._field.attname] 
-
-if isinstance(geom_value, self._klass): 
+geom_value = obj.__dict__[self._field.attname]
+
+if isinstance(geom_value, self._klass):
 geom = geom_value
 elif (geom_value is None) or (geom_value==''):
 geom = None
-else: 
+else:
 # Otherwise, a Geometry object is built using the field's contents,
 # and the model's corresponding attribute is set.
 geom = self._klass(geom_value)
-setattr(obj, self._field.attname, geom) 
-return geom 
- 
+setattr(obj, self._field.attname, geom)
+return geom
+
 def __set__(self, obj, value):
 """
 This accessor sets the proxied geometry with the geometry class
@@ -45,18 +47,18 @@
 """
 # The OGC Geometry type of the field.
 gtype = self._field.geom_type
-
+
 # The geometry type must match that of the field -- unless the
 # general GeometryField is used.
 if isinstance(value, self._klass) and (str(value.geom_type).upper() == 
gtype or gtype == 'GEOMETRY'):
 # Assigning the SRID to the geometry.
 if value.srid is None: value.srid = self._field.srid
-elif isinstance(value, (NoneType, StringType, UnicodeType)):
-# Set with None, WKT, or HEX
+elif value is None or isinstance(value, (basestring, buffer)):
+# Set with None, WKT, HEX, or WKB
 pass
 else:
 raise TypeError('cannot set %s GeometryProxy with value of type: 
%s' % (obj.__class__.__name__, type(value)))
 
 # Setting the objects dictionary with the value, and returning.
-obj.__dict__[self._field.attname] = value 
-return value 
+obj.__dict__[self._field.attname] = value
+return 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.

[Changeset] r12584 - django/trunk/django/contrib/gis/db/models

[noreply]

Author: jbronn
Date: 2010-02-24 15:20:02 -0600 (Wed, 24 Feb 2010)
New Revision: 12584

Modified:
   django/trunk/django/contrib/gis/db/models/proxy.py
Log:
Fixed #11353 -- `GeometryProxy` descriptor no longer chokes when accessed from 
a class rather than an instance, thanks yml and Tobu; removed unnecessary 
imports from `types` and cleaned up whitespace.


Modified: django/trunk/django/contrib/gis/db/models/proxy.py
===
--- django/trunk/django/contrib/gis/db/models/proxy.py  2010-02-24 21:16:37 UTC 
(rev 12583)
+++ django/trunk/django/contrib/gis/db/models/proxy.py  2010-02-24 21:20:02 UTC 
(rev 12584)
@@ -1,42 +1,44 @@
 """
- The GeometryProxy object, allows for lazy-geometries.  The proxy uses
- Python descriptors for instantiating and setting Geometry objects
- corresponding to geographic model fields.
+The GeometryProxy object, allows for lazy-geometries.  The proxy uses
+Python descriptors for instantiating and setting Geometry objects
+corresponding to geographic model fields.
 
- Thanks to Robert Coup for providing this functionality (see #4322).
+Thanks to Robert Coup for providing this functionality (see #4322).
 """
 
-from types import NoneType, StringType, UnicodeType
-
-class GeometryProxy(object): 
-def __init__(self, klass, field): 
+class GeometryProxy(object):
+def __init__(self, klass, field):
 """
-Proxy initializes on the given Geometry class (not an instance) and 
+Proxy initializes on the given Geometry class (not an instance) and
 the GeometryField.
 """
-self._field = field 
+self._field = field
 self._klass = klass
- 
-def __get__(self, obj, type=None): 
+
+def __get__(self, obj, type=None):
 """
 This accessor retrieves the geometry, initializing it using the 
geometry
-class specified during initialization and the HEXEWKB value of the 
field.  
+class specified during initialization and the HEXEWKB value of the 
field.
 Currently, only GEOS or OGR geometries are supported.
 """
+if obj is None:
+# Accessed on a class, not an instance
+return self
+
 # Getting the value of the field.
-geom_value = obj.__dict__[self._field.attname] 
-
-if isinstance(geom_value, self._klass): 
+geom_value = obj.__dict__[self._field.attname]
+
+if isinstance(geom_value, self._klass):
 geom = geom_value
 elif (geom_value is None) or (geom_value==''):
 geom = None
-else: 
+else:
 # Otherwise, a Geometry object is built using the field's contents,
 # and the model's corresponding attribute is set.
 geom = self._klass(geom_value)
-setattr(obj, self._field.attname, geom) 
-return geom 
- 
+setattr(obj, self._field.attname, geom)
+return geom
+
 def __set__(self, obj, value):
 """
 This accessor sets the proxied geometry with the geometry class
@@ -45,18 +47,18 @@
 """
 # The OGC Geometry type of the field.
 gtype = self._field.geom_type
-
+
 # The geometry type must match that of the field -- unless the
 # general GeometryField is used.
 if isinstance(value, self._klass) and (str(value.geom_type).upper() == 
gtype or gtype == 'GEOMETRY'):
 # Assigning the SRID to the geometry.
 if value.srid is None: value.srid = self._field.srid
-elif isinstance(value, (NoneType, StringType, UnicodeType)):
-# Set with None, WKT, or HEX
+elif value is None or isinstance(value, (basestring, buffer)):
+# Set with None, WKT, HEX, or WKB
 pass
 else:
 raise TypeError('cannot set %s GeometryProxy with value of type: 
%s' % (obj.__class__.__name__, type(value)))
 
 # Setting the objects dictionary with the value, and returning.
-obj.__dict__[self._field.attname] = value 
-return value 
+obj.__dict__[self._field.attname] = value
+return 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.

[Changeset] r12583 - django/branches/releases/1.1.X

[noreply]

Author: jkocherhans
Date: 2010-02-24 15:16:37 -0600 (Wed, 24 Feb 2010)
New Revision: 12583

Modified:
   django/branches/releases/1.1.X/
Log:
[1.1.X.] Blocked a few more revisions via svnmerge.py.



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-blocked
   - 
/django/trunk:11526,11586-11587,11590,11593-11595,11600,11618,11627,11636,11639-11642,11645-11647,11654-11655,11660-11661,11663-11669,11672-11673,11675-11677,11680,11683,11709-11713,11716-11718,11721-11731,11736-11739,11742-11747,11752,11755,11778-11799,11803-11807,11810,11814,11830,11843,11846-11848,11850,11854-11855,11858,11861-11863,11880,11883-11884,11887,11900,11907,11910,11915-11916,11921,11923-11924,11937,11943,11952,11955-11956,11959-11960,11964-11976,11981-11983,12008-12010,12013,12021,12026-12037,12041-12043,12046-12047,12049-12053,12057-12058,12060,12080-12085,12089,12097-12103,12106-12117,12120,12122-12125,12127,12135,12139,12142,12146,12148,12153-12157,12159-12160,12164,12174,12176-12177,12180,12185,12191-12192,12194-12196,12198,12203-12219,1-12228,12232,12247-12248,12255-12262,12264-12275,12278-12281,12285,12287-12292,12295-12312,12315-12316,12335-12338,12345,12349-12352,12354,12357-12361,12364-12378,12381-12383,12386-12397,12399-12403,12496,12525,12532,12543-12544
   + 
/django/trunk:11526,11586-11587,11590,11593-11595,11600,11618,11627,11636,11639-11642,11645-11647,11654-11655,11660-11661,11663-11669,11672-11673,11675-11677,11680,11683,11709-11713,11716-11718,11721-11731,11736-11739,11742-11747,11752,11755,11778-11799,11803-11807,11810,11814,11830,11843,11846-11848,11850,11854-11855,11858,11861-11863,11880,11883-11884,11887,11900,11907,11910,11915-11916,11921,11923-11924,11937,11943,11952,11955-11956,11959-11960,11964-11976,11981-11983,12008-12010,12013,12021,12026-12037,12041-12043,12046-12047,12049-12053,12057-12058,12060,12080-12085,12089,12097-12103,12106-12117,12120,12122-12125,12127,12135,12139,12142,12146,12148,12153-12157,12159-12160,12164,12174,12176-12177,12180,12185,12191-12192,12194-12196,12198,12203-12219,1-12228,12232,12247-12248,12255-12262,12264-12275,12278-12281,12285,12287-12292,12295-12312,12315-12316,12335-12338,12345,12349-12352,12354,12357-12361,12364-12378,12381-12383,12386-12397,12399-12403,12496,12525,12532,12543-12544,12551,12578-12580

-- 
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] r12582 - in django/branches/releases/1.1.X: . django/utils tests/regressiontests/text

[noreply]

Author: jkocherhans
Date: 2010-02-24 14:56:09 -0600 (Wed, 24 Feb 2010)
New Revision: 12582

Modified:
   django/branches/releases/1.1.X/
   django/branches/releases/1.1.X/django/utils/text.py
   django/branches/releases/1.1.X/tests/regressiontests/text/tests.py
Log:
[1.1.X] Fixed #12119. Changed smart_split to stop splitting on whitespace in 
quotes. Backport of r12581 from trunk.



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12405,12492,12498,12523,12526,12533,12535,12537,12539,12541,12548,12556,12567,12573,12576
   + 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12405,12492,12498,12523,12526,12533,12535,12537,12539,12541,12548,12556,12567,12573,12576,12581

Modified: django/branches/releases/1.1.X/django/utils/text.py
===
--- django/branches/releases/1.1.X/django/utils/text.py 2010-02-24 20:52:14 UTC 
(rev 12581)
+++ django/branches/releases/1.1.X/django/utils/text.py 2010-02-24 20:56:09 UTC 
(rev 12582)
@@ -200,9 +200,14 @@
 # Expression to match some_token and some_token="with spaces" (and similarly
 # for single-quoted strings).
 smart_split_re = re.compile(r"""
-([^\s"]*"(?:[^"\\]*(?:\\.[^"\\]*)*)"\S*|
- [^\s']*'(?:[^'\\]*(?:\\.[^'\\]*)*)'\S*|
- \S+)""", re.VERBOSE)
+((?:
+[^\s'"]*
+(?:
+(?:"(?:[^"\\]|\\.)*" | '(?:[^'\\]|\\.)*')
+[^\s'"]*
+)+
+) | \S+)
+""", re.VERBOSE)
 
 def smart_split(text):
 r"""

Modified: django/branches/releases/1.1.X/tests/regressiontests/text/tests.py
===
--- django/branches/releases/1.1.X/tests/regressiontests/text/tests.py  
2010-02-24 20:52:14 UTC (rev 12581)
+++ django/branches/releases/1.1.X/tests/regressiontests/text/tests.py  
2010-02-24 20:56:09 UTC (rev 12582)
@@ -27,6 +27,8 @@
 [u'url', u'search_page', u'words=hello']
 >>> list(smart_split(u'url search_page words="something else'))
 [u'url', u'search_page', u'words="something', u'else']
+>>> list(smart_split("cut:','|cut:' '"))
+[u"cut:','|cut:' '"]
 
 ### urlquote #
 >>> from django.utils.http import urlquote, urlquote_plus

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

[noreply]

Author: jkocherhans
Date: 2010-02-24 14:52:14 -0600 (Wed, 24 Feb 2010)
New Revision: 12581

Modified:
   django/trunk/django/utils/text.py
   django/trunk/tests/regressiontests/text/tests.py
Log:
Fixed #12119. Changed smart_split to stop splitting on whitespace in quotes. 
Thanks, emulbreh.

Modified: django/trunk/django/utils/text.py
===
--- django/trunk/django/utils/text.py   2010-02-24 19:39:04 UTC (rev 12580)
+++ django/trunk/django/utils/text.py   2010-02-24 20:52:14 UTC (rev 12581)
@@ -202,9 +202,14 @@
 # Expression to match some_token and some_token="with spaces" (and similarly
 # for single-quoted strings).
 smart_split_re = re.compile(r"""
-([^\s"]*"(?:[^"\\]*(?:\\.[^"\\]*)*)"\S*|
- [^\s']*'(?:[^'\\]*(?:\\.[^'\\]*)*)'\S*|
- \S+)""", re.VERBOSE)
+((?:
+[^\s'"]*
+(?:
+(?:"(?:[^"\\]|\\.)*" | '(?:[^'\\]|\\.)*')
+[^\s'"]*
+)+
+) | \S+)
+""", re.VERBOSE)
 
 def smart_split(text):
 r"""

Modified: django/trunk/tests/regressiontests/text/tests.py
===
--- django/trunk/tests/regressiontests/text/tests.py2010-02-24 19:39:04 UTC 
(rev 12580)
+++ django/trunk/tests/regressiontests/text/tests.py2010-02-24 20:52:14 UTC 
(rev 12581)
@@ -27,6 +27,8 @@
 [u'url', u'search_page', u'words=hello']
 >>> list(smart_split(u'url search_page words="something else'))
 [u'url', u'search_page', u'words="something', u'else']
+>>> list(smart_split("cut:','|cut:' '"))
+[u"cut:','|cut:' '"]
 
 ### urlquote #
 >>> from django.utils.http import urlquote, urlquote_plus

-- 
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] #11940: ModelForm evaluates callable default values on form class creation

[Django]

#11940: ModelForm evaluates callable default values on form class creation
+---
  Reporter:  Harm Geerts   | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Forms  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jpaulett):

 * cc: j...@paulett.org (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] #6191: Admin delete view doesn't show all items in some circumstances

[Django]

#6191: Admin delete view doesn't show all items in some circumstances
---+
  Reporter:  nicklane  | Owner:  carljm
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by carljm):

 Thanks for the review, very helpful.

 Replying to [comment:23 russellm]:
 >  * I got a test failure running the
 admin_util.NestedObjectsTests.test_siblings test (got [0, [2, 1]],
 expected [0, [1, 2]]). The problem appears to be that NestedObjects uses a
 set to collect objects, which therefore doesn't give a guaranteed result
 order. One fix is to use a list instead if a set; the other fix is to
 modify the test so it isn't order dependent. I'm fairly certain just using
 a list is all that is required - I couldn't see anything obvious that was
 relying on the fact that sets were unique or easy to look up.

 Right, I'll just use a list. Somehow I thought the set was to prevent
 duplicates, but I check for already-seen first, so that's not an issue.

 >  * I'm not wild about the inner _format_callback function in
 get_deleted_objects(). admin_site, perms_needed, and levels_to_root are
 all variables from a scope outside the function itself, which is a bit of
 a code smell. I'd be much happier if _format_callback was a standalone
 function in its own right that took these extra values as kwargs that were
 passed in by nested (i.e., nested takes any extra kwargs and passes them
 down the the callback)

 One man's closure is another's code smell, I guess ;-) Just don't tell the
 Lispers & Javascripters. I think the closure style is simpler and more
 elegant here than adding **kwargs all over the place, but I'm not tied to
 it; I'll use your suggestion instead.

 >  * The one test case that I can see that is obviously missing is
 inheritance. On paper, this is probably caught by deleting OneToOneFields,
 but there is enough special handling for inheritance that it's worth
 having a specific test case for it (suggestion: SuperVillain subclassing
 Villain, create a SuperVillain; what happens if you delete the villain? if
 you delete the supervillain?)

 I was trying to strike a balance of thoroughly testing the admin
 functionality without redundantly testing Model._collect_sub_objects,
 which is tested elsewhere; since my code has no special handling for
 inheritance I thought this fell into the "redundant" category. But I guess
 that same argument could apply to the multiple-fkey tests; I'll add
 inheritance tests.

 >  * The template change makes me mildly nervous. Ideally, I'd prefer that
 this change wasn't necessary, as it will break any existing templates in
 the field that are constructed against the context that has historically
 existed - even if that just means introducing a dummy top-level list entry
 so the old template can iterate over a single element.

 Ok. I'll use a dummy top-level list wrapper to keep the template context
 backwards-compatible, but I'll at least fix the template misspelling of
 "deletable," since that's internal to the short loop ;)

 >  * The comments on the add() method for NestedObjects makes a point of
 highlighting that the model, pk and parent_model arguments aren't actually
 used. I accept that they are completely redundant as they can be derived
 from the obj and parent_obj arguments. However, I'm a little nervous

 Was there more here that got cut off regarding the nature of your
 nervousness? If I do merge CollectedObjects and NestedObjects, I would at
 least be tempted to remove redundancy from the .add() API, but this would
 require giving CollectedObjects knowledge about model internals
 (specifically model.pk), which currently it avoids. Do you have a clear
 preference between the simpler API (object, parent), which requires the
 collection class to know it's collecting model instances, vs. the current
 redundant API (obj_class, obj_pk, obj, parent_class, parent_pk), where the
 redundancy is needed because NestedObjects ultimately needs access to the
 full instance?

 >  * Is there any reason that NestedObjects can't be merged into
 CollectedObjects? It seems to me like there is a lot of duplication
 between the two classes, and we would be better served by extending
 CollectedObjects to provide the nested() functionality rather than have a
 second collection class.

 These last two issues are a result of me trying to touch django.db.* as
 little as possible. I certainly thought of merging CollectedObjects and
 NestedObjects; if you like the idea, I'll give it a shot. I'm a

Re: [Django] #12901: Forms _get_validations_exclusions is still not backwards compatible

[Django]

#12901: Forms _get_validations_exclusions is still not backwards compatible
--+-
  Reporter:  SmileyChris  | Owner:  nobody
Status:  closed   | Milestone:  1.2   
 Component:  Forms|   Version:  SVN   
Resolution:  fixed|  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by ammarr):

 Replying to [comment:12 Honza_Kral]:
 >
 > No. The key difference here is that if you omit the field in
 Meta.fields, it doesn't get populated on the model so validation doesn't
 make sense. If you, however, just override the field definition, the model
 still get populated with this field and validation should then be run.

 In addition to the previous message, the only way to exclude a field from
 model validation is to provide the entire fields tuple, exclude that one
 field, and then manually declare it. This behavior isn't symmetrical
 though (declare a field manually, and then just exclude it using the
 exclude tuple doesn't work). Perhaps this check should be added:

 {{{
 elif self._meta.exclude and field in self._meta.exclude:
 exclude.append(f.name)
 }}}

-- 
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] #12962: Broken Admin Delete Action With Confirmation

[Django]

#12962: Broken Admin Delete Action With Confirmation
---+
  Reporter:  leveille  | Owner:  nobody  
Status:  new   | Milestone:  1.2 
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  admin delete
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by jezdez):

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

-- 
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] #12901: Forms _get_validations_exclusions is still not backwards compatible

[Django]

#12901: Forms _get_validations_exclusions is still not backwards compatible
--+-
  Reporter:  SmileyChris  | Owner:  nobody
Status:  closed   | Milestone:  1.2   
 Component:  Forms|   Version:  SVN   
Resolution:  fixed|  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by ammarr):

 I see (and agree with) what you're saying, but the resultant behavior is
 not backwards compatible. The code snippet without the fields tuple
 validates in 1.1.1.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #12963: template context processors docs are wrong

[Django]

#12963: template context processors docs are wrong
+---
  Reporter:  anonymous  | Owner:  nobody
   
Status:  closed | Milestone:  1.2   
   
 Component:  Documentation  |   Version:  1.2-beta  
   
Resolution:  invalid|  Keywords:  admin context processor 
documentation
 Stage:  Unreviewed | Has_patch:  0 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 You're correct.

-- 
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] #12963: template context processors docs are wrong

[Django]

#12963: template context processors docs are wrong
+---
  Reporter:  anonymous  | Owner:  nobody
   
Status:  new| Milestone:  1.2   
   
 Component:  Documentation  |   Version:  1.2-beta  
   
Resolution: |  Keywords:  admin context processor 
documentation
 Stage:  Unreviewed | Has_patch:  0 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Comment (by chr):

 actually, the docs are right. a few changesets ago, the auth
 context_processors are moved to contrib.auth. (as is mentioned in the link
 you provided). leaving this open, in case i missed something...

-- 
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] r12580 - django/trunk/django/views

[noreply]

Author: jkocherhans
Date: 2010-02-24 13:39:04 -0600 (Wed, 24 Feb 2010)
New Revision: 12580

Modified:
   django/trunk/django/views/debug.py
Log:
Fixed #12944. Added Django version to the main part of the debug page. Thanks, 
robhudson.

Modified: django/trunk/django/views/debug.py
===
--- django/trunk/django/views/debug.py  2010-02-24 19:06:59 UTC (rev 12579)
+++ django/trunk/django/views/debug.py  2010-02-24 19:39:04 UTC (rev 12580)
@@ -420,6 +420,10 @@
   {{ request.build_absolute_uri|escape }}
 
 
+  Django Version:
+  {{ django_version_info }}
+
+
   Exception Type:
   {{ exception_type }}
 

-- 
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] #12901: Forms _get_validations_exclusions is still not backwards compatible

[Django]

#12901: Forms _get_validations_exclusions is still not backwards compatible
--+-
  Reporter:  SmileyChris  | Owner:  nobody
Status:  closed   | Milestone:  1.2   
 Component:  Forms|   Version:  SVN   
Resolution:  fixed|  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by Honza_Kral):

 Replying to [comment:11 ammarr]:
 > From the test case, it works with the following code:
 > {{{
 > class IncompleteCategoryForm(ModelForm):
 > url = forms.CharField(required=False)
 > class Meta:
 > fields = ('name', 'slug')
 > model = Category
 > }}}
 >
 > but not this:
 >
 > {{{
 > class IncompleteCategoryForm(ModelForm):
 > url = forms.CharField(required=False)
 > class Meta:
 > # removed field tuple
 > model = Category
 > }}}
 >
 > Is this intentional? IMO, if you declare a field manually, then it
 should be excluded from validation in any case (regardless of whether the
 field tuple is present or not).


 No. The key difference here is that if you omit the field in Meta.fields,
 it doesn't get populated on the model so validation doesn't make sense. If
 you, however, just override the field definition, the model still get
 populated with this field and validation should then be run.

-- 
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] #12901: Forms _get_validations_exclusions is still not backwards compatible

[Django]

#12901: Forms _get_validations_exclusions is still not backwards compatible
--+-
  Reporter:  SmileyChris  | Owner:  nobody
Status:  closed   | Milestone:  1.2   
 Component:  Forms|   Version:  SVN   
Resolution:  fixed|  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by ammarr):

 From the test case, it works with the following code:
 {{{
 class IncompleteCategoryForm(ModelForm):
 url = forms.CharField(required=False)
 class Meta:
 fields = ('name', 'slug')
 model = Category
 }}}

 but not this:

 {{{
 class IncompleteCategoryForm(ModelForm):
 url = forms.CharField(required=False)
 class Meta:
 # removed field tuple
 model = Category
 }}}

 Is this intentional? IMO, if you declare a field manually, then it should
 be excluded from validation in any case (regardless of whether the field
 tuple is present or not).

-- 
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] #12963: template context processors docs are wrong

[Django]

#12963: template context processors docs are wrong
+---
  Reporter:  anonymous  | Owner:  nobody
   
Status:  new| Milestone:  1.2   
   
 Component:  Documentation  |   Version:  1.2-beta  
   
Resolution: |  Keywords:  admin context processor 
documentation
 Stage:  Unreviewed | Has_patch:  0 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #12963: template context processors docs are wrong

[Django]

#12963: template context processors docs are wrong
---+
 Reporter:  anonymous  |   Owner:  nobody
   Status:  new|   Milestone:  1.2   
Component:  Documentation  | Version:  1.2-beta  
 Keywords:  admin context processor documentation  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 the docs at http://docs.djangoproject.com/en/dev/ref/settings/#template-
 context-processors have the wrong defaults... copy and pasting:

 ("django.contrib.auth.context_processors.auth",
 "django.core.context_processors.debug",
 "django.core.context_processors.i18n",
 "django.core.context_processors.media",
 "django.contrib.messages.context_processors.messages")

 that creates errors trying to use this to add our own... it makes the
 admin app die with:

 ImproperlyConfigured at /events/shows
 Put 'django.core.context_processors.auth' in your
 TEMPLATE_CONTEXT_PROCESSORS setting in order to use the admin application.

 obviously changing the first item in the tuple fixes the problem.  needs
 to be fixed.

 bonus question, is there a way to just add to the defaults so this problem
 doesn't persist with future changes?

-- 
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] #12962: Broken Admin Delete Action With Confirmation

[Django]

#12962: Broken Admin Delete Action With Confirmation
--+-
 Reporter:  leveille  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  SVN   
 Keywords:  admin delete  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 After updating to head this morning I noticed that I was unable to delete
 items in the administrator via the delete dropdown action (and
 confirmation).  I was able to track the issue back to [12525].
 Specifically, the introduced check looks for 'index', which will not be
 present when coming from the delete confirmation page:

 '''pprint of request.POST in response_action after clicking GO'''

 {{{
 #!python
 
 }}}

 '''pprint of request.POST in response_action after confirming I want to
 delete the record'''

 {{{
 #!python
 
 }}}

 To be sure my code wasn't introducing any issues, I testing with a fresh
 django project/app and the bug was still present.

-- 
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] r12579 - in django/trunk: django/db/models tests/modeltests/field_subclassing tests/regressiontests/defer_regress

[noreply]

Author: jkocherhans
Date: 2010-02-24 13:06:59 -0600 (Wed, 24 Feb 2010)
New Revision: 12579

Added:
   django/trunk/tests/modeltests/field_subclassing/fields.py
   django/trunk/tests/modeltests/field_subclassing/tests.py
Modified:
   django/trunk/django/db/models/query_utils.py
   django/trunk/tests/modeltests/field_subclassing/models.py
   django/trunk/tests/regressiontests/defer_regress/models.py
Log:
Fixed #12734. Deferred fields will now be properly converted to python when 
accessed. Thanks, Alex Gaynor.

Modified: django/trunk/django/db/models/query_utils.py
===
--- django/trunk/django/db/models/query_utils.py2010-02-24 17:36:18 UTC 
(rev 12578)
+++ django/trunk/django/db/models/query_utils.py2010-02-24 19:06:59 UTC 
(rev 12579)
@@ -183,11 +183,29 @@
 Retrieves and caches the value from the datastore on the first lookup.
 Returns the cached value.
 """
+from django.db.models.fields import FieldDoesNotExist
+
 assert instance is not None
 cls = self.model_ref()
 data = instance.__dict__
 if data.get(self.field_name, self) is self:
-data[self.field_name] = 
cls._base_manager.filter(pk=instance.pk).values_list(self.field_name, 
flat=True).using(instance._state.db).get()
+# self.field_name is the attname of the field, but only() takes the
+# actual name, so we need to translate it here.
+try:
+cls._meta.get_field_by_name(self.field_name)
+name = self.field_name
+except FieldDoesNotExist:
+name = [f.name for f in cls._meta.fields
+if f.attname == self.field_name][0]
+# We use only() instead of values() here because we want the
+# various data coersion methods (to_python(), etc.) to be called
+# here.
+val = getattr(
+cls._base_manager.filter(pk=instance.pk).only(name).using(
+instance._state.db).get(),
+self.field_name
+)
+data[self.field_name] = val
 return data[self.field_name]
 
 def __set__(self, instance, value):

Added: django/trunk/tests/modeltests/field_subclassing/fields.py
===
--- django/trunk/tests/modeltests/field_subclassing/fields.py   
(rev 0)
+++ django/trunk/tests/modeltests/field_subclassing/fields.py   2010-02-24 
19:06:59 UTC (rev 12579)
@@ -0,0 +1,71 @@
+from django.core.exceptions import FieldError
+from django.db import models
+from django.utils import simplejson as json
+from django.utils.encoding import force_unicode
+
+
+class Small(object):
+"""
+A simple class to show that non-trivial Python objects can be used as
+attributes.
+"""
+def __init__(self, first, second):
+self.first, self.second = first, second
+
+def __unicode__(self):
+return u'%s%s' % (force_unicode(self.first), 
force_unicode(self.second))
+
+def __str__(self):
+return unicode(self).encode('utf-8')
+
+class SmallField(models.Field):
+"""
+Turns the "Small" class into a Django field. Because of the similarities
+with normal character fields and the fact that Small.__unicode__ does
+something sensible, we don't need to implement a lot here.
+"""
+__metaclass__ = models.SubfieldBase
+
+def __init__(self, *args, **kwargs):
+kwargs['max_length'] = 2
+super(SmallField, self).__init__(*args, **kwargs)
+
+def get_internal_type(self):
+return 'CharField'
+
+def to_python(self, value):
+if isinstance(value, Small):
+return value
+return Small(value[0], value[1])
+
+def get_db_prep_save(self, value):
+return unicode(value)
+
+def get_db_prep_lookup(self, lookup_type, value):
+if lookup_type == 'exact':
+return force_unicode(value)
+if lookup_type == 'in':
+return [force_unicode(v) for v in value]
+if lookup_type == 'isnull':
+return []
+raise FieldError('Invalid lookup type: %r' % lookup_type)
+
+
+class JSONField(models.TextField):
+__metaclass__ = models.SubfieldBase
+
+description = ("JSONField automatically serializes and desializes values 
to "
+"and from JSON.")
+
+def to_python(self, value):
+if not value:
+return None
+
+if isinstance(value, basestring):
+value = json.loads(value)
+return value
+
+def get_db_prep_save(self, value):
+if value is None:
+return None
+return json.dumps(value)

Modified: django/trunk/tests/modeltests/field_subclassing/models.py
===
--- django/trunk/tests/modeltests/field_subclassing/models.py   2010-

Re: [Django] #12944: Add django version to debug page

[Django]

#12944: Add django version to debug page
+---
  Reporter:  robhudson  | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Generic views  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * stage:  Accepted => Ready for checkin

-- 
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] #12648: [PATCH]User send_email change from send_mail to EmailMessage

[Django]

#12648: [PATCH]User send_email change from send_mail to EmailMessage
-+--
  Reporter:  galuszkak   | Owner:  galuszkak
 
Status:  reopened| Milestone:   
 
 Component:  Authentication  |   Version:  SVN  
 
Resolution:  |  Keywords:  send_mail, email, 
send_email, EmailMessage
 Stage:  Unreviewed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

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

Comment:

 Let's start from the beginning. I'm using django-registration developed by
 ubernostrum, in my django project.
 Some time ago I had a problem with activation mail. It was simple,
 some(not every) email accounts wasn't receiving activation mail. It was
 very strange so I started searching what is the problem. I found that
 sending email was handled here:
 http://bitbucket.org/ubernostrum/django-
 registration/src/tip/registration/models.py
 And this line was the problem.
 {{{
 self.user.email_user(subject, message, settings.DEFAULT_FROM_EMAIL)
 }}}
 So I tried sending activation emails with EmailMessage. For me it was
 solution for problem, because magically emails where reaching destination
 email box(that previously don't reached that box).

 Email account from which I was sending activation links, is on the same
 server where I have my django project. My settings:

 {{{
 EMAIL_HOST = '127.0.0.1'
 EMAIL_HOST_USER = 'sponso...@sponsorek.pl'
 EMAIL_HOST_PASSWORD = '*'
 EMAIL_USE_TLS = False
 EMAIL_PORT = 25
 DEFAULT_FROM_EMAIL = 'sponso...@sponsorek.pl'
 }}}

 Site is on mod_python. Hosting provider is linuxpl.com .

 If you have any question you are welcome. I think that send_email is
 buggy, I can provide more specific details if you want.

 Some people on IRC said me that they have the same problem.

 With regards
 Galuszkak

-- 
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] #12941: multiple database connections cursors

[Django]

#12941: multiple database connections cursors
--+-
  Reporter:  atlith...@gmail.com  | Owner:  nobody  
Status:  new  | Milestone:  1.2 
 Component:  Documentation|   Version:  1.2-beta
Resolution:   |  Keywords:  
 Stage:  Ready for checkin| Has_patch:  1   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by Alex):

  * has_patch:  0 => 1
  * stage:  Accepted => Ready for checkin

-- 
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] #12119: django.utils.text.smart_split() does not handle multiple quoted strings joined by non-whitespace characters properly

[Django]

#12119: django.utils.text.smart_split() does not handle multiple quoted strings
joined by non-whitespace characters properly
+---
  Reporter:  emulbreh   | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Template system|   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * stage:  Accepted => Ready for checkin

-- 
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] r12578 - in django/trunk: django/db/models/fields docs/ref docs/ref/models docs/releases tests/regressiontests/model_fields

[noreply]

Author: jkocherhans
Date: 2010-02-24 11:36:18 -0600 (Wed, 24 Feb 2010)
New Revision: 12578

Modified:
   django/trunk/django/db/models/fields/__init__.py
   django/trunk/docs/ref/databases.txt
   django/trunk/docs/ref/models/fields.txt
   django/trunk/docs/releases/1.2.txt
   django/trunk/tests/regressiontests/model_fields/tests.py
Log:
Fixed #7190. Boolean fields now return bool values instead of 1 or 0. Thanks, 
Alex Gaynor.

Modified: django/trunk/django/db/models/fields/__init__.py
===
--- django/trunk/django/db/models/fields/__init__.py2010-02-24 16:06:10 UTC 
(rev 12577)
+++ django/trunk/django/db/models/fields/__init__.py2010-02-24 17:36:18 UTC 
(rev 12578)
@@ -524,9 +524,14 @@
 return "BooleanField"
 
 def to_python(self, value):
-if value in (True, False): return value
-if value in ('t', 'True', '1'): return True
-if value in ('f', 'False', '0'): return False
+if value in (True, False):
+# if value is 1 or 0 than it's equal to True or False, but we want
+# to return a true bool for semantic reasons.
+return bool(value)
+if value in ('t', 'True', '1'):
+return True
+if value in ('f', 'False', '0'):
+return False
 raise exceptions.ValidationError(self.error_messages['invalid'])
 
 def get_prep_lookup(self, lookup_type, value):
@@ -934,10 +939,16 @@
 return "NullBooleanField"
 
 def to_python(self, value):
-if value in (None, True, False): return value
-if value in ('None',): return None
-if value in ('t', 'True', '1'): return True
-if value in ('f', 'False', '0'): return False
+if value is None:
+return None
+if value in (True, False):
+return bool(value)
+if value in ('None',):
+return None
+if value in ('t', 'True', '1'):
+return True
+if value in ('f', 'False', '0'):
+return False
 raise exceptions.ValidationError(self.error_messages['invalid'])
 
 def get_prep_lookup(self, lookup_type, value):

Modified: django/trunk/docs/ref/databases.txt
===
--- django/trunk/docs/ref/databases.txt 2010-02-24 16:06:10 UTC (rev 12577)
+++ django/trunk/docs/ref/databases.txt 2010-02-24 17:36:18 UTC (rev 12578)
@@ -326,13 +326,12 @@
 Boolean fields
 ~~
 
-Since MySQL doesn't have a direct ``BOOLEAN`` column type, Django uses a
-``TINYINT`` column with values of ``1`` and ``0`` to store values for the
-:class:`~django.db.models.BooleanField` model field. Refer to the documentation
-of that field for more details, but usually this won't be something that will
-matter unless you're printing out the field values and are expecting to see
-``True`` and ``False.``.
+.. versionchanged:: 1.2
 
+In previous versions of Django when running under MySQL ``BooleanFields`` would
+return their data as ``ints``, instead of true ``bools``.  See the release
+notes for a complete description of the change.
+
 Character fields
 
 

Modified: django/trunk/docs/ref/models/fields.txt
===
--- django/trunk/docs/ref/models/fields.txt 2010-02-24 16:06:10 UTC (rev 
12577)
+++ django/trunk/docs/ref/models/fields.txt 2010-02-24 17:36:18 UTC (rev 
12578)
@@ -342,18 +342,11 @@
 
 The admin represents this as a checkbox.
 
-.. admonition:: MySQL users..
+.. versionchanged:: 1.2
 
-A boolean field in MySQL is stored as a ``TINYINT`` column with a value of
-either 0 or 1 (most databases have a proper ``BOOLEAN`` type instead). So,
-for MySQL, only, when a ``BooleanField`` is retrieved from the database
-and stored on a model attribute, it will have the values 1 or 0, rather
-than ``True`` or ``False``. Normally, this shouldn't be a problem, since
-Python guarantees that ``1 == True`` and ``0 == False`` are both true.
-Just be careful if you're writing something like ``obj is True`` when
-``obj`` is a value from a boolean attribute on a model. If that model was
-constructed using the ``mysql`` backend, the "``is``" test will fail.
-Prefer an equality test (using "``==``") in cases like this.
+In previous versions of Django when running under MySQL ``BooleanFields``
+would return their data as ``ints``, instead of true ``bools``.  See the
+release notes for a complete description of the change.
 
 ``CharField``
 -

Modified: django/trunk/docs/releases/1.2.txt
===
--- django/trunk/docs/releases/1.2.txt  2010-02-24 16:06:10 UTC (rev 12577)
+++ django/trunk/docs/releases/1.2.txt  2010-02-24 17:36:18 UTC (rev 12578)
@@ -302,6 +302,16 @@
 
 .. _deprecated-features-1.2:
 
+``BooleanField`` on MySQL
+--

[Django] #12961: Wrong Handler settings for Shared Apache Settings

[Django]

#12961: Wrong Handler settings for Shared Apache Settings
-+--
 Reporter:  cdavidowskiatcd  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  1.1   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 I was setting up a dev environment following the the directions for
 running django on a shared hosting provider with apache found at:
 http://docs.djangoproject.com/en/1.1/howto/deployment/fastcgi/#running-
 django-on-a-shared-hosting-provider-with-apache

 I was running into problems with the script not being executed, but being
 printed out to the browser when I tried to access the page.  I narrowed it
 down to a wrong AddHandler line.

 it says to use the following line for AddHandler

 {{{AddHandler fastcgi-script .fcgi}}}

 I had to use the following line to get it to work.

 {{{AddHandler cgi-script .fcgi}}}

 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] #12881: Unique constraint error with model inheritance while ModelForm should not validate

[Django]

#12881: Unique constraint error with model inheritance while ModelForm should 
not
validate
---+
  Reporter:  fgaudin   | Owner:  nobody 
  
Status:  new   | Milestone:  1.2
  
 Component:  Database layer (models, ORM)  |   Version:  1.1
  
Resolution:|  Keywords:  unique 
constraint, ModelForm, inheritance
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  1  
  
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #12235: MultiValueDictKeyError when editing Inline objects

[Django]

#12235: MultiValueDictKeyError when editing Inline objects
---+
  Reporter:  br...@playfirst.com   | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by matiasb):

 I think the problem could be in the definition of the UUIDField in the
 attached file. There, the id (an AutoField) is being replaced with an
 UUIDField, thus this field should work as an auto field. Then, adding the
 following to the UUIDField class definition solves the issue:

 {{{
 def contribute_to_class(self, cls, name):
 assert not cls._meta.has_auto_field, "A model can't have more than
 one AutoField."
 super(UUIDField, self).contribute_to_class(cls, name)
 cls._meta.has_auto_field = True
 cls._meta.auto_field = self
 }}}

 What was the problem? When generating the template for inline forms, as
 the Author instances didn't have an auto_field, there wasn't any hidden
 field to relate the shown Author instance with the previously saved Author
 when editing a Book (in stacked.html and tabular.html templates):
 {{{
 {% if inline_admin_form.has_auto_field %}{{
 inline_admin_form.pk_field.field }}{% endif %}
 }}}

 However, the saving view expects the 'author_set-0-id' field with the uuid
 (primary key) of the author to be updated. I'm assuming the if tag in the
 template is needed to be there, as defined.

-- 
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] #12960: return value (cleaned_data) from clean() method is ignored

[Django]

#12960: return value (cleaned_data) from clean() method is ignored
-+--
 Reporter:  krejcik  |   Owner:  nobody
   Status:  new  |   Milestone:  1.2   
Component:  Forms| Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Any changes made by model's clean method are ignored.

 Sequence of calls in BaseForm.full_clean() is following:
 1. - _clean_fields - which calls clean on fields and creates instance with
 cleaned values
 2. - _clean_form - which class clean on model, assign return to
 form.cleaned_data but instance is not updated
 3. - finally save_instance(construct=False) is called (in previous version
 of Django model instance was created here from correct cleaned_data)

-- 
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] #12956: More specificity would be more good

[Django]

#12956: More specificity would be more good
+---
  Reporter:  mitchf | Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.2-beta
Resolution: |  Keywords:  
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by mitchf):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Documentation
  * needs_tests:  => 0
  * needs_docs:  => 0

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #12957: Add scope=col to admin change_list_results.html (Accessibility)

[Django]

#12957: Add scope=col to admin change_list_results.html (Accessibility)
---+
  Reporter:  acdha | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  django.contrib.admin  |   Version:  1.1  
Resolution:|  Keywords:  accessibility
 Stage:  Unreviewed| Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by acdha):

  * needs_better_patch:  => 0
  * summary:  Add scope=row to admin change_list_results.html
  (Accessibility) => Add scope=col to admin
  change_list_results.html (Accessibility)
  * needs_tests:  => 0
  * needs_docs:  => 0

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #12959: SelectFilter2: alt text for filter button

[Django]

#12959: SelectFilter2: alt text for filter button
--+-
 Reporter:  acdha |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.1   
 Keywords:  accessibility |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Our 508 testing group noticed that SelectFilter2 generates the filter
 widget without alt text for the image. This patch adds alt text and wraps
 in a , similar to the main change list search.

 Patch attached; commit here for Github users:

 http://github.com/acdha/django/commit/a5610a1aa306afe7819055bbabdca24b43dd941e

-- 
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] #12958: Typo in code sample

[Django]

#12958: Typo in code sample
---+
 Reporter:  mitchf |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 URL: http://docs.djangoproject.com/en/dev/intro/tutorial03/#intro-
 tutorial03 (Section: Write views that actually do something)

 Sample code for [template_dir}/polls/index.html shows:
 {% if latest_poll_list %}
 
 {% for poll in latest_poll_list %}
 {{ poll.question }}<
 {% endfor %}
 
 {% else %}
 No polls are available.
 {% endif %}

 Should be:
 {% if latest_poll_list %}
 
 {% for poll in latest_poll_list %}
 {{ poll.question }}
 {% endfor %}
 
 {% else %}
 No polls are available.
 {% endif %}

 "" vs. "<"

-- 
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] #11907: EmailField should run strip()

[Django]

#11907: EmailField should run strip()
+---
  Reporter:  whatcould  | Owner:  djansoft
Status:  closed | Milestone:  
 Component:  Forms  |   Version:  1.1 
Resolution:  duplicate  |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by whatcould):

 ubernostrum, if you see my comment above (02/04/10 00:25:26) I explained
 why this should be marked as a separate bug, instead of being thrown into
 the 2-year-old black hole that is that other bug. Someone else apparently
 agreed at the time.

 This is all no skin off my back (I was consulting on a django project
 that's finished) -- I was just trying to follow through on this bug. Wish
 it hadn't felt like pushing on a string.

 -whatcould (fellow joyeur)

-- 
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] #12957: Add scope=row to admin change_list_results.html (Accessibility)

[Django]

#12957: Add scope=row to admin change_list_results.html (Accessibility)
--+-
 Reporter:  acdha |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.1   
 Keywords:  accessibility |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Our 508 testing group requested that we add scope=col to the change list
 tables.

 Patch attached; commit here for people who prefer git:
 http://github.com/acdha/django/commit/2780bc113756ed7a667a08082ba803ec6b454112

-- 
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] #12956: More specificity would be more good

[Django]

#12956: More specificity would be more good
---+
 Reporter:  mitchf |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2-beta  
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 URL: http://docs.djangoproject.com/en/dev/intro/tutorial03/#intro-
 tutorial03
 (Section: Write views that actually do something)

 I'm running through your 4-part Django tutorial. This being my first
 tutorial and project in Django, I am looking for concrete best practices
 and not vague statements like "First, create a directory, somewhere on
 your filesystem, whose contents Django can access. (Django runs as
 whatever user your server runs.) Don't put them under your document root,
 though. You probably shouldn't make them public, just for security's
 sake."

 Everything in Django is just days old to me. It would so much more helpful
 for you say "First, create the directory 'templates' in your 'mysite'
 directory. Make sure Django can access the directory and don't make it
 public, for security's sake", unless of course it is best practice for
 these files to live in the application directories and not the project
 directory. As a new user I desperately need clear steps and best
 practices.

-- 
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] r12577 - in django/branches/releases/1.1.X: . django/db/models/fields tests/regressiontests/serializers_regress

[noreply]

Author: jkocherhans
Date: 2010-02-24 10:06:10 -0600 (Wed, 24 Feb 2010)
New Revision: 12577

Modified:
   django/branches/releases/1.1.X/
   django/branches/releases/1.1.X/django/db/models/fields/__init__.py
   
django/branches/releases/1.1.X/tests/regressiontests/serializers_regress/models.py
   
django/branches/releases/1.1.X/tests/regressiontests/serializers_regress/tests.py
Log:
[1.1.X] Fixed #12546. Objects with a __len__ that returns 0 can now be 
serialized. Thanks, casobn for the report and Alex Gaynor for the patch and 
tests. Backport of r12576 from trunk.



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12405,12492,12498,12523,12526,12533,12535,12537,12539,12541,12548,12556,12567,12573
   + 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12405,12492,12498,12523,12526,12533,12535,12537,12539,12541,12548,12556,12567,12573,12576

Modified: django/branches/releases/1.1.X/django/db/models/fields/__init__.py
===
--- django/branches/releases/1.1.X/django/db/models/fields/__init__.py  
2010-02-24 15:54:03 UTC (rev 12576)
+++ django/branches/releases/1.1.X/django/db/models/fields/__init__.py  
2010-02-24 16:06:10 UTC (rev 12577)
@@ -277,7 +277,7 @@
 return first_choice + list(self.flatchoices)
 
 def _get_val_from_obj(self, obj):
-if obj:
+if obj is not None:
 return getattr(obj, self.attname)
 else:
 return self.get_default()

Modified: 
django/branches/releases/1.1.X/tests/regressiontests/serializers_regress/models.py
===
--- 
django/branches/releases/1.1.X/tests/regressiontests/serializers_regress/models.py
  2010-02-24 15:54:03 UTC (rev 12576)
+++ 
django/branches/releases/1.1.X/tests/regressiontests/serializers_regress/models.py
  2010-02-24 16:06:10 UTC (rev 12577)
@@ -252,4 +252,9 @@
 class ExplicitInheritBaseModel(BaseModel):
 parent = models.OneToOneField(BaseModel)
 child_data = models.IntegerField()
-
\ No newline at end of file
+
+class LengthModel(models.Model):
+data = models.IntegerField()
+
+def __len__(self):
+return self.data

Modified: 
django/branches/releases/1.1.X/tests/regressiontests/serializers_regress/tests.py
===
--- 
django/branches/releases/1.1.X/tests/regressiontests/serializers_regress/tests.py
   2010-02-24 15:54:03 UTC (rev 12576)
+++ 
django/branches/releases/1.1.X/tests/regressiontests/serializers_regress/tests.py
   2010-02-24 16:06:10 UTC (rev 12577)
@@ -8,7 +8,8 @@
 """
 
 
-import unittest, datetime
+import datetime
+import unittest
 from cStringIO import StringIO
 
 from django.utils.functional import curry
@@ -321,6 +322,8 @@
 (inherited_obj, 900, InheritAbstractModel, 
{'child_data':37,'parent_data':42}),
 (inherited_obj, 910, ExplicitInheritBaseModel, 
{'child_data':37,'parent_data':42}),
 (inherited_obj, 920, InheritBaseModel, {'child_data':37,'parent_data':42}),
+(data_obj, 1004, LengthModel, 0),
+(data_obj, 1005, LengthModel, 1),
 ]
 
 # Because Oracle treats

[Changeset] r12576 - in django/trunk: django/db/models/fields tests/regressiontests/serializers_regress

[noreply]

Author: jkocherhans
Date: 2010-02-24 09:54:03 -0600 (Wed, 24 Feb 2010)
New Revision: 12576

Modified:
   django/trunk/django/db/models/fields/__init__.py
   django/trunk/tests/regressiontests/serializers_regress/models.py
   django/trunk/tests/regressiontests/serializers_regress/tests.py
Log:
Fixed #12546. Objects with a __len__ that returns 0 can now be serialized. 
Thanks, casobn for the report and Alex Gaynor for the patch and tests.

Modified: django/trunk/django/db/models/fields/__init__.py
===
--- django/trunk/django/db/models/fields/__init__.py2010-02-24 15:40:33 UTC 
(rev 12575)
+++ django/trunk/django/db/models/fields/__init__.py2010-02-24 15:54:03 UTC 
(rev 12576)
@@ -404,7 +404,7 @@
 return first_choice + list(self.flatchoices)
 
 def _get_val_from_obj(self, obj):
-if obj:
+if obj is not None:
 return getattr(obj, self.attname)
 else:
 return self.get_default()

Modified: django/trunk/tests/regressiontests/serializers_regress/models.py
===
--- django/trunk/tests/regressiontests/serializers_regress/models.py
2010-02-24 15:40:33 UTC (rev 12575)
+++ django/trunk/tests/regressiontests/serializers_regress/models.py
2010-02-24 15:54:03 UTC (rev 12576)
@@ -258,3 +258,9 @@
 class ExplicitInheritBaseModel(BaseModel):
 parent = models.OneToOneField(BaseModel)
 child_data = models.IntegerField()
+
+class LengthModel(models.Model):
+data = models.IntegerField()
+
+def __len__(self):
+return self.data

Modified: django/trunk/tests/regressiontests/serializers_regress/tests.py
===
--- django/trunk/tests/regressiontests/serializers_regress/tests.py 
2010-02-24 15:40:33 UTC (rev 12575)
+++ django/trunk/tests/regressiontests/serializers_regress/tests.py 
2010-02-24 15:54:03 UTC (rev 12576)
@@ -8,7 +8,9 @@
 """
 
 
-import unittest, datetime
+import datetime
+import decimal
+import unittest
 from cStringIO import StringIO
 
 from django.utils.functional import curry
@@ -18,10 +20,6 @@
 from django.conf import settings
 
 from models import *
-try:
-import decimal
-except ImportError:
-from django.utils import _decimal as decimal
 
 # A set of functions that can be used to recreate
 # test data objects of various kinds.
@@ -326,6 +324,8 @@
 (data_obj, 1001, BigIntegerData, -9223372036854775808),
 (data_obj, 1002, BigIntegerData, 0),
 (data_obj, 1003, BigIntegerData, None),
+(data_obj, 1004, LengthModel, 0),
+(data_obj, 1005, LengthModel, 1),
 ]
 
 # Because Oracle treats the empty string as NULL, Oracle is expected to fail

-- 
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] #12546: Definining __len__ on a model object breaks it's serialization

[Django]

#12546: Definining __len__ on a model object breaks it's serialization
-+--
  Reporter:  casbon  | Owner:  nessita
Status:  assigned| Milestone:  1.2
 Component:  Core framework  |   Version:  1.1
Resolution:  |  Keywords: 
 Stage:  Accepted| Has_patch:  0  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by nessita):

  * owner:  nobody => nessita
  * 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.

[Changeset] r12575 - in django/branches/releases/1.1.X: . django/db/backends/sqlite3 tests/regressiontests/backends

[noreply]

Author: jkocherhans
Date: 2010-02-24 09:40:33 -0600 (Wed, 24 Feb 2010)
New Revision: 12575

Modified:
   django/branches/releases/1.1.X/
   django/branches/releases/1.1.X/django/db/backends/sqlite3/base.py
   django/branches/releases/1.1.X/tests/regressiontests/backends/models.py
   django/branches/releases/1.1.X/tests/regressiontests/backends/tests.py
Log:
[1.1.X] Fixed #12818. SQLite now properly quotes strings for date extraction 
and truncation. Backport of r12573 from trunk.



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12405,12492,12498,12523,12526,12533,12535,12537,12539,12541,12548,12556,12567
   + 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12405,12492,12498,12523,12526,12533,12535,12537,12539,12541,12548,12556,12567,12573

Modified: django/branches/releases/1.1.X/django/db/backends/sqlite3/base.py
===
--- django/branches/releases/1.1.X/django/db/backends/sqlite3/base.py   
2010-02-24 15:33:14 UTC (rev 12574)
+++ django/branches/releases/1.1.X/django/db/backends/sqlite3/base.py   
2010-02-24 15:40:33 UTC (rev 12575)
@@ -64,13 +64,17 @@
 class DatabaseOperations(BaseDatabaseOperations):
 def date_extract_sql(self, lookup_type, field_name):
 # sqlite doesn't support extract, so we fake it with the user-defined
-# function django_extract that's registered in connect().
-return 'django_extract("%s", %s)' % (lookup_type.lower(), field_name)
+# function django_extract that's registered in connect(). Note that
+# single quotes are used because this is a string (and could otherwise
+# cause a collision with a field name).
+return "django_extract('%s', %s)" % (lookup_type.lower(), field_name)
 
 def date_trunc_sql(self, lookup_type, field_name):
 # sqlite doesn't support DATE_TRUNC, so we fake it with a user-defined
-# function django_date_trunc that's registered in connect().
-return 'django_date_trunc("%s", %s)' % (lookup_type.lower(), 
field_name)
+# function django_date_trunc that's registered in connect(). Note that
+# single quotes are used because this is a string (and could otherwise
+# cause a collision with a field name).
+return "django_date_trunc('%s', %s)" % (lookup_type.lower(), 
field_name)
 
 def drop_foreignkey_sql(self):
 return ""

Modified: 
django/branches/releases/1.1.X/tests/regressiontests/backends/models.py
===
--- django/branches/releases/1.1.X/tests/regressiontests/backends/models.py 
2010-02-24 15:33:14 UTC (rev 12574)
+++ django/branches/releases/1.1.X/tests/regressiontests/backends/models.py 
2010-02-24 15:40:33 UTC (rev 12575)
@@ -15,6 +15,11 @@
 def __unicode__(self):
 return u'%s %s' % (self.first_name, self.last_name)
 
+class SchoolClass(models.Model):
+year = models.PositiveIntegerField()
+day = models.CharField(max_length=9, blank=True)
+last_updated = models.DateTimeField()
+
 qn = connection.ops.quote_name
 
 __test__ = {'API_TESTS': """

Modified: django/branches/rel

[Changeset] r12574 - django/trunk/django/conf/locale/pl/LC_MESSAGES

[noreply]

Author: zgoda
Date: 2010-02-24 09:33:14 -0600 (Wed, 24 Feb 2010)
New Revision: 12574

Modified:
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
Log:
Polish translations updated


Modified: django/trunk/django/conf/locale/pl/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2010-02-24 
15:29:25 UTC (rev 12573)
+++ django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2010-02-24 
15:33:14 UTC (rev 12574)
@@ -5,7 +5,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2010-01-11 10:18+0100\n"
+"POT-Creation-Date: 2010-02-24 16:25+0100\n"
 "PO-Revision-Date: 2008-02-25 15:53+0100\n"
 "Last-Translator: Jarek Zgoda \n"
 "MIME-Version: 1.0\n"
@@ -19,206 +19,222 @@
 msgstr "arabski"
 
 #: conf/global_settings.py:45
+msgid "Bulgarian"
+msgstr "bułgarski"
+
+#: conf/global_settings.py:46
 msgid "Bengali"
 msgstr "bengalski"
 
-#: conf/global_settings.py:46
-msgid "Bulgarian"
-msgstr "bułgarski"
+#: conf/global_settings.py:47
+msgid "Bosnian"
+msgstr "bośniacki"
 
-#: conf/global_settings.py:47
+#: conf/global_settings.py:48
 msgid "Catalan"
 msgstr "kataloński"
 
-#: conf/global_settings.py:48
+#: conf/global_settings.py:49
 msgid "Czech"
 msgstr "czeski"
 
-#: conf/global_settings.py:49
+#: conf/global_settings.py:50
 msgid "Welsh"
 msgstr "walijski"
 
-#: conf/global_settings.py:50
+#: conf/global_settings.py:51
 msgid "Danish"
 msgstr "duński"
 
-#: conf/global_settings.py:51
+#: conf/global_settings.py:52
 msgid "German"
 msgstr "niemiecki"
 
-#: conf/global_settings.py:52
+#: conf/global_settings.py:53
 msgid "Greek"
 msgstr "grecki"
 
-#: conf/global_settings.py:53
+#: conf/global_settings.py:54
 msgid "English"
 msgstr "angielski"
 
-#: conf/global_settings.py:54
+#: conf/global_settings.py:55
 msgid "Spanish"
 msgstr "hiszpański"
 
-#: conf/global_settings.py:55
-msgid "Estonian"
-msgstr "estoński"
-
 #: conf/global_settings.py:56
 msgid "Argentinean Spanish"
 msgstr "hiszpański argentyński"
 
 #: conf/global_settings.py:57
+msgid "Estonian"
+msgstr "estoński"
+
+#: conf/global_settings.py:58
 msgid "Basque"
 msgstr "baskijski"
 
-#: conf/global_settings.py:58
+#: conf/global_settings.py:59
 msgid "Persian"
 msgstr "perski"
 
-#: conf/global_settings.py:59
+#: conf/global_settings.py:60
 msgid "Finnish"
 msgstr "fiński"
 
-#: conf/global_settings.py:60
+#: conf/global_settings.py:61
 msgid "French"
 msgstr "francuski"
 
-#: conf/global_settings.py:61
+#: conf/global_settings.py:62
+msgid "Frisian"
+msgstr "fryzyjski"
+
+#: conf/global_settings.py:63
 msgid "Irish"
 msgstr "irlandzki"
 
-#: conf/global_settings.py:62
+#: conf/global_settings.py:64
 msgid "Galician"
 msgstr "galicyjski"
 
-#: conf/global_settings.py:63
-msgid "Hungarian"
-msgstr "węgierski"
-
-#: conf/global_settings.py:64
+#: conf/global_settings.py:65
 msgid "Hebrew"
 msgstr "hebrajski"
 
-#: conf/global_settings.py:65
+#: conf/global_settings.py:66
 msgid "Hindi"
 msgstr "hindi"
 
-#: conf/global_settings.py:66
+#: conf/global_settings.py:67
 msgid "Croatian"
 msgstr "chorwacki"
 
-#: conf/global_settings.py:67
+#: conf/global_settings.py:68
+msgid "Hungarian"
+msgstr "węgierski"
+
+#: conf/global_settings.py:69
 msgid "Icelandic"
 msgstr "islandzki"
 
-#: conf/global_settings.py:68
+#: conf/global_settings.py:70
 msgid "Italian"
 msgstr "włoski"
 
-#: conf/global_settings.py:69
+#: conf/global_settings.py:71
 msgid "Japanese"
 msgstr "japoński"
 
-#: conf/global_settings.py:70
+#: conf/global_settings.py:72
 msgid "Georgian"
 msgstr "gruziński"
 
-#: conf/global_settings.py:71
-msgid "Korean"
-msgstr "koreański"
-
-#: conf/global_settings.py:72
+#: conf/global_settings.py:73
 msgid "Khmer"
 msgstr "khmerski"
 
-#: conf/global_settings.py:73
+#: conf/global_settings.py:74
 msgid "Kannada"
 msgstr "kannada"
 
-#: conf/global_settings.py:74
-msgid "Latvian"
-msgstr "łotewski"
+#: conf/global_settings.py:75
+msgid "Korean"
+msgstr "koreański"
 
-#: conf/global_settings.py:75
+#: conf/global_settings.py:76
 msgid "Lithuanian"
 msgstr "litewski"
 
-#: conf/global_settings.py:76
+#: conf/global_settings.py:77
+msgid "Latvian"
+msgstr "łotewski"
+
+#: conf/global_settings.py:78
 msgid "Macedonian"
 msgstr "macedoński"
 
-#: conf/global_settings.py:77
+#: conf/global_settings.py:79
 msgid "Dutch"
 msgstr "holenderski"
 
-#: conf/global_settings.py:78
+#: conf/global_settings.py:80
 msgid "Norwegian"
 msgstr "norweski"
 
-#: conf/global_settings.py:79
+#: conf/global_settings.py:81
 msgid "Polish"
 msgstr "polski"
 
-#: conf/global_settings.py:80
+#: conf/global_settings.py:82
 msgid "Portuguese"
 msgstr "portugalski"
 
-#: conf/global_settings.py:81
+#: conf/global_settin

[Changeset] r12573 - in django/trunk: django/db/backends/sqlite3 tests/regressiontests/backends

[noreply]

Author: jkocherhans
Date: 2010-02-24 09:29:25 -0600 (Wed, 24 Feb 2010)
New Revision: 12573

Modified:
   django/trunk/django/db/backends/sqlite3/base.py
   django/trunk/tests/regressiontests/backends/models.py
   django/trunk/tests/regressiontests/backends/tests.py
Log:
Fixed #12818. SQLite now properly quotes strings for date extraction and 
truncation. Thanks, SmilyChris.

Modified: django/trunk/django/db/backends/sqlite3/base.py
===
--- django/trunk/django/db/backends/sqlite3/base.py 2010-02-24 14:52:49 UTC 
(rev 12572)
+++ django/trunk/django/db/backends/sqlite3/base.py 2010-02-24 15:29:25 UTC 
(rev 12573)
@@ -63,13 +63,17 @@
 class DatabaseOperations(BaseDatabaseOperations):
 def date_extract_sql(self, lookup_type, field_name):
 # sqlite doesn't support extract, so we fake it with the user-defined
-# function django_extract that's registered in connect().
-return 'django_extract("%s", %s)' % (lookup_type.lower(), field_name)
+# function django_extract that's registered in connect(). Note that
+# single quotes are used because this is a string (and could otherwise
+# cause a collision with a field name).
+return "django_extract('%s', %s)" % (lookup_type.lower(), field_name)
 
 def date_trunc_sql(self, lookup_type, field_name):
 # sqlite doesn't support DATE_TRUNC, so we fake it with a user-defined
-# function django_date_trunc that's registered in connect().
-return 'django_date_trunc("%s", %s)' % (lookup_type.lower(), 
field_name)
+# function django_date_trunc that's registered in connect(). Note that
+# single quotes are used because this is a string (and could otherwise
+# cause a collision with a field name).
+return "django_date_trunc('%s', %s)" % (lookup_type.lower(), 
field_name)
 
 def drop_foreignkey_sql(self):
 return ""

Modified: django/trunk/tests/regressiontests/backends/models.py
===
--- django/trunk/tests/regressiontests/backends/models.py   2010-02-24 
14:52:49 UTC (rev 12572)
+++ django/trunk/tests/regressiontests/backends/models.py   2010-02-24 
15:29:25 UTC (rev 12573)
@@ -15,6 +15,11 @@
 def __unicode__(self):
 return u'%s %s' % (self.first_name, self.last_name)
 
+class SchoolClass(models.Model):
+year = models.PositiveIntegerField()
+day = models.CharField(max_length=9, blank=True)
+last_updated = models.DateTimeField()
+
 qn = connection.ops.quote_name
 
 __test__ = {'API_TESTS': """

Modified: django/trunk/tests/regressiontests/backends/tests.py
===
--- django/trunk/tests/regressiontests/backends/tests.py2010-02-24 
14:52:49 UTC (rev 12572)
+++ django/trunk/tests/regressiontests/backends/tests.py2010-02-24 
15:29:25 UTC (rev 12573)
@@ -1,9 +1,12 @@
 # -*- coding: utf-8 -*-
 # Unit and doctests for specific database backends.
+import datetime
+import models
 import unittest
 from django.db import backend, connection, DEFAULT_DB_ALIAS
 from django.db.backends.signals import connection_created
 from django.conf import settings
+from django.test import TestCase
 
 class Callproc(unittest.TestCase):
 
@@ -34,6 +37,35 @@
 c.execute('DROP TABLE ltext')
 self.assertEquals(long_str, row[0].read())
 
+class DateQuotingTest(TestCase):
+
+def test_django_date_trunc(self):
+"""
+Test the custom ``django_date_trunc method``, in particular against
+fields which clash with strings passed to it (e.g. 'year') - see
+#12818__.
+
+__: http://code.djangoproject.com/ticket/12818
+
+"""
+updated = datetime.datetime(2010, 2, 20)
+models.SchoolClass.objects.create(year=2009, last_updated=updated)
+years = models.SchoolClass.objects.dates('last_updated', 'year')
+self.assertEqual(list(years), [datetime.datetime(2010, 1, 1, 0, 0)])
+
+def test_django_extract(self):
+"""
+Test the custom ``django_extract method``, in particular against fields
+which clash with strings passed to it (e.g. 'day') - see #12818__.
+
+__: http://code.djangoproject.com/ticket/12818
+
+"""
+updated = datetime.datetime(2010, 2, 20)
+models.SchoolClass.objects.create(year=2009, last_updated=updated)
+classes = models.SchoolClass.objects.filter(last_updated__day=20)
+self.assertEqual(len(classes), 1)
+
 def connection_created_test(sender, **kwargs):
 print 'connection_created signal'
 

-- 
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 

Re: [Django] #12028: Generic Inline doesn't validate unique_together

[Django]

#12028: Generic Inline doesn't validate unique_together
---+
  Reporter:  diverman  | Owner:  nessita
 
Status:  assigned  | Milestone: 
 
 Component:  Contrib apps  |   Version:  SVN
 
Resolution:|  Keywords:  content type generic 
inline unique validation formset admin modeladmin model
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by nessita):

  * owner:  nobody => nessita
  * 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.

Re: [Django] #2417: Support for binary type fields (aka: bytea in postgres and VARBINARY in mysql)

[Django]

#2417: Support for binary type fields (aka: bytea in postgres and VARBINARY in
mysql)
---+
  Reporter:  scan...@nominum.com   | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by sfllaw):

 * cc: si...@akoha.com (added)

Comment:

 Much like TextField uses LONGTEXT in MySQL, BlobField should use LONGBLOB.

-- 
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] #12955: Large file (bigger than 2GB) upload

[Django]

#12955: Large file (bigger than 2GB) upload
--+-
 Reporter:  iscarface |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  File uploads/storage  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 '''When i'm uploading more than 2GB file i have an error:
 '''[[BR]]

 OverflowError at /admin/films/film/add/[[BR]]

 long int too large to convert to int[[BR]]

 Request Method:POST[[BR]]

 Request URL:http://192.168.1.10/admin/films/film/add/[[BR]]

 Exception Type:OverflowError[[BR]]

 Exception Value:
 long int too large to convert to int[[BR]]

 Exception Location:/usr/lib/python2.5/site-
 packages/django/db/models/fields/files.py in _get_size, line 76[[BR]]

 Python Executable:/usr/bin/python[[BR]]

 Python Version:2.5.2[[BR]]

 Python Path:['/var/www/', '/usr/lib/python2.5', '/usr/lib/python2.5
 /plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-
 dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5
 /site-packages', '/usr/lib/python2.5/site-packages/PIL', '/var/lib/python-
 support/python2.5'][[BR]]

 Server time:Втр, 23 Фев 2010 17:16:19 +0200[[BR]]




 Django version = (1, 2, 0, 'alpha', 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-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] r12572 - django/branches/releases/1.1.X/docs/internals

[noreply]

Author: russellm
Date: 2010-02-24 08:52:49 -0600 (Wed, 24 Feb 2010)
New Revision: 12572

Modified:
   django/branches/releases/1.1.X/docs/internals/contributing.txt
Log:
[1.1.X] Fixed #12102 -- Corrected an example in the docs that suggested that 
you use a relative path in your PYTHONPATH. Thanks to alexkon for the report.

Backport of r12570 from trunk.

Modified: django/branches/releases/1.1.X/docs/internals/contributing.txt
===
--- django/branches/releases/1.1.X/docs/internals/contributing.txt  
2010-02-24 14:52:21 UTC (rev 12571)
+++ django/branches/releases/1.1.X/docs/internals/contributing.txt  
2010-02-24 14:52:49 UTC (rev 12572)
@@ -854,7 +854,7 @@
 
 .. code-block:: bash
 
-PYTHONPATH=..
+PYTHONPATH=`pwd`/..
 ./runtests.py --settings=settings generic_relations i18n
 
 Contrib apps

-- 
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] r12571 - in django/branches/releases/1.1.X/docs: ref topics/http

[noreply]

Author: russellm
Date: 2010-02-24 08:52:21 -0600 (Wed, 24 Feb 2010)
New Revision: 12571

Modified:
   django/branches/releases/1.1.X/docs/ref/settings.txt
   django/branches/releases/1.1.X/docs/topics/http/sessions.txt
Log:
[1.1.X] Fixed #11933 -- Added versionchanged marker for the cache_db session 
backend. Thanks to gabrielhurley for the report and patch.

Backport of r12569 from trunk.

Modified: django/branches/releases/1.1.X/docs/ref/settings.txt
===
--- django/branches/releases/1.1.X/docs/ref/settings.txt2010-02-24 
14:50:37 UTC (rev 12570)
+++ django/branches/releases/1.1.X/docs/ref/settings.txt2010-02-24 
14:52:21 UTC (rev 12571)
@@ -873,6 +873,9 @@
 
 .. versionadded:: 1.0
 
+.. versionchanged:: 1.1
+   The ``cache_db`` backend was added
+
 Default: ``django.contrib.sessions.backends.db``
 
 Controls where Django stores session data. Valid values are:
@@ -880,6 +883,7 @@
 * ``'django.contrib.sessions.backends.db'``
 * ``'django.contrib.sessions.backends.file'``
 * ``'django.contrib.sessions.backends.cache'``
+* ``'django.contrib.sessions.backends.cache_db'``
 
 See :ref:`topics-http-sessions`.
 

Modified: django/branches/releases/1.1.X/docs/topics/http/sessions.txt
===
--- django/branches/releases/1.1.X/docs/topics/http/sessions.txt
2010-02-24 14:50:37 UTC (rev 12570)
+++ django/branches/releases/1.1.X/docs/topics/http/sessions.txt
2010-02-24 14:52:21 UTC (rev 12571)
@@ -410,6 +410,9 @@
 
 .. versionadded:: 1.0
 
+.. versionchanged:: 1.1
+   The ``cache_db`` backend was added
+
 Default: ``django.contrib.sessions.backends.db``
 
 Controls where Django stores session data. Valid values are:
@@ -417,6 +420,7 @@
 * ``'django.contrib.sessions.backends.db'``
 * ``'django.contrib.sessions.backends.file'``
 * ``'django.contrib.sessions.backends.cache'``
+* ``'django.contrib.sessions.backends.cache_db'``
 
 See `configuring the session engine`_ for more details.
 

-- 
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] r12570 - django/trunk/docs/internals

[noreply]

Author: russellm
Date: 2010-02-24 08:50:37 -0600 (Wed, 24 Feb 2010)
New Revision: 12570

Modified:
   django/trunk/docs/internals/contributing.txt
Log:
Fixed #12102 -- Corrected an example in the docs that suggested that you use a 
relative path in your PYTHONPATH. Thanks to alexkon for the report.

Modified: django/trunk/docs/internals/contributing.txt
===
--- django/trunk/docs/internals/contributing.txt2010-02-24 14:49:38 UTC 
(rev 12569)
+++ django/trunk/docs/internals/contributing.txt2010-02-24 14:50:37 UTC 
(rev 12570)
@@ -900,7 +900,7 @@
 
 .. code-block:: bash
 
-PYTHONPATH=..
+PYTHONPATH=`pwd`/..
 ./runtests.py --settings=settings generic_relations i18n
 
 Contrib apps

-- 
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] r12569 - in django/trunk/docs: ref topics/http

[noreply]

Author: russellm
Date: 2010-02-24 08:49:38 -0600 (Wed, 24 Feb 2010)
New Revision: 12569

Modified:
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/topics/http/sessions.txt
Log:
Fixed #11933 -- Added versionchanged marker for the cache_db session backend. 
Thanks to gabrielhurley for the report and patch.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2010-02-24 14:42:03 UTC (rev 12568)
+++ django/trunk/docs/ref/settings.txt  2010-02-24 14:49:38 UTC (rev 12569)
@@ -1205,6 +1205,9 @@
 
 .. versionadded:: 1.0
 
+.. versionchanged:: 1.1
+   The ``cache_db`` backend was added
+
 Default: ``django.contrib.sessions.backends.db``
 
 Controls where Django stores session data. Valid values are:
@@ -1212,6 +1215,7 @@
 * ``'django.contrib.sessions.backends.db'``
 * ``'django.contrib.sessions.backends.file'``
 * ``'django.contrib.sessions.backends.cache'``
+* ``'django.contrib.sessions.backends.cache_db'``
 
 See :ref:`topics-http-sessions`.
 

Modified: django/trunk/docs/topics/http/sessions.txt
===
--- django/trunk/docs/topics/http/sessions.txt  2010-02-24 14:42:03 UTC (rev 
12568)
+++ django/trunk/docs/topics/http/sessions.txt  2010-02-24 14:49:38 UTC (rev 
12569)
@@ -422,6 +422,9 @@
 
 .. versionadded:: 1.0
 
+.. versionchanged:: 1.1
+   The ``cache_db`` backend was added
+
 Default: ``django.contrib.sessions.backends.db``
 
 Controls where Django stores session data. Valid values are:
@@ -429,6 +432,7 @@
 * ``'django.contrib.sessions.backends.db'``
 * ``'django.contrib.sessions.backends.file'``
 * ``'django.contrib.sessions.backends.cache'``
+* ``'django.contrib.sessions.backends.cache_db'``
 
 See `configuring the session engine`_ for more details.
 

-- 
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] r12568 - in django/branches/releases/1.1.X: . django/db/models tests/modeltests/model_inheritance tests/modeltests/proxy_models

[noreply]

Author: jkocherhans
Date: 2010-02-24 08:42:03 -0600 (Wed, 24 Feb 2010)
New Revision: 12568

Modified:
   django/branches/releases/1.1.X/
   django/branches/releases/1.1.X/django/db/models/base.py
   django/branches/releases/1.1.X/tests/modeltests/model_inheritance/models.py
   django/branches/releases/1.1.X/tests/modeltests/proxy_models/models.py
Log:
[1.1.X] Fixed #12152. DoesNotExist and MultipleObjectsReturned now subclass 
their parent model's exceptions. Backport of r12567 from trunk.



Property changes on: django/branches/releases/1.1.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12405,12492,12498,12523,12526,12533,12535,12537,12539,12541,12548,12556
   + 
/django/trunk:1-11500,11523,11527-11528,11531-11552,11554,11577,11579-11581,11588-11589,11591-11592,11596-11599,11601-11617,11619-11626,11628-11635,11637-11638,11643-11644,11648-11653,11656,11670,11678,11681,11684,11686,11688,11691,11693,11695,11697,11699,11701,11703,11705,11707,11714,11719,11732,11734,11740,11748,11751,11753,11756,11760,11800,11802,11808,11815,11817,11820,11822,11824,11826,11828,11831,11833,11835,11837,11839,11841,11844,11857,11864,11874,11876,11878,11885,11898,11901,11905,11909,11912,11914,11917,11938,11953,11961,11977,11979,11984,11986,11988,11990,11992,11994,11996,11998,12001,12004,12006,12011,12022,12024,12044-12045,12048,12054-12056,12059,12064,12066,12068,12070,12079,12086,12088,12104,12118,12132,12137-12138,12140-12141,12144,12150-12152,12220-12221,12229,12249,12253,12276,12282,12284,12293,12313,12317-12324,12333,12341,12343,12346,12353,12362,12379,12384,12405,12492,12498,12523,12526,12533,12535,12537,12539,12541,12548,12556,12567

Modified: django/branches/releases/1.1.X/django/db/models/base.py
===
--- django/branches/releases/1.1.X/django/db/models/base.py 2010-02-24 
14:32:11 UTC (rev 12567)
+++ django/branches/releases/1.1.X/django/db/models/base.py 2010-02-24 
14:42:03 UTC (rev 12568)
@@ -55,10 +55,14 @@
 
 new_class.add_to_class('_meta', Options(meta, **kwargs))
 if not abstract:
-new_class.add_to_class('DoesNotExist',
-subclass_exception('DoesNotExist', ObjectDoesNotExist, 
module))
-new_class.add_to_class('MultipleObjectsReturned',
-subclass_exception('MultipleObjectsReturned', 
MultipleObjectsReturned, module))
+new_class.add_to_class('DoesNotExist', 
subclass_exception('DoesNotExist',
+tuple(x.DoesNotExist
+for x in parents if hasattr(x, '_meta') and not 
x._meta.abstract)
+or (ObjectDoesNotExist,), module))
+new_class.add_to_class('MultipleObjectsReturned', 
subclass_exception('MultipleObjectsReturned',
+tuple(x.MultipleObjectsReturned
+for x in parents if hasattr(x, '_meta') and not 
x._meta.abstract)
+or (MultipleObjectsReturned,), module))
 if base_meta and not base_meta.abstract:
 # Non-abstract child classes inherit some attributes from their
 # non-abstract parent (unless an ABC comes before it in the
@@ -681,8 +685,8 @@
 
 if sys.version_info < (2, 5):
 # Prior to Python 2.5, Exception was an old-style class
-def subclass_exception(name, parent, unused):
-return types.ClassType(name, (parent,), {})
+def subclass_exception(name, parents, unused):
+return types.ClassType(name, parents, {})
 else:
-def subclass_exception(name, parent, module):
-return type(name, (parent,), {'__module__': module})
+def subclass_exception(name, parents, module):
+return type(name, parents, {'__module__': module})

Modified: 
django/branches/releases/1.1.X/tests/modeltests/model_inheritance/models.py
===
--- django/branches/releases/1.1.X/tests/modeltests/model_inheritance/models.py 
2010-02-24 14:32:11

Re: [Django] #12152: A child model's DoesNotExist doesn't extend the parent's

[Django]

#12152: A child model's DoesNotExist doesn't extend the parent's
---+
  Reporter:  mattmcc   | Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  1.1   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jkocherhans):

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

Comment:

 Fixed by r12567.

-- 
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] r12567 - in django/trunk: django/db/models tests/modeltests/model_inheritance tests/modeltests/proxy_models

[noreply]

Author: jkocherhans
Date: 2010-02-24 08:32:11 -0600 (Wed, 24 Feb 2010)
New Revision: 12567

Modified:
   django/trunk/django/db/models/base.py
   django/trunk/tests/modeltests/model_inheritance/models.py
   django/trunk/tests/modeltests/proxy_models/models.py
Log:
Fixed #12152. DoesNotExist and MultipleObjectsReturned now subclass their 
parent model's exceptions. Thanks, mattmcc and Alex Gaynor.

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2010-02-24 14:07:25 UTC (rev 
12566)
+++ django/trunk/django/db/models/base.py   2010-02-24 14:32:11 UTC (rev 
12567)
@@ -52,10 +52,14 @@
 
 new_class.add_to_class('_meta', Options(meta, **kwargs))
 if not abstract:
-new_class.add_to_class('DoesNotExist',
-subclass_exception('DoesNotExist', ObjectDoesNotExist, 
module))
-new_class.add_to_class('MultipleObjectsReturned',
-subclass_exception('MultipleObjectsReturned', 
MultipleObjectsReturned, module))
+new_class.add_to_class('DoesNotExist', 
subclass_exception('DoesNotExist',
+tuple(x.DoesNotExist
+for x in parents if hasattr(x, '_meta') and not 
x._meta.abstract)
+or (ObjectDoesNotExist,), module))
+new_class.add_to_class('MultipleObjectsReturned', 
subclass_exception('MultipleObjectsReturned',
+tuple(x.MultipleObjectsReturned
+for x in parents if hasattr(x, '_meta') and not 
x._meta.abstract)
+or (MultipleObjectsReturned,), module))
 if base_meta and not base_meta.abstract:
 # Non-abstract child classes inherit some attributes from their
 # non-abstract parent (unless an ABC comes before it in the
@@ -919,8 +923,8 @@
 
 if sys.version_info < (2, 5):
 # Prior to Python 2.5, Exception was an old-style class
-def subclass_exception(name, parent, unused):
-return types.ClassType(name, (parent,), {})
+def subclass_exception(name, parents, unused):
+return types.ClassType(name, parents, {})
 else:
-def subclass_exception(name, parent, module):
-return type(name, (parent,), {'__module__': module})
+def subclass_exception(name, parents, module):
+return type(name, parents, {'__module__': module})

Modified: django/trunk/tests/modeltests/model_inheritance/models.py
===
--- django/trunk/tests/modeltests/model_inheritance/models.py   2010-02-24 
14:07:25 UTC (rev 12566)
+++ django/trunk/tests/modeltests/model_inheritance/models.py   2010-02-24 
14:32:11 UTC (rev 12567)
@@ -38,6 +38,9 @@
 class Meta:
 pass
 
+class StudentWorker(Student, Worker):
+pass
+
 #
 # Abstract base classes with related models
 #
@@ -176,6 +179,32 @@
 ...
 AttributeError: type object 'CommonInfo' has no attribute 'objects'
 
+# A StudentWorker which does not exist is both a Student and Worker which does 
not exist.
+>>> try:
+... StudentWorker.objects.get(id=1)
+... except Student.DoesNotExist:
+... pass
+>>> try:
+... StudentWorker.objects.get(id=1)
+... except Worker.DoesNotExist:
+... pass
+
+# MultipleObjectsReturned is also inherited.
+>>> sw1 = StudentWorker()
+>>> sw1.name = 'Wilma'
+>>> sw1.age = 35
+>>> sw1.save()
+>>> sw2 = StudentWorker()
+>>> sw2.name = 'Betty'
+>>> sw2.age = 34
+>>> sw2.save()
+>>> try:
+... StudentWorker.objects.get(id__lt=10)
+... except Student.MultipleObjectsReturned:
+... pass
+... except Worker.MultipleObjectsReturned:
+... pass
+
 # Create a Post
 >>> post = Post(title='Lorem Ipsum')
 >>> post.save()
@@ -267,6 +296,18 @@
 ...
 DoesNotExist: ItalianRestaurant matching query does not exist.
 
+# An ItalianRestaurant which does not exist is also a Place which does not 
exist.
+>>> try:
+... ItalianRestaurant.objects.get(name='The Noodle Void')
+... except Place.DoesNotExist:
+... pass
+
+# MultipleObjectsReturned is also inherited.
+>>> try:
+... Restaurant.objects.get(id__lt=10)
+... except Place.MultipleObjectsReturned:
+... pass
+
 # Related objects work just as they normally do.
 
 >>> s1 = Supplier(name="Joe's Chickens", address='123 Sesame St')

Modified: django/trunk/tests/modeltests/proxy_models/models.py
===
--- django/trunk/tests/modeltests/proxy_models/models.py2010-02-24 
14:07:25 UTC (rev 12566)
+++ django/trunk/tests/modeltests/proxy_models/models.py2010-02-24 
14:32:11 UTC (rev 12567)
@@ -206,6 +206,26 @@
 >>> MyPersonProxy.objects.all()
 [, , ]
 
+# Proxy models are included in the ancestors for a model's DoesNotExist and 
MultipleObjectsReturned
+>>> try:
+... MyPersonProxy.objects.get(name='Zathras')
+... excep

[Changeset] r12566 - django/branches/releases/1.1.X/docs/topics/http

[noreply]

Author: russellm
Date: 2010-02-24 08:07:25 -0600 (Wed, 24 Feb 2010)
New Revision: 12566

Modified:
   django/branches/releases/1.1.X/docs/topics/http/file-uploads.txt
Log:
[1.1.X] Fixed #11782 -- Added some Sphinx metadata to the file uploads 
documentation. Thanks to timo for the patch.

Backport of r12562 from trunk.

Modified: django/branches/releases/1.1.X/docs/topics/http/file-uploads.txt
===
--- django/branches/releases/1.1.X/docs/topics/http/file-uploads.txt
2010-02-24 14:06:51 UTC (rev 12565)
+++ django/branches/releases/1.1.X/docs/topics/http/file-uploads.txt
2010-02-24 14:07:25 UTC (rev 12566)
@@ -9,15 +9,15 @@
 .. versionadded:: 1.0
 
 When Django handles a file upload, the file data ends up placed in
-``request.FILES`` (for more on the ``request`` object see the documentation for
-:ref:`request and response objects `). This document
-explains how files are stored on disk and in memory, and how to customize the
-default behavior.
+:attr:`request.FILES ` (for more on the
+``request`` object see the documentation for :ref:`request and response objects
+`). This document explains how files are stored on disk
+and in memory, and how to customize the default behavior.
 
 Basic file uploads
 ==
 
-Consider a simple form containing a ``FileField``::
+Consider a simple form containing a :class:`~django.forms.FileField`::
 
 from django import forms
 
@@ -25,14 +25,17 @@
 title = forms.CharField(max_length=50)
 file  = forms.FileField()
 
-A view handling this form will receive the file data in ``request.FILES``, 
which
-is a dictionary containing a key for each ``FileField`` (or ``ImageField``, or
-other ``FileField`` subclass) in the form. So the data from the above form 
would
+A view handling this form will receive the file data in
+:attr:`request.FILES `, which is a dictionary
+containing a key for each :class:`~django.forms.FileField` (or
+:class:`~django.forms.ImageField`, or other :class:`~django.forms.FileField`
+subclass) in the form. So the data from the above form would
 be accessible as ``request.FILES['file']``.
 
-Note that ``request.FILES`` will only contain data if the request method was
-``POST`` and the  that posted the request has the attribute
-``enctype="multipart/form-data"``. Otherwise, ``request.FILES`` will be empty.
+Note that :attr:`request.FILES ` will only
+contain data if the request method was ``POST`` and the  that posted
+the request has the attribute ``enctype="multipart/form-data"``. Otherwise,
+``request.FILES`` will be empty.
 
 Most of the time, you'll simply pass the file data from ``request`` into the
 form as described in :ref:`binding-uploaded-files`. This would look
@@ -54,16 +57,16 @@
 form = UploadFileForm()
 return render_to_response('upload.html', {'form': form})
 
-Notice that we have to pass ``request.FILES`` into the form's constructor; this
-is how file data gets bound into a form.
+Notice that we have to pass :attr:`request.FILES 
`
+into the form's constructor; this is how file data gets bound into a form.
 
 Handling uploaded files
 ---
 
 The final piece of the puzzle is handling the actual file data from
-``request.FILES``. Each entry in this dictionary is an ``UploadedFile`` object
--- a simple wrapper around an uploaded file. You'll usually use one of these
-methods to access the uploaded content:
+:attr:`request.FILES `. Each entry in this
+dictionary is an ``UploadedFile`` object -- a simple wrapper around an uploaded
+file. You'll usually use one of these methods to access the uploaded content:
 
 ``UploadedFile.read()``
 Read the entire uploaded data from the file. Be careful with this

-- 
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] r12565 - django/branches/releases/1.1.X/docs/ref/models

[noreply]

Author: russellm
Date: 2010-02-24 08:06:51 -0600 (Wed, 24 Feb 2010)
New Revision: 12565

Modified:
   django/branches/releases/1.1.X/docs/ref/models/querysets.txt
Log:
[1.1.X] Fixed #12538 -- Added a note that pickles aren't stable during version 
updates. Thanks to snow0x2d0 for the suggestion.

Backport of r12560 from trunk.

Modified: django/branches/releases/1.1.X/docs/ref/models/querysets.txt
===
--- django/branches/releases/1.1.X/docs/ref/models/querysets.txt
2010-02-24 14:05:58 UTC (rev 12564)
+++ django/branches/releases/1.1.X/docs/ref/models/querysets.txt
2010-02-24 14:06:51 UTC (rev 12565)
@@ -102,6 +102,14 @@
 (and fully supported) to pickle and unpickle the attribute's contents as
 described here.
 
+.. admonition:: You can't share pickles between versions
+
+   Pickles of QuerySets are only valid for the version of Django that
+   was used to generate them. If you generate a pickle using Django
+   version N, there is no guarantee that pickle will be readable with
+   Django version N+1. Pickles should not be used as part of a long-term
+   archival strategy.
+
 .. _pickle: http://docs.python.org/library/pickle.html
 
 .. _queryset-api:

-- 
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] r12564 - in django/branches/releases/1.1.X/docs: howto topics/db

[noreply]

Author: russellm
Date: 2010-02-24 08:05:58 -0600 (Wed, 24 Feb 2010)
New Revision: 12564

Modified:
   django/branches/releases/1.1.X/docs/howto/auth-remote-user.txt
   django/branches/releases/1.1.X/docs/topics/db/transactions.txt
Log:
[1.1.X] Fixed #12880 -- Added some missing sphinx directives for module 
references. Thanks to psagers for the report, and timo for the patch.

Backport of r12559 from trunk.

Modified: django/branches/releases/1.1.X/docs/howto/auth-remote-user.txt
===
--- django/branches/releases/1.1.X/docs/howto/auth-remote-user.txt  
2010-02-24 14:05:18 UTC (rev 12563)
+++ django/branches/releases/1.1.X/docs/howto/auth-remote-user.txt  
2010-02-24 14:05:58 UTC (rev 12564)
@@ -4,6 +4,8 @@
 Authentication using ``REMOTE_USER``
 
 
+.. currentmodule:: django.contrib.backends
+
 This document describes how to make use of external authentication sources
 (where the Web server sets the ``REMOTE_USER`` environment variable) in your
 Django applications.  This type of authentication solution is typically seen on

Modified: django/branches/releases/1.1.X/docs/topics/db/transactions.txt
===
--- django/branches/releases/1.1.X/docs/topics/db/transactions.txt  
2010-02-24 14:05:18 UTC (rev 12563)
+++ django/branches/releases/1.1.X/docs/topics/db/transactions.txt  
2010-02-24 14:05:58 UTC (rev 12564)
@@ -4,6 +4,8 @@
 Managing database transactions
 ==
 
+.. currentmodule:: django.db
+
 Django gives you a few ways to control how database transactions are managed,
 if you're using a database that supports transactions.
 

-- 
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] r12563 - django/branches/releases/1.1.X

[noreply]

Author: russellm
Date: 2010-02-24 08:05:18 -0600 (Wed, 24 Feb 2010)
New Revision: 12563

Modified:
   django/branches/releases/1.1.X/README
Log:
[1.1.X] Fixed #12951 -- Corrected README link for deployment. Thanks to carljm 
for the report.

Backport of r12558 from trunk.

Modified: django/branches/releases/1.1.X/README
===
--- django/branches/releases/1.1.X/README   2010-02-24 13:57:46 UTC (rev 
12562)
+++ django/branches/releases/1.1.X/README   2010-02-24 14:05:18 UTC (rev 
12563)
@@ -11,8 +11,7 @@
   docs/intro/tutorial02.txt, etc.).
 
 * If you want to set up an actual deployment server, read
-  docs/howto/deployment/modpython.txt for instructions on running Django
-  under mod_python.
+  docs/howto/deployment/index.txt for instructions.
 
 * You'll probably want to read through the topical guides (in docs/topics)
   next; from there you can jump to the HOWTOs (in docs/howto) for specific

-- 
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] r12562 - django/trunk/docs/topics/http

[noreply]

Author: russellm
Date: 2010-02-24 07:57:46 -0600 (Wed, 24 Feb 2010)
New Revision: 12562

Modified:
   django/trunk/docs/topics/http/file-uploads.txt
Log:
Fixed #11782 -- Added some Sphinx metadata to the file uploads documentation. 
Thanks to timo for the patch.

Modified: django/trunk/docs/topics/http/file-uploads.txt
===
--- django/trunk/docs/topics/http/file-uploads.txt  2010-02-24 13:57:02 UTC 
(rev 12561)
+++ django/trunk/docs/topics/http/file-uploads.txt  2010-02-24 13:57:46 UTC 
(rev 12562)
@@ -9,15 +9,15 @@
 .. versionadded:: 1.0
 
 When Django handles a file upload, the file data ends up placed in
-``request.FILES`` (for more on the ``request`` object see the documentation for
-:ref:`request and response objects `). This document
-explains how files are stored on disk and in memory, and how to customize the
-default behavior.
+:attr:`request.FILES ` (for more on the
+``request`` object see the documentation for :ref:`request and response objects
+`). This document explains how files are stored on disk
+and in memory, and how to customize the default behavior.
 
 Basic file uploads
 ==
 
-Consider a simple form containing a ``FileField``::
+Consider a simple form containing a :class:`~django.forms.FileField`::
 
 from django import forms
 
@@ -25,14 +25,17 @@
 title = forms.CharField(max_length=50)
 file  = forms.FileField()
 
-A view handling this form will receive the file data in ``request.FILES``, 
which
-is a dictionary containing a key for each ``FileField`` (or ``ImageField``, or
-other ``FileField`` subclass) in the form. So the data from the above form 
would
+A view handling this form will receive the file data in
+:attr:`request.FILES `, which is a dictionary
+containing a key for each :class:`~django.forms.FileField` (or
+:class:`~django.forms.ImageField`, or other :class:`~django.forms.FileField`
+subclass) in the form. So the data from the above form would
 be accessible as ``request.FILES['file']``.
 
-Note that ``request.FILES`` will only contain data if the request method was
-``POST`` and the  that posted the request has the attribute
-``enctype="multipart/form-data"``. Otherwise, ``request.FILES`` will be empty.
+Note that :attr:`request.FILES ` will only
+contain data if the request method was ``POST`` and the  that posted
+the request has the attribute ``enctype="multipart/form-data"``. Otherwise,
+``request.FILES`` will be empty.
 
 Most of the time, you'll simply pass the file data from ``request`` into the
 form as described in :ref:`binding-uploaded-files`. This would look
@@ -54,16 +57,16 @@
 form = UploadFileForm()
 return render_to_response('upload.html', {'form': form})
 
-Notice that we have to pass ``request.FILES`` into the form's constructor; this
-is how file data gets bound into a form.
+Notice that we have to pass :attr:`request.FILES 
`
+into the form's constructor; this is how file data gets bound into a form.
 
 Handling uploaded files
 ---
 
 The final piece of the puzzle is handling the actual file data from
-``request.FILES``. Each entry in this dictionary is an ``UploadedFile`` object
--- a simple wrapper around an uploaded file. You'll usually use one of these
-methods to access the uploaded content:
+:attr:`request.FILES `. Each entry in this
+dictionary is an ``UploadedFile`` object -- a simple wrapper around an uploaded
+file. You'll usually use one of these methods to access the uploaded content:
 
 ``UploadedFile.read()``
 Read the entire uploaded data from the file. Be careful with this

-- 
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] r12561 - django/trunk/docs/topics/db

[noreply]

Author: russellm
Date: 2010-02-24 07:57:02 -0600 (Wed, 24 Feb 2010)
New Revision: 12561

Modified:
   django/trunk/docs/topics/db/sql.txt
Log:
Fixed #12519 -- Corrected documentation on .raw() queries. Thanks to boralyl 
for the report and patch.

Modified: django/trunk/docs/topics/db/sql.txt
===
--- django/trunk/docs/topics/db/sql.txt 2010-02-24 13:56:19 UTC (rev 12560)
+++ django/trunk/docs/topics/db/sql.txt 2010-02-24 13:57:02 UTC (rev 12561)
@@ -25,8 +25,10 @@
 
 .. method:: Manager.raw(raw_query, params=None, translations=None)
 
-This method method takes a raw SQL query, executes it, and returns model
-instances.
+This method method takes a raw SQL query, executes it, and returns a
+:class:`~django.db.models.query.RawQuerySet` instance. This
+:class:`~django.db.models.query.RawQuerySet` instance can be iterated
+over just like an normal QuerySet to provide object instances.
 
 This is best illustrated with an example. Suppose you've got the following 
model::
 
@@ -37,8 +39,10 @@
 
 You could then execute custom SQL like so::
 
->>> Person.objects.raw('SELECT * from myapp_person')
-[, , ...]
+>>> for p in Person.objects.raw('SELECT * FROM myapp_person'):
+... print p
+John Smith
+Jane Jones
 
 .. admonition:: Model table names
 
@@ -110,7 +114,7 @@
 
 Fields may also be left out::
 
->>> people = Person.objects.raw('SELECT id, first_name FROM myapp_person'):
+>>> people = Person.objects.raw('SELECT id, first_name FROM myapp_person')
 
 The ``Person`` objects returned by this query will be :ref:`deferred
 ` model instances. This means that the fields that are omitted
@@ -142,7 +146,7 @@
 
 >>> people = Person.objects.raw('SELECT *, age(birth_date) AS age FROM 
myapp_person')
 >>> for p in people:
-...   print "%s is %s." % (p.first_name, p.age)
+... print "%s is %s." % (p.first_name, p.age)
 John is 37.
 Jane is 42.
 ...

-- 
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] r12560 - django/trunk/docs/ref/models

[noreply]

Author: russellm
Date: 2010-02-24 07:56:19 -0600 (Wed, 24 Feb 2010)
New Revision: 12560

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Fixed #12538 -- Added a note that pickles aren't stable during version updates. 
Thanks to snow0x2d0 for the suggestion.

Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2010-02-24 13:55:37 UTC (rev 
12559)
+++ django/trunk/docs/ref/models/querysets.txt  2010-02-24 13:56:19 UTC (rev 
12560)
@@ -106,6 +106,14 @@
 (and fully supported) to pickle and unpickle the attribute's contents as
 described here.
 
+.. admonition:: You can't share pickles between versions
+
+   Pickles of QuerySets are only valid for the version of Django that
+   was used to generate them. If you generate a pickle using Django
+   version N, there is no guarantee that pickle will be readable with
+   Django version N+1. Pickles should not be used as part of a long-term
+   archival strategy.
+
 .. _pickle: http://docs.python.org/library/pickle.html
 
 .. _queryset-api:

-- 
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] r12559 - in django/trunk/docs: howto topics/db

[noreply]

Author: russellm
Date: 2010-02-24 07:55:37 -0600 (Wed, 24 Feb 2010)
New Revision: 12559

Modified:
   django/trunk/docs/howto/auth-remote-user.txt
   django/trunk/docs/topics/db/transactions.txt
Log:
Fixed #12880 -- Added some missing sphinx directives for module references. 
Thanks to psagers for the report, and timo for the patch.

Modified: django/trunk/docs/howto/auth-remote-user.txt
===
--- django/trunk/docs/howto/auth-remote-user.txt2010-02-24 13:54:53 UTC 
(rev 12558)
+++ django/trunk/docs/howto/auth-remote-user.txt2010-02-24 13:55:37 UTC 
(rev 12559)
@@ -4,6 +4,8 @@
 Authentication using ``REMOTE_USER``
 
 
+.. currentmodule:: django.contrib.backends
+
 This document describes how to make use of external authentication sources
 (where the Web server sets the ``REMOTE_USER`` environment variable) in your
 Django applications.  This type of authentication solution is typically seen on

Modified: django/trunk/docs/topics/db/transactions.txt
===
--- django/trunk/docs/topics/db/transactions.txt2010-02-24 13:54:53 UTC 
(rev 12558)
+++ django/trunk/docs/topics/db/transactions.txt2010-02-24 13:55:37 UTC 
(rev 12559)
@@ -4,6 +4,8 @@
 Managing database transactions
 ==
 
+.. currentmodule:: django.db
+
 Django gives you a few ways to control how database transactions are managed,
 if you're using a database that supports transactions.
 

-- 
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] r12558 - django/trunk

[noreply]

Author: russellm
Date: 2010-02-24 07:54:53 -0600 (Wed, 24 Feb 2010)
New Revision: 12558

Modified:
   django/trunk/README
Log:
Fixed #12951 -- Corrected README link for deployment. Thanks to carljm for the 
report.

Modified: django/trunk/README
===
--- django/trunk/README 2010-02-23 23:48:44 UTC (rev 12557)
+++ django/trunk/README 2010-02-24 13:54:53 UTC (rev 12558)
@@ -11,8 +11,7 @@
   docs/intro/tutorial02.txt, etc.).
 
 * If you want to set up an actual deployment server, read
-  docs/howto/deployment/modpython.txt for instructions on running Django
-  under mod_python.
+  docs/howto/deployment/index.txt for instructions.
 
 * You'll probably want to read through the topical guides (in docs/topics)
   next; from there you can jump to the HOWTOs (in docs/howto) for specific

-- 
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] #12648: [PATCH]User send_email change from send_mail to EmailMessage

[Django]

#12648: [PATCH]User send_email change from send_mail to EmailMessage
-+--
  Reporter:  galuszkak   | Owner:  galuszkak
 
Status:  closed  | Milestone:   
 
 Component:  Authentication  |   Version:  SVN  
 
Resolution:  invalid |  Keywords:  send_mail, email, 
send_email, EmailMessage
 Stage:  Unreviewed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 Well, "Bryan" is wrong. As a word of advice, if Django deprecates
 something, you'll be able to find evidence of it on *our* website, and in
 *our* documentation.

 As for email "not working" - you're going to need to be more a whole lot
 more specific than "working invalid". I have plenty of evidence that it is
 working fine.

-- 
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] #11680: add references to EMAIL* settings when discussing error notifications

[Django]

#11680: add references to EMAIL* settings when discussing error notifications
+---
  Reporter:  ccurvey| Owner:  jdunck
Status:  assigned   | Milestone:  1.2   
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Changes (by russellm):

  * needs_better_patch:  0 => 1
  * stage:  Ready for checkin => Accepted

Comment:

 The patch isn't really correct - the error emails are sent to the default
 email backend, so the instructions should read that you need to configure
 that backend as documented in the email backends docs. In most cases, this
 will mean EMAIL_HOST etc, but it might not.

-- 
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] #12954: Website Admin documentation doesn't have the same fields in two similar examples

[Django]

#12954: Website Admin documentation doesn't have the same fields in two similar
examples
-+--
 Reporter:  humitos  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  1.1   
 Keywords:  admin, fields, fieldset  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 I was reading this:
 
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.fieldsets

 and then... read this:
 
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.fields

 I found that the page says that it's the same example but written in
 another way, but in the second example is missing one field: 'sites'

 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] #12648: [PATCH]User send_email change from send_mail to EmailMessage

[Django]

#12648: [PATCH]User send_email change from send_mail to EmailMessage
-+--
  Reporter:  galuszkak   | Owner:  galuszkak
 
Status:  reopened| Milestone:   
 
 Component:  Authentication  |   Version:  SVN  
 
Resolution:  |  Keywords:  send_mail, email, 
send_email, EmailMessage
 Stage:  Unreviewed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by galuszkak):

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

Comment:

 Well i read here:
 http://ltslashgt.com/2007/07/02/gmail-and-django/

 That send_email is deprecated. Even if no. Send_email is not working
 properly. Because it not deliever emails. I discover this bug in
 registration app when i was sending twice one mail. First with
 User.send_mail() that was using send_email and second with EmailMessage.
 To gmail this 2 mails was receive. But on other email hosting only email
 from EmailMessage was receive.

 So I guess that send_email is not working always properly. Not for me. I
 tried it on two websites. Always send_email was working invalid.

-- 
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] #6191: Admin delete view doesn't show all items in some circumstances

[Django]

#6191: Admin delete view doesn't show all items in some circumstances
---+
  Reporter:  nicklane  | Owner:  carljm
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 The general approach here looks really good. Some review comments:

  * I got a test failure running the
 admin_util.NestedObjectsTests.test_siblings test (got [0, [2, 1]],
 expected [0, [1, 2]]). The problem appears to be that NestedObjects uses a
 set to collect objects, which therefore doesn't give a guaranteed result
 order. One fix is to use a list instead if a set; the other fix is to
 modify the test so it isn't order dependent. I'm fairly certain just using
 a list is all that is required - I couldn't see anything obvious that was
 relying on the fact that sets were unique or easy to look up.

  * I'm not wild about the inner _format_callback function in
 get_deleted_objects(). admin_site, perms_needed, and levels_to_root are
 all variables from a scope outside the function itself, which is a bit of
 a code smell. I'd be much happier if _format_callback was a standalone
 function in its own right that took these extra values as kwargs that were
 passed in by nested (i.e., nested takes any extra kwargs and passes them
 down the the callback)

  * The one test case that I can see that is obviously missing is
 inheritance. On paper, this is probably caught by deleting OneToOneFields,
 but there is enough special handling for inheritance that it's worth
 having a specific test case for it (suggestion: SuperVillain subclassing
 Villain, create a SuperVillain; what happens if you delete the villain? if
 you delete the supervillain?)

  * The template change makes me mildly nervous. Ideally, I'd prefer that
 this change wasn't necessary, as it will break any existing templates in
 the field that are constructed against the context that has historically
 existed - even if that just means introducing a dummy top-level list entry
 so the old template can iterate over a single element.

  * The comments on the add() method for NestedObjects makes a point of
 highlighting that the model, pk and parent_model arguments aren't actually
 used. I accept that they are completely redundant as they can be derived
 from the obj and parent_obj arguments. However, I'm a little nervous

  * Is there any reason that NestedObjects can't be merged into
 CollectedObjects? It seems to me like there is a lot of duplication
 between the two classes, and we would be better served by extending
 CollectedObjects to provide the nested() functionality rather than have a
 second collection class.

-- 
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] #12235: MultiValueDictKeyError when editing Inline objects

[Django]

#12235: MultiValueDictKeyError when editing Inline objects
---+
  Reporter:  br...@playfirst.com   | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by j.sta...@gmail.com):

 Yes, I'm getting the same error - but don't even know were to start
 looking for the solution?

-- 
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] #11907: EmailField should run strip()

[Django]

#11907: EmailField should run strip()
+---
  Reporter:  whatcould  | Owner:  djansoft
Status:  closed | Milestone:  
 Component:  Forms  |   Version:  1.1 
Resolution:  duplicate  |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by ubernostrum):

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

-- 
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] #11907: EmailField should run strip()

[Django]

#11907: EmailField should run strip()
+---
  Reporter:  whatcould  | Owner:  djansoft
Status:  reopened   | Milestone:  
 Component:  Forms  |   Version:  1.1 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by ubernostrum):

 Well... actually it's part of (and thus now being closed as a duplicate
 of) #6362, which asks for whitespace stripping to be applied before
 validating data in all text-based field types. And that's definitely a
 feature request, so once again there's no way for this to make it into
 1.2. The best way to advance this is to hold on for a bit while 1.2 gets
 out the door, then lobby for it to get into 1.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] #9523: Restart runserver after translation MO files change

[Django]

#9523: Restart runserver after translation MO files change
---+
  Reporter:  w...@adreswerk.nl  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Internationalization  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Someday/Maybe | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by trebor74hr):

 === Solution suggestion ===

 Whenever new translation is to be submitted django-admin compilemessages
 management command has to be called
 (http://docs.djangoproject.com/en/1.1/topics/i18n/localization/).
 If command
 
http://code.djangoproject.com/browser/django/trunk/django/core/management/commands/compilemessages.py
 issues at least one successful compiling (new version of mo is created) -
 it could
 "touch" some django python file - what should trigger django-dev server
 restart. The only issue is which file to touch, while it shouldn't be any
 file that user is editing in the meantime.

 btw. #4032 is closed ticket with the same 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] #8426: Wrap help_text in "", like errors in "" in HTML output

[Django]

#8426: Wrap help_text in "", like errors in "" in HTML output
---+
  Reporter:  erikcw| Owner:  kmtracey 
Status:  new   | Milestone:   
 Component:  Forms |   Version:  SVN  
Resolution:|  Keywords:  help_text, as_p, as_ul, forms
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by ubernostrum):

 Replying to [comment:19 pihentagy]:
 > Definitely not happy. Simple bug, simple patch, more than one year old.

 Like it or not, this is a feature request, and the process for feature
 requests getting into new releases is documented. The biggest factor for a
 small request is that someone motivated -- perhaps you, if you feel
 strongly about this ticket -- needs to bring it up during the feature-
 development phase of a release cycle and make sure there's some discussion
 about it and a decision as to whether it's worth adding. If no-one does
 that (and no-one did for the 1.2 release cycle), it's more or less
 inevitable that the request will simply be punted until someone does. And
 since 1.2 is feature-frozen there's no way to do that for 1.2 now; if
 you'd like to see this make it into Django, then make a note of it and pop
 onto the django-dev list when feature discussion for 1.3 opens up in a
 month or so.

-- 
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] #4032: server restart necessary after compile-messages.py

[Django]

#4032: server restart necessary after compile-messages.py
--+-
  Reporter:  t...@barnettweb.net  | Owner:  jacob   
  
Status:  closed   | Milestone:  
  
 Component:  Documentation|   Version:  SVN 
  
Resolution:  worksforme   |  Keywords:  
internationalization po gettext translate translations
 Stage:  Unreviewed   | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Comment (by trebor74hr):

 the same issue in #9523

-- 
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] #8426: Wrap help_text in "", like errors in "" in HTML output

[Django]

#8426: Wrap help_text in "", like errors in "" in HTML output
---+
  Reporter:  erikcw| Owner:  kmtracey 
Status:  new   | Milestone:   
 Component:  Forms |   Version:  SVN  
Resolution:|  Keywords:  help_text, as_p, as_ul, forms
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by pihentagy):

 Definitely not happy. Simple bug, simple patch, more than one year old.

-- 
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] #6191: Admin delete view doesn't show all items in some circumstances

[Django]

#6191: Admin delete view doesn't show all items in some circumstances
---+
  Reporter:  nicklane  | Owner:  carljm
Status:  new   | Milestone:  1.2   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by carljm):

 The latest patch here includes special-case code to fix #12025. If the fix
 for #12953 moves generic-relation handling up to
 Model._collect_sub_objects(), it should be possible to get rid of the
 special-case here.

-- 
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] #12953: Generic-related objects are cascade-deleted, but the cascade does not extend beyond them

[Django]

#12953: Generic-related objects are cascade-deleted, but the cascade does not
extend beyond them
---+
  Reporter:  carljm| Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Database layer (models, ORM)
  * needs_tests:  => 0
  * version:  1.1 => SVN
  * milestone:  => 1.2
  * needs_docs:  => 0

Comment:

 If we're smart with the fix for this, it might be possible to avoid
 special-casing generic relations at all, and thus get rid of one
 dependency of the ORM on django.contrib.contenttypes.

-- 
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] #12953: Generic-related objects are cascade-deleted, but the cascade does not extend beyond them

[Django]

#12953: Generic-related objects are cascade-deleted, but the cascade does not
extend beyond them
---+
 Reporter:  carljm |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Say I have these models:

 {{{
 class Award(models.Model):
 name = models.CharField(max_length=25)
 object_id = models.PositiveIntegerField()
 content_type = models.ForeignKey(ContentType)
 content_object = generic.GenericForeignKey()

 class AwardNote(models.Model):
 award = models.ForeignKey(Award)
 note = models.CharField(max_length=100)

 class Person(models.Model):
 name = models.CharField(max_length=25)
 awards = generic.GenericRelation(Award)
 }}}

 If I create one of each, then delete the Person, Django currently cascade-
 deletes the generically-related Award, but does not follow the relations
 any further, and thus the AwardNote is left undeleted. Databases which
 enforce referential integrity may delete the AwardNote themselves, or
 raise an error; databases which don't will leave the AwardNote with a
 broken ForeignKey.

 Since Django's deletion behavior is advertised as equivalent to ON DELETE
 CASCADE, Django should explicitly delete the AwardNote in this case.

 Currently deletion of generically-related objects is done in
 DeleteQuery.delete_batch_related(). I think the fix for this will involve
 moving it up to Model._collect_sub_objects() instead.

 Testcase attached.

-- 
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] #11212: Don't encode emails with base64/qp

[Django]

#11212: Don't encode emails with base64/qp
---+
  Reporter:  phr   | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  django.core.mail  |   Version:  SVN  
Resolution:|  Keywords:  send_mail
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by phr):

  * needs_better_patch:  1 => 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-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] #11212: Don't encode emails with base64/qp

[Django]

#11212: Don't encode emails with base64/qp
---+
  Reporter:  phr   | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  django.core.mail  |   Version:  SVN  
Resolution:|  Keywords:  send_mail
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  1 |  
---+
Comment (by phr):

 Replying to [comment:8 gisle]:
 > I've included a patch that makes the tests pass, but as demonstrated by
 the patch this make us start generating email with "`Content-Transfer-
 Encoding: 8bit`" when passing in Unicode strings as subject or content.  I
 think that should be avoided, so I don't recommend this patch as is.

 [[BR]]

 The use of 8bit encoding is exactly the aim of this ticket, so the patch
 does the right thing IMHO.

 Except for a few legacy paths, SMTP is mostly 8bit today - and where not,
 it's the MTA's role to downconvert to 7bit.

 Many email clients are generating 8bit-encoded messages (Thunderbird,
 Mutt, etc) and people routinely use 8bit email every day. Avoiding it
 makes no longer any sense, and the current practice of using quoted-
 printable does not work right for non-latin aplhabets.

 Please note that other software already implemented my proposal - see e.g.
 http://trac.edgewall.org/ticket/8252

-- 
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.