date:20091017

Re: [Django] #12049: New LazyObject-wrapped User breaks queries in template tags

2009-10-17 Thread Django

#12049: New LazyObject-wrapped User breaks queries in template tags
-+--
  Reporter:  chipx86 | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by chipx86):

 The attached patch implements {{{__deepcopy__}}} for {{{LazyObject}}}. I
 like the idea of providing the implementation there rather than in a
 subclass as it seems that this functionality should exist higher up, but
 if you think of a case where we really should limit this to a subclass, we
 can change that.

 I kept the testcase in the same place even though really the fix isn't
 part of the auth framework. I couldn't find anything that, as far as I
 could tell, tested LazyObject specifically, and since the User wrapper is
 a real-world case of breakage (which could break again if User was wrapped
 in something else), I thought it'd be nice to continue testing this case.
 However, I'll leave this up to you to decide.

 Ran the unit tests with Python 2.4, 2.5 and 2.6. All tests succeeded.

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

Re: [Django] #11735: Wrong documentation for changing Model formsets queryset

2009-10-17 Thread Django

#11735: Wrong documentation for changing Model formsets queryset
+---
  Reporter:  claudep| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * stage:  Unreviewed => Ready for checkin
  * 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #12049: New LazyObject-wrapped User breaks queries in template tags

2009-10-17 Thread Django

#12049: New LazyObject-wrapped User breaks queries in template tags
-+--
  Reporter:  chipx86 | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by lukeplant):

 Thanks for the test, that's really useful.  Hopefully I look at fixing
 this on Monday.  If you want to do it yourself, I imagine the fix will be
 to implement `__deepcopy__` on !SimpleLazyObject.  I think the
 implementation is straightforward - if `self._wrapped is None`, then you
 just assign the same _setupfunc function to the copy (no need to make a
 copy of the function).  If `self._wrapped is not None`, you copy the
 wrapped object itself.

 In this context, I don't think we need a deep copy of the wrapped object,
 because it is just going to be thrown away and not modified, but to obey
 the `__deepcopy__` contract, you might want to make it a deep copy.
 Alternatively, you could make a !ContextLazyObject which subclasses
 !SimpleLazyObject, and has a `__deepcopy__` method that does shallow
 copies, which should be safe if !ContextLazyObject is only used for this
 purpose.  Perhaps.  I haven't thought about it properly.

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

Re: [Django] #12049: New LazyObject-wrapped User breaks queries in template tags

2009-10-17 Thread Django

#12049: New LazyObject-wrapped User breaks queries in template tags
-+--
  Reporter:  chipx86 | Owner:  nobody
Status:  new | Milestone:
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by chipx86):

 * cc: chip...@chipx86.com (added)
  * 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #12049: New LazyObject-wrapped User breaks queries in template tags

2009-10-17 Thread Django

#12049: New LazyObject-wrapped User breaks queries in template tags
+---
 Reporter:  chipx86 |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Authentication  | Version:  SVN   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 I spent a couple days tracking this down since the last fix (ticket
 #12037) for the new lazy-wrapped User. Basically, if you have a template
 tag that grabs the User from the context and performs a complex query with
 two or more {{{Q()}}}'s chained together, it will fail. The failure case
 on Python 2.4 is fatal, while on 2.5/2.6 it seems to not fail but does log
 internally caught exception spew.

 Basically, when a deepcopy() is performed on the node list, it sees a
 {{{function()}}} for the wrapped User and just fails.

 Imagine you have a template tag that takes in the context and starts to
 build a query, like so:

 {{{
 query = Q(user=context['user']) & Q(someflag=True)
 }}}

 The process of using a Q() on a wrapped User and chaining with another Q()
 will break. On Python 2.4, we see:

 {{{
   File "/usr/lib/python2.4/site-packages/django/db/models/query_utils.py",
 line 162, in __and__
 return self._combine(other, self.AND)
   File "/usr/lib/python2.4/site-packages/django/db/models/query_utils.py",
 line 154, in _combine
 obj = deepcopy(self)
   File "/usr/lib/python2.4/copy.py", line 185, in deepcopy
 y = copier(x, memo)
   File "/usr/lib/python2.4/site-packages/django/utils/tree.py", line 61,
 in __deepcopy__
 obj.children = deepcopy(self.children, memodict)
   File "/usr/lib/python2.4/copy.py", line 174, in deepcopy
 y = copier(x, memo)
   File "/usr/lib/python2.4/copy.py", line 241, in _deepcopy_list
 y.append(deepcopy(a, memo))
   File "/usr/lib/python2.4/copy.py", line 174, in deepcopy
 y = copier(x, memo)
   File "/usr/lib/python2.4/copy.py", line 248, in _deepcopy_tuple
 y.append(deepcopy(a, memo))
   File "/usr/lib/python2.4/copy.py", line 204, in deepcopy
 y = _reconstruct(x, rv, 1, memo)
   File "/usr/lib/python2.4/copy.py", line 351, in _reconstruct
 state = deepcopy(state, memo)
   File "/usr/lib/python2.4/copy.py", line 174, in deepcopy
 y = copier(x, memo)
   File "/usr/lib/python2.4/copy.py", line 268, in _deepcopy_dict
 y[deepcopy(key, memo)] = deepcopy(value, memo)
   File "/usr/lib/python2.4/copy.py", line 204, in deepcopy
 y = _reconstruct(x, rv, 1, memo)
   File "/usr/lib/python2.4/copy.py", line 336, in _reconstruct
 y = callable(*args)
   File "/usr/lib/python2.4/copy_reg.py", line 92, in __newobj__
 return cls.__new__(cls, *args)
 TypeError: function() takes at least 2 arguments (0 given)
 }}}

 On Python 2.5 and 2.6, the call succeeds (or at least doesn't throw a
 fatal exception, but I don't know if there are internal side effects
 here), but does log the following:

 {{{
 Exception RuntimeError: 'maximum recursion depth exceeded while calling a
 Python object' in  ignored
 }}}

 I'm attaching a diff that simply amends the test_user_attrs testcase to
 simulate this. After the other checks, it pulls out the User and then
 builds a dummy query.

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

[Django] #12048: MultiWidget does not define deepcopy

2009-10-17 Thread Django

#12048: MultiWidget does not define __deepcopy__
-+--
 Reporter:  powderflask   |   Owner:  nobody
   Status:  new  |   Milestone:  1.2   
Component:  Forms| Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 django.forms.!MultiWidget defines an instance variable, {{{ widgets }}},
 which is a list of widgets.  However, it does not override the
 __deepcopy__() method in the Widget base class to make a copy of this
 instance variable.  A deepcopy of the widgets is needed when an instance
 when a django Form containing a Field that uses a !MultiWidget is
 instantiated, otherwise all such forms have a reference to the same
 widgets list rather than their own copy.

 The patch is simple - override __deepcopy__() in !MultiWidget to make a
 copy of widgets.  A proposed patch is attached.

 Replicating the problem requires that we extend !MultiWidget, make a
 deepcopy of the widget, then alter one of the widgets in some way.  Here
 is a minimal example that demonstrates the issue - applying the patch
 fixes the issue.

 {{{
 from django import forms
 from django.utils.encoding import StrAndUnicode, force_unicode
 from django.utils.safestring import mark_safe

 #
 ## Simplified ChoiceWithOtherWidget
 ##   original downloaded from: http://www.djangosnippets.org/snippets/863/
 #
 class ChoiceWithOtherWidget(forms.MultiWidget):
 """MultiWidget for use with ChoiceWithOtherField."""
 def __init__(self, choices=[]):
 widgets = [
 forms.RadioSelect(choices=choices),
 forms.TextInput
 ]
 super(ChoiceWithOtherWidget, self).__init__(widgets)

 def _set_choices(self, choices):
 """ When choices are set for this widget, we want to pass those
 along to the Select widget"""
 self.widgets[0].choices = choices
 def _get_choices(self):
 """ The choices for this widget are the Select widget's choices"""
 return self.widgets[0].choices
 choices = property(_get_choices, _set_choices)

 def decompress(self, value):
 if not value:
 return [None, None]
 return value


 #
 ##  Minimal code to reproduces bug
 #
 from copy import deepcopy

 widget1 = ChoiceWithOtherWidget(choices=['A','B','C'])
 widget2 = deepcopy(widget1)
 widget2.choices=['X','Y','Z']

 widget1.choices
 widget2.choices
 }}}

 Here is the output from running the sample code above in a shell before
 the patch was applied:
 {{{
 >>> widget1 = ChoiceWithOtherWidget(choices=['A','B','C'])
 >>> widget2 = deepcopy(widget1)
 >>> widget2.choices=['X','Y','Z']
 >>>
 >>> widget1.choices
 ['X', 'Y', 'Z']
 >>> widget2.choices
 ['X', 'Y', 'Z']
 }}}

 ... and after the patch was applied:

 {{{
 >>> widget1 = ChoiceWithOtherWidget(choices=['A','B','C'])
 >>> widget2 = deepcopy(widget1)
 >>> widget2.choices=['X','Y','Z']
 >>>
 >>> widget1.choices
 ['A', 'B', 'C']
 >>> widget2.choices
 ['X', 'Y', 'Z']
 }}}

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

Re: [Django] #9886: File-like interface for HttpRequest

2009-10-17 Thread Django

#9886: File-like interface for HttpRequest
-+--
  Reporter:  isagalaev   | Owner:  mtredinnick  
Status:  new | Milestone:   
 Component:  HTTP handling   |   Version:  1.0  
Resolution:  |  Keywords:  streaming request
 Stage:  Design decision needed  | Has_patch:  1
Needs_docs:  1   |   Needs_tests:  1
Needs_better_patch:  0   |  
-+--
Changes (by alexkoshelev):

 * cc: alexkoshelev (added)

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

[Changeset] r11629 - in django/branches/releases/1.1.X/django/contrib/gis/gdal: . prototypes tests

2009-10-17 Thread noreply


Author: jbronn
Date: 2009-10-17 12:46:44 -0500 (Sat, 17 Oct 2009)
New Revision: 11629

Modified:
   django/branches/releases/1.1.X/django/contrib/gis/gdal/geometries.py
   django/branches/releases/1.1.X/django/contrib/gis/gdal/prototypes/geom.py
   django/branches/releases/1.1.X/django/contrib/gis/gdal/tests/test_geom.py
Log:
[1.1.X] The `OGRGeometry.coord_dim` property may now be set; implemented a 
work-around for an OGR bug that changed geometries to 3D after transformation.  
Refs #11433.

Backport of r11628 from trunk.


Modified: django/branches/releases/1.1.X/django/contrib/gis/gdal/geometries.py
===
--- django/branches/releases/1.1.X/django/contrib/gis/gdal/geometries.py
2009-10-17 17:32:25 UTC (rev 11628)
+++ django/branches/releases/1.1.X/django/contrib/gis/gdal/geometries.py
2009-10-17 17:46:44 UTC (rev 11629)
@@ -29,7 +29,7 @@
   +proj=longlat +ellps=clrk66 +datum=NAD27 +no_defs
   >>> print mpnt
   MULTIPOINT (-89.30378602485 29.999797886557641,-89.30378602485 
29.999797886557641)
-  
+
   The OGRGeomType class is to make it easy to specify an OGR geometry type:
   >>> from django.contrib.gis.gdal import OGRGeomType
   >>> gt1 = OGRGeomType(3) # Using an integer for the type
@@ -78,7 +78,7 @@
 geom_input = buffer(a2b_hex(geom_input.upper()))
 str_instance = False
 
-# Constructing the geometry, 
+# Constructing the geometry,
 if str_instance:
 # Checking if unicode
 if isinstance(geom_input, unicode):
@@ -130,12 +130,12 @@
 self.__class__ = GEO_CLASSES[self.geom_type.num]
 
 @classmethod
-def from_bbox(cls, bbox):   
+def from_bbox(cls, bbox):
 "Constructs a Polygon from a bounding box (4-tuple)."
 x0, y0, x1, y1 = bbox
 return OGRGeometry( 'POLYGON((%s %s, %s %s, %s %s, %s %s, %s %s))' %  (
 x0, y0, x0, y1, x1, y1, x1, y0, x0, y0) )
- 
+
 def __del__(self):
 "Deletes this Geometry."
 if self._ptr: capi.destroy_geom(self._ptr)
@@ -179,11 +179,18 @@
 "Returns 0 for points, 1 for lines, and 2 for surfaces."
 return capi.get_dims(self.ptr)
 
-@property
-def coord_dim(self):
+def _get_coord_dim(self):
 "Returns the coordinate dimension of the Geometry."
-return capi.get_coord_dims(self.ptr)
+return capi.get_coord_dim(self.ptr)
 
+def _set_coord_dim(self, dim):
+"Sets the coordinate dimension of this Geometry."
+if not dim in (2, 3):
+raise ValueError('Geometry dimension must be either 2 or 3')
+capi.set_coord_dim(self.ptr, dim)
+
+coord_dim = property(_get_coord_dim, _set_coord_dim)
+
 @property
 def geom_count(self):
 "The number of elements in this Geometry."
@@ -237,7 +244,7 @@
 return self.envelope.tuple
 
  SpatialReference-related Properties 
-
+
 # The SRS property
 def _get_srs(self):
 "Returns the Spatial Reference for this Geometry."
@@ -298,7 +305,7 @@
 Returns the GeoJSON representation of this Geometry (requires
 GDAL 1.5+).
 """
-if GEOJSON: 
+if GEOJSON:
 return capi.to_json(self.ptr)
 else:
 raise NotImplementedError('GeoJSON output only supported on GDAL 
1.5+.')
@@ -335,7 +342,7 @@
 def wkt(self):
 "Returns the WKT representation of the Geometry."
 return capi.to_wkt(self.ptr, byref(c_char_p()))
-
+
  Geometry Methods 
 def clone(self):
 "Clones this OGR Geometry."
@@ -363,6 +370,16 @@
 klone = self.clone()
 klone.transform(coord_trans)
 return klone
+
+# Have to get the coordinate dimension of the original geometry
+# so it can be used to reset the transformed geometry's dimension
+# afterwards.  This is done because of GDAL bug (in versions prior
+# to 1.7) that turns geometries 3D after transformation, see:
+#  http://trac.osgeo.org/gdal/changeset/17792
+orig_dim = self.coord_dim
+
+# Depending on the input type, use the appropriate OGR routine
+# to perform the transformation.
 if isinstance(coord_trans, CoordTransform):
 capi.geom_transform(self.ptr, coord_trans.ptr)
 elif isinstance(coord_trans, SpatialReference):
@@ -373,6 +390,10 @@
 else:
 raise TypeError('Transform only accepts CoordTransform, 
SpatialReference, string, and integer objects.')
 
+# Setting with original dimension, see comment above.
+if self.coord_dim != orig_dim:
+self.coord_dim = orig_dim
+
 def transform_to(self, srs):
 "For backwards-compatibility."
 self.transform(srs)
@@ -391,7 +412,7 @@
 def intersects(self, other):
 "Returns True if this geometry intersects with the other."

[Changeset] r11628 - in django/trunk/django/contrib/gis/gdal: . prototypes tests

2009-10-17 Thread noreply


Author: jbronn
Date: 2009-10-17 12:32:25 -0500 (Sat, 17 Oct 2009)
New Revision: 11628

Modified:
   django/trunk/django/contrib/gis/gdal/geometries.py
   django/trunk/django/contrib/gis/gdal/prototypes/geom.py
   django/trunk/django/contrib/gis/gdal/tests/test_geom.py
Log:
The `OGRGeometry.coord_dim` property may now be set; implemented a work-around 
for an OGR bug that changed geometries to 3D after transformation.  Refs #11433.


Modified: django/trunk/django/contrib/gis/gdal/geometries.py
===
--- django/trunk/django/contrib/gis/gdal/geometries.py  2009-10-15 20:25:20 UTC 
(rev 11627)
+++ django/trunk/django/contrib/gis/gdal/geometries.py  2009-10-17 17:32:25 UTC 
(rev 11628)
@@ -29,7 +29,7 @@
   +proj=longlat +ellps=clrk66 +datum=NAD27 +no_defs
   >>> print mpnt
   MULTIPOINT (-89.30378602485 29.999797886557641,-89.30378602485 
29.999797886557641)
-  
+
   The OGRGeomType class is to make it easy to specify an OGR geometry type:
   >>> from django.contrib.gis.gdal import OGRGeomType
   >>> gt1 = OGRGeomType(3) # Using an integer for the type
@@ -78,7 +78,7 @@
 geom_input = buffer(a2b_hex(geom_input.upper()))
 str_instance = False
 
-# Constructing the geometry, 
+# Constructing the geometry,
 if str_instance:
 # Checking if unicode
 if isinstance(geom_input, unicode):
@@ -130,12 +130,12 @@
 self.__class__ = GEO_CLASSES[self.geom_type.num]
 
 @classmethod
-def from_bbox(cls, bbox):   
+def from_bbox(cls, bbox):
 "Constructs a Polygon from a bounding box (4-tuple)."
 x0, y0, x1, y1 = bbox
 return OGRGeometry( 'POLYGON((%s %s, %s %s, %s %s, %s %s, %s %s))' %  (
 x0, y0, x0, y1, x1, y1, x1, y0, x0, y0) )
- 
+
 def __del__(self):
 "Deletes this Geometry."
 if self._ptr: capi.destroy_geom(self._ptr)
@@ -179,11 +179,18 @@
 "Returns 0 for points, 1 for lines, and 2 for surfaces."
 return capi.get_dims(self.ptr)
 
-@property
-def coord_dim(self):
+def _get_coord_dim(self):
 "Returns the coordinate dimension of the Geometry."
-return capi.get_coord_dims(self.ptr)
+return capi.get_coord_dim(self.ptr)
 
+def _set_coord_dim(self, dim):
+"Sets the coordinate dimension of this Geometry."
+if not dim in (2, 3):
+raise ValueError('Geometry dimension must be either 2 or 3')
+capi.set_coord_dim(self.ptr, dim)
+
+coord_dim = property(_get_coord_dim, _set_coord_dim)
+
 @property
 def geom_count(self):
 "The number of elements in this Geometry."
@@ -237,7 +244,7 @@
 return self.envelope.tuple
 
  SpatialReference-related Properties 
-
+
 # The SRS property
 def _get_srs(self):
 "Returns the Spatial Reference for this Geometry."
@@ -298,7 +305,7 @@
 Returns the GeoJSON representation of this Geometry (requires
 GDAL 1.5+).
 """
-if GEOJSON: 
+if GEOJSON:
 return capi.to_json(self.ptr)
 else:
 raise NotImplementedError('GeoJSON output only supported on GDAL 
1.5+.')
@@ -335,7 +342,7 @@
 def wkt(self):
 "Returns the WKT representation of the Geometry."
 return capi.to_wkt(self.ptr, byref(c_char_p()))
-
+
  Geometry Methods 
 def clone(self):
 "Clones this OGR Geometry."
@@ -363,6 +370,16 @@
 klone = self.clone()
 klone.transform(coord_trans)
 return klone
+
+# Have to get the coordinate dimension of the original geometry
+# so it can be used to reset the transformed geometry's dimension
+# afterwards.  This is done because of GDAL bug (in versions prior
+# to 1.7) that turns geometries 3D after transformation, see:
+#  http://trac.osgeo.org/gdal/changeset/17792
+orig_dim = self.coord_dim
+
+# Depending on the input type, use the appropriate OGR routine
+# to perform the transformation.
 if isinstance(coord_trans, CoordTransform):
 capi.geom_transform(self.ptr, coord_trans.ptr)
 elif isinstance(coord_trans, SpatialReference):
@@ -373,6 +390,10 @@
 else:
 raise TypeError('Transform only accepts CoordTransform, 
SpatialReference, string, and integer objects.')
 
+# Setting with original dimension, see comment above.
+if self.coord_dim != orig_dim:
+self.coord_dim = orig_dim
+
 def transform_to(self, srs):
 "For backwards-compatibility."
 self.transform(srs)
@@ -391,7 +412,7 @@
 def intersects(self, other):
 "Returns True if this geometry intersects with the other."
 return self._topology(capi.ogr_intersects, other)
-
+
 def equals(self, other):
 "Returns True if this geometry is equivalent to the other."

Re: [Django] #12012: Integration with the Python standard library logging module

2009-10-17 Thread Django

#12012: Integration with the Python standard library logging module
-+--
  Reporter:  simon   | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Comment (by vsajip):

 I've proposed the detail of a dictionary schema for Python logging
 configuration on python-dev in [http://mail.python.org/pipermail/python-
 dev/2009-October/093062.html this post]. An example configuration in YAML
 format would be:
 {{{
 formatters:
   brief:
 format: '%(levelname)-8s: %(name)-15s: %(message)s'
   precise:
 format: '%(asctime)s %(name)-15s %(levelname)-8s %(message)s'
 datefmt: '%Y-%m-%d %H:%M:%S'
 filters:
   allow_foo:
 name: foo
 handlers:
   console:
 class : logging.StreamHandler
 formatter: brief
 level   : INFO
 stream  : ext://sys.stdout
 filters: [allow_foo]
   file:
 class : logging.handlers.RotatingFileHandler
 formatter: precise
 filename: logconfig.log
 maxBytes: 1024
 backupCount: 3
   debugfile:
 class : logging.FileHandler
 formatter: precise
 filename: logconfig-detail.log
 mode: a
   email:
 class: logging.handlers.SMTPHandler
 mailhost: localhost
 fromaddr: my_app at domain.tld
 toaddrs:
   - support_team at domain.tld
   - dev_team at domain.tld
 subject: Houston, we have a problem.
 loggers:
   foo:
 level : ERROR
 handlers: [debugfile]
   spam:
 level : CRITICAL
 handlers: [debugfile]
 propagate: no
   bar.baz:
 level: WARNING
 root:
   level : DEBUG
   handlers  : [console, file]

 }}}

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

Re: [Django] #12043: Incorrect redirect to http instead of https

2009-10-17 Thread Django

#12043: Incorrect redirect to http instead of https
--+-
  Reporter:  ad...@gpuserver.com  | Owner:  nobody 
Status:  new  | Milestone: 
 Component:  Core framework   |   Version:  1.1
Resolution:   |  Keywords:  redirect http https
 Stage:  Unreviewed   | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by grahamd):

 Django does not need to be modified and WebFaction doesn't need to do
 anything for you.

 Just add yourself to your Apache configuration for your Django site:

   SetEnvIf X-Forwarded-Proto https HTTPS=1

 WebFaction does this as part of their standard one click installers now.
 You obviously created yours back before they added this line to correspond
 to what header they have nginx set.

 You may need to also load Apache module mod_setenvif.

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

Re: [Django] #8611: Reverse for '' not found

2009-10-17 Thread Django

#8611: Reverse for '' not found
-+--
  Reporter:  imbac...@gmail.com  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.1   
Resolution:  fixed   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by Suor):

 Sorry, for reopening. I am using 1.1 release where error message is still
 incorrect.

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

Re: [Django] #11817: Incorrect document structures in django-documentation

2009-10-17 Thread Django

#11817: Incorrect document structures in django-documentation
+---
  Reporter:  axel   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Kellen):

 That line is from
 
http://code.djangoproject.com/browser/django/trunk/django/template/defaulttags.py#L436
 but I don't see the text anywhere in the normal documentation.

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

Re: [Django] #12049: New LazyObject-wrapped User breaks queries in template tags

Re: [Django] #11735: Wrong documentation for changing Model formsets queryset

Re: [Django] #12049: New LazyObject-wrapped User breaks queries in template tags

Re: [Django] #12049: New LazyObject-wrapped User breaks queries in template tags

[Django] #12049: New LazyObject-wrapped User breaks queries in template tags

[Django] #12048: MultiWidget does not define deepcopy

Re: [Django] #9886: File-like interface for HttpRequest

[Changeset] r11629 - in django/branches/releases/1.1.X/django/contrib/gis/gdal: . prototypes tests

[Changeset] r11628 - in django/trunk/django/contrib/gis/gdal: . prototypes tests

Re: [Django] #12012: Integration with the Python standard library logging module

Re: [Django] #12043: Incorrect redirect to http instead of https

Re: [Django] #8611: Reverse for '' not found

Re: [Django] #11817: Incorrect document structures in django-documentation

13 matches

Site Navigation

Mail list logo

Footer information