Re: [Django] #10449: Bug: HTML accents not escaped out when using newforms

[Django]

#10449: Bug: HTML accents not escaped out when using newforms
---+
  Reporter:  tipan | Owner:  nobody   
Status:  reopened  | Milestone:   
 Component:  Internationalization  |   Version:  1.0  
Resolution:|  Keywords:  accents, newforms
 Stage:  Accepted  | Has_patch:  0
Needs_docs:  1 |   Needs_tests:  1
Needs_better_patch:  0 |  
---+
Comment (by arien):

 Malcolm, I'm not fighting you. I disagree with your solution, that is all.

 If and when anybody wants to have a stab at this, it may be nice to know
 that changing the translation functions so that they return `SafeData`
 fixes this particular issue, while passing all but a few tests in Django's
 suite.  The tests that don't pass (in `django/contrib/auth/tests` and
 `tests/regressiontests/admin_views`) assume that translated strings will
 be escaped on output.  (See
 `django.contrib.auth.tests.PasswordResetTest.test_email_not_found` for an
 example, escaping single quotes.)

 I think I'm done with this particular ticket. *sigh*

-- 
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] r10063 - in django/trunk: django/contrib/auth django/contrib/auth/tests docs/howto docs/ref docs/topics

[noreply]

Author: gwilson
Date: 2009-03-15 00:54:28 -0500 (Sun, 15 Mar 2009)
New Revision: 10063

Added:
   django/trunk/django/contrib/auth/tests/remote_user.py
   django/trunk/docs/howto/auth-remote-user.txt
   django/trunk/docs/ref/authbackends.txt
Modified:
   django/trunk/django/contrib/auth/backends.py
   django/trunk/django/contrib/auth/middleware.py
   django/trunk/django/contrib/auth/tests/__init__.py
   django/trunk/docs/howto/index.txt
   django/trunk/docs/ref/index.txt
   django/trunk/docs/ref/request-response.txt
   django/trunk/docs/topics/auth.txt
   django/trunk/docs/topics/index.txt
Log:
Fixed #689 -- Added a middleware and authentication backend to contrib.auth for 
supporting external authentication solutions.  Thanks to all who contributed to 
this patch, including Ian Holsman, garthk, Koen Biermans, Marc Fargas, ekarulf, 
and Ramiro Morales.

Modified: django/trunk/django/contrib/auth/backends.py
===
--- django/trunk/django/contrib/auth/backends.py2009-03-15 05:05:26 UTC 
(rev 10062)
+++ django/trunk/django/contrib/auth/backends.py2009-03-15 05:54:28 UTC 
(rev 10063)
@@ -78,3 +78,64 @@
 return User.objects.get(pk=user_id)
 except User.DoesNotExist:
 return None
+
+
+class RemoteUserBackend(ModelBackend):
+"""
+This backend is to be used in conjunction with the ``RemoteUserMiddleware``
+found in the middleware module of this package, and is used when the server
+is handling authentication outside of Django.
+
+By default, the ``authenticate`` method creates ``User`` objects for
+usernames that don't already exist in the database.  Subclasses can disable
+this behavior by setting the ``create_unknown_user`` attribute to
+``False``.
+"""
+
+# Create a User object if not already in the database?
+create_unknown_user = True
+
+def authenticate(self, remote_user):
+"""
+The username passed as ``remote_user`` is considered trusted.  This
+method simply returns the ``User`` object with the given username,
+creating a new ``User`` object if ``create_unknown_user`` is ``True``.
+
+Returns None if ``create_unknown_user`` is ``False`` and a ``User``
+object with the given username is not found in the database.
+"""
+if not remote_user:
+return
+user = None
+username = self.clean_username(remote_user)
+
+# Note that this could be accomplished in one try-except clause, but
+# instead we use get_or_create when creating unknown users since it has
+# built-in safeguards for multiple threads.
+if self.create_unknown_user:
+user, created = User.objects.get_or_create(username=username)
+if created:
+user = self.configure_user(user)
+else:
+try:
+user = User.objects.get(username=username)
+except User.DoesNotExist:
+pass
+return user
+
+def clean_username(self, username):
+"""
+Performs any cleaning on the "username" prior to using it to get or
+create the user object.  Returns the cleaned username.
+
+By default, returns the username unchanged.
+"""
+return username
+
+def configure_user(self, user):
+"""
+Configures a user after creation and returns the updated user.
+
+By default, returns the user unmodified.
+"""
+return user

Modified: django/trunk/django/contrib/auth/middleware.py
===
--- django/trunk/django/contrib/auth/middleware.py  2009-03-15 05:05:26 UTC 
(rev 10062)
+++ django/trunk/django/contrib/auth/middleware.py  2009-03-15 05:54:28 UTC 
(rev 10063)
@@ -1,3 +1,7 @@
+from django.contrib import auth
+from django.core.exceptions import ImproperlyConfigured
+
+
 class LazyUser(object):
 def __get__(self, request, obj_type=None):
 if not hasattr(request, '_cached_user'):
@@ -5,8 +9,73 @@
 request._cached_user = get_user(request)
 return request._cached_user
 
+
 class AuthenticationMiddleware(object):
 def process_request(self, request):
 assert hasattr(request, 'session'), "The Django authentication 
middleware requires session middleware to be installed. Edit your 
MIDDLEWARE_CLASSES setting to insert 
'django.contrib.sessions.middleware.SessionMiddleware'."
 request.__class__.user = LazyUser()
 return None
+
+
+class RemoteUserMiddleware(object):
+"""
+Middleware for utilizing web-server-provided authentication.
+
+If request.user is not authenticated, then this middleware attempts to
+authenticate the username passed in the ``REMOTE_USER`` request header.
+If authentication is successful, the user is automatically logged in to
+persist the user in the session.
+
+ 

[Changeset] r10062 - in django/trunk: django/forms docs/topics/forms tests/modeltests/model_forms

[noreply]

Author: russellm
Date: 2009-03-15 00:05:26 -0500 (Sun, 15 Mar 2009)
New Revision: 10062

Modified:
   django/trunk/django/forms/models.py
   django/trunk/docs/topics/forms/modelforms.txt
   django/trunk/tests/modeltests/model_forms/models.py
Log:
Fixed #8164 -- Fields on a ModelForm are now ordered in the order specified in 
the fields attribute of the ModelForm's Meta class. Thanks to Alex Gaynor for 
the patch.

Modified: django/trunk/django/forms/models.py
===
--- django/trunk/django/forms/models.py 2009-03-15 03:46:26 UTC (rev 10061)
+++ django/trunk/django/forms/models.py 2009-03-15 05:05:26 UTC (rev 10062)
@@ -149,7 +149,6 @@
 fields will be excluded from the returned fields, even if they are listed
 in the ``fields`` argument.
 """
-# TODO: if fields is provided, it would be nice to return fields in that 
order
 field_list = []
 opts = model._meta
 for f in opts.fields + opts.many_to_many:
@@ -162,7 +161,10 @@
 formfield = formfield_callback(f)
 if formfield:
 field_list.append((f.name, formfield))
-return SortedDict(field_list)
+field_dict = SortedDict(field_list)
+if fields:
+field_dict = SortedDict([(f, field_dict[f]) for f in fields if (not 
exclude) or (exclude and f not in exclude)])
+return field_dict
 
 class ModelFormOptions(object):
 def __init__(self, options=None):

Modified: django/trunk/docs/topics/forms/modelforms.txt
===
--- django/trunk/docs/topics/forms/modelforms.txt   2009-03-15 03:46:26 UTC 
(rev 10061)
+++ django/trunk/docs/topics/forms/modelforms.txt   2009-03-15 05:05:26 UTC 
(rev 10062)
@@ -259,7 +259,8 @@
 
 2. Use the ``fields`` attribute of the ``ModelForm``'s inner ``Meta``
class.  This attribute, if given, should be a list of field names
-   to include in the form.
+   to include in the form. The form will render the fields in the same
+   order they are specified in the ``fields`` attribute.
 
 3. Use the ``exclude`` attribute of the ``ModelForm``'s inner ``Meta``
class.  This attribute, if given, should be a list of field names
@@ -336,6 +337,31 @@
... class Meta:
... model = Article
 
+Changing the order of fields
+
+
+By default, a ``ModelForm`` will render fields in the same order that
+they are defined on the model, with ``ManyToManyField``s appearing last.
+If you want to change the order in which fields are rendered, you can
+use the ``fields`` attribute on the ``Meta`` class.
+
+The ``fields`` attribute defines the subset of model fields that will be
+rendered, and the order in which they will be rendered. For example given this
+model::
+
+class Book(models.Model):
+author = models.ForeignKey(Author)
+title = models.CharField(max_length=100)
+
+the ``author`` field would be rendered first. If we wanted the title field
+to be rendered first, we could specify the following ``ModelForm``::
+
+>>> class BookForm(ModelForm):
+... class Meta:
+... model = Book
+... fields = ['title', 'author']
+
+
 Overriding the clean() method
 -
 

Modified: django/trunk/tests/modeltests/model_forms/models.py
===
--- django/trunk/tests/modeltests/model_forms/models.py 2009-03-15 03:46:26 UTC 
(rev 10061)
+++ django/trunk/tests/modeltests/model_forms/models.py 2009-03-15 05:05:26 UTC 
(rev 10062)
@@ -105,12 +105,12 @@
 # If PIL is not available, ImageField tests are omitted.
 from PIL import Image, _imaging
 test_images = True
-
+
 class ImageFile(models.Model):
 def custom_upload_path(self, filename):
 path = self.path or 'tests'
 return '%s/%s' % (path, filename)
-
+
 description = models.CharField(max_length=20)
 image = models.ImageField(storage=temp_storage, 
upload_to=custom_upload_path,
   width_field='width', height_field='height')
@@ -120,15 +120,15 @@
 
 def __unicode__(self):
 return self.description
-
+
 class OptionalImageFile(models.Model):
 def custom_upload_path(self, filename):
 path = self.path or 'tests'
 return '%s/%s' % (path, filename)
-
+
 description = models.CharField(max_length=20)
 image = models.ImageField(storage=temp_storage, 
upload_to=custom_upload_path,
-  width_field='width', height_field='height', 
+  width_field='width', height_field='height',
   blank=True, null=True)
 width = models.IntegerField(editable=False, null=True)
 height = models.IntegerField(editable=False, null=True)
@@ -138,7 +138,7 @@
 return self.description
 ex

Re: [Django] #10506: Automatically use correct auto-manager class for inherited models

[Django]

#10506: Automatically use correct auto-manager class for inherited models
---+
  Reporter:  mtredinnick   | Owner:  mtredinnick
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * summary:  Understand correct auto-manager class for inherited models =>
  Automatically use correct auto-manager class
  for inherited models
  * 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] #10506: Understand correct auto-manager class for inherited models

[Django]

#10506: Understand correct auto-manager class for inherited models
--+-
 Reporter:  mtredinnick   |   Owner:  mtredinnick
   Status:  new   |   Milestone:  1.1
Component:  Database layer (models, ORM)  | Version:  SVN
 Keywords:|   Stage:  Unreviewed 
Has_patch:  0 |  
--+-
 When creating a subclass of a model with a default manager that has
 `use_for_related_fields = True`, and if the subclass has no explicit
 manager set, we should use the class of the parent's manager. This is
 consistent with every other time we create an automatic manager (in fact,
 the docs added in r10057 hint that we already do this, but it's not quite
 true for subclasses yet).

 For multiple base classes, we walk them all and choose the most derived
 manager satisfying this constraint. It should subclass all the other
 managers that also do. If there is no such manager (e.g. two different
 managers subclassing `django.db.models.Manager`), we raise an error and
 the user has to specify the default manager themselves. This is because
 there would be no way to ensure that an appropriate `get_query_set()`
 method id used

 Using MRO to determine the class type is wrong, since a model that
 inherits from both an ordinary model and a gis model, in that order, needs
 a !GeoManager (which already subclasses Manager, so we're fine).

 When this is done, there's a "TODO" in the gis tests that can be removed,
 too (in a child model).

 I'll get to this before 1.1, but I had to fix the first parts of this as
 part of some other yak-shaving and don't want to get distracted on this
 yet.

-- 
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] r10061 - django/branches/releases/1.0.X/docs/topics/db

[noreply]

Author: mtredinnick
Date: 2009-03-14 22:46:26 -0500 (Sat, 14 Mar 2009)
New Revision: 10061

Modified:
   django/branches/releases/1.0.X/docs/topics/db/managers.txt
Log:
[1.0.X] Documented patterns for adding extra managers to model subclasses.

This seems to have been a source of confusion, so now we have some explicit
examples. Fixed #9676.

Backport of r10058 from trunk.

Modified: django/branches/releases/1.0.X/docs/topics/db/managers.txt
===
--- django/branches/releases/1.0.X/docs/topics/db/managers.txt  2009-03-15 
03:45:56 UTC (rev 10060)
+++ django/branches/releases/1.0.X/docs/topics/db/managers.txt  2009-03-15 
03:46:26 UTC (rev 10061)
@@ -217,7 +217,7 @@
class, using Python's normal name resolution order (names on the child
class override all others; then come names on the first parent class,
and so on). Abstract base classes are designed to capture information
-   and behaviour that is common to their child classes. Defining common
+   and behavior that is common to their child classes. Defining common
managers is an appropriate part of this common information.
 
 3. The default manager on a class is either the first manager declared on
@@ -226,6 +226,54 @@
manager is explicitly declared, Django's normal default manager is
used.
 
+These rules provide the necessary flexibility if you want to install a
+collection of custom managers on a group of models, via an abstract base
+class, but still customize the default manager. For example, suppose you have
+this base class::
+
+class AbstractBase(models.Model):
+...
+objects = CustomerManager()
+
+class Meta:
+abstract = True
+
+If you use this directly in a subclass, ``objects`` will be the default
+manager if you declare no managers in the base class::
+
+class ChildA(AbstractBase):
+...
+# This class has CustomManager as the default manager.
+
+If you want to inherit from ``AbstractBase``, but provide a different default
+manager, you can provide the default manager on the child class::
+
+class ChildB(AbstractBase):
+...
+# An explicit default manager.
+default_manager = OtherManager()
+
+Here, ``default_manager`` is the default. The ``objects`` manager is
+still available, since it's inherited. It just isn't used as the default.
+
+Finally for this example, suppose you want to add extra managers to the child
+class, but still use the default from ``AbstractBase``. You can't add the new
+manager directly in the child class, as that would override the default and 
you would
+have to also explicitly include all the managers from the abstract base class.
+The solution is to put the extra managers in another base class and introduce
+it into the inheritance hierarchy *after* the defaults::
+
+class ExtraManager(models.Model):
+extra_manager = OtherManager()
+
+class Meta:
+abstract = True
+
+class ChildC(AbstractBase, ExtraManager):
+...
+# Default manager is CustomManager, but OtherManager is
+# also available via the "extra_manager" attribute.
+
 .. _manager-types:
 
 Controlling Automatic Manager Types


--~--~-~--~~~---~--~~
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] r10060 - django/branches/releases/1.0.X/docs/topics/db

[noreply]

Author: mtredinnick
Date: 2009-03-14 22:45:56 -0500 (Sat, 14 Mar 2009)
New Revision: 10060

Modified:
   django/branches/releases/1.0.X/docs/topics/db/managers.txt
Log:
[1.0.X] Clarified and expanded documentation for Manager.use_for_related_fields.

This is for Manager subclasses that are default managers, but only
sometimes.  The general rule is: "don't use it." If you really need it,
read the instructions.

Backport of r10057 from trunk.

Modified: django/branches/releases/1.0.X/docs/topics/db/managers.txt
===
--- django/branches/releases/1.0.X/docs/topics/db/managers.txt  2009-03-15 
03:45:32 UTC (rev 10059)
+++ django/branches/releases/1.0.X/docs/topics/db/managers.txt  2009-03-15 
03:45:56 UTC (rev 10060)
@@ -16,6 +16,8 @@
 document specifically touches on model options that customize ``Manager``
 behavior.
 
+.. _manager-names:
+
 Manager names
 =
 
@@ -175,20 +177,23 @@
 avoid a situation where overriding of ``get_query_set()`` results in
 an inability to retrieve objects you'd like to work with.
 
+.. _managers-for-related-objects:
+
 Using managers for related object access
 
 
-By default, Django uses a "bare" (i.e. default) manager when accessing related
-objects (i.e. ``choice.poll``). If this default isn't appropriate for your
-default manager, you can force Django to use a custom manager for related 
object
-attributes by giving it a ``use_for_related_fields`` property::
+By default, Django uses an instance of a "plain" manager class when accessing
+related objects (i.e. ``choice.poll``), not the default manager on the related
+object. This is because Django needs to be able to retrieve the related
+object, even if it would otherwise be filtered out (and hence be inaccessible)
+by the default manager.
 
-class MyManager(models.Manager)::
-use_for_related_fields = True
-...
-
+If the normal plain manager class (:class:`django.db.models.Manager`) is not
+appropriate for your circumstances, you can force Django to use the same class
+as the default manager for your model by setting the `use_for_related_fields`
+attribute on the manager class. This is documented fully below_.
 
-...
+.. _below: manager-types_
 
 Custom managers and model inheritance
 -
@@ -221,3 +226,103 @@
manager is explicitly declared, Django's normal default manager is
used.
 
+.. _manager-types:
+
+Controlling Automatic Manager Types
+===
+
+This document has already mentioned a couple of places where Django creates a
+manager class for you: `default managers`_ and the "plain" manager used to
+`access related objects`_. There are other places in the implementation of
+Django where temporary plain managers are needed. Those automatically created
+managers will normally be instances of the :class:`django.db.models.Manager`
+class.
+
+.. _default managers: manager-names_
+.. _access related objects: managers-for-related-objects_
+
+Throughout this section, we will use the term "automatic manager" to mean a
+manager that Django creates for you -- either as a default manager on a model
+with no managers, or to use temporarily when accessing related objects.
+
+Sometimes this default class won't be the right choice. One example is in the
+`django.contrib.gis` application that ships with Django itself. All `gis`
+models must use a special manager class (``GeoManager``) because they need a
+special queryset (``GeoQuerySet``) to be used for interacting with the
+database.  It turns out that models which require a special manager like this
+need to use the same manager class wherever an automatic manager is created.
+
+Django provides a way for custom manager developers to say that their manager
+class should be used for automatic managers whenever it is the default manager
+on a model. This is done by setting the ``use_for_related_fields`` attribute on
+the manager class::
+
+class MyManager(models.Manager):
+use_for_related_fields = True
+
+...
+
+If this attribute is set on the *default* manager for a model (only the
+default manager is considered in these situations), Django will use that class
+whenever it needs to automatically create a manager for the class.  Otherwise,
+it will use :class:`django.db.models.Manager`.
+
+.. admonition:: Historical Note
+
+Given the purpose for which it's used, the name of this attribute
+(``use_for_related_fields``) might seem a little odd. Originally, the
+attribute only controlled the type of manager used for related field
+access, which is where the name came from. As it became clear the concept
+was more broadly useful, the name hasn't been changed. This is primarily
+so that existing code will :ref:`continue to work ` in
+future Django versions.
+
+Writing Correct Managers For Use In Automatic Manager Instance

[Changeset] r10059 - in django/branches/releases/1.0.X: django/db/models tests/regressiontests tests/regressiontests/custom_managers_regress

[noreply]

Author: mtredinnick
Date: 2009-03-14 22:45:32 -0500 (Sat, 14 Mar 2009)
New Revision: 10059

Added:
   django/branches/releases/1.0.X/tests/regressiontests/custom_managers_regress/
   
django/branches/releases/1.0.X/tests/regressiontests/custom_managers_regress/__init__.py
   
django/branches/releases/1.0.X/tests/regressiontests/custom_managers_regress/models.py
Modified:
   django/branches/releases/1.0.X/django/db/models/base.py
   django/branches/releases/1.0.X/django/db/models/manager.py
Log:
[1.0.X] Use plain model.Manager, or suitable proxy, for model saving.

We can't use the default manager in Model.save_base(), since we need to
retrieve existing objects which might be filtered out by that manager. We now
always use a plain Manager instance at that point (or something that can
replace it, such as a GeoManager), making all existing rows in the
database visible to the saving code.

The logic for detecting a "suitable replacement" plain base is the same as for
related fields: if the use_for_related_fields is set on the manager subclass,
we can use it. The general requirement here is that we want a base class that
returns the appropriate QuerySet subclass, but does not restrict the rows
returned.

Fixed #8990, #9527.

Refs #2698 (which is not fixed by this change, but it's the first part of a
larger change to fix that bug.)

Backport of r10056 from trunk.

Modified: django/branches/releases/1.0.X/django/db/models/base.py
===
--- django/branches/releases/1.0.X/django/db/models/base.py 2009-03-15 
03:42:31 UTC (rev 10058)
+++ django/branches/releases/1.0.X/django/db/models/base.py 2009-03-15 
03:45:32 UTC (rev 10059)
@@ -69,6 +69,7 @@
 
 if getattr(new_class, '_default_manager', None):
 new_class._default_manager = None
+new_class._base_manager = None
 
 # Bail out early if we have already created this class.
 m = get_model(new_class._meta.app_label, name, False)
@@ -369,7 +370,7 @@
 pk_val = self._get_pk_val(meta)
 pk_set = pk_val is not None
 record_exists = True
-manager = cls._default_manager
+manager = cls._base_manager
 if pk_set:
 # Determine whether a record with the primary key already exists.
 if (force_update or (not force_insert and

Modified: django/branches/releases/1.0.X/django/db/models/manager.py
===
--- django/branches/releases/1.0.X/django/db/models/manager.py  2009-03-15 
03:42:31 UTC (rev 10058)
+++ django/branches/releases/1.0.X/django/db/models/manager.py  2009-03-15 
03:45:32 UTC (rev 10059)
@@ -5,8 +5,16 @@
 from django.db.models.fields import FieldDoesNotExist
 
 def ensure_default_manager(sender, **kwargs):
+"""
+Ensures that a Model subclass contains a default manager  and sets the
+_default_manager attribute on the class. Also sets up the _base_manager
+points to a plain Manager instance (which could be the same as
+_default_manager if it's not a subclass of Manager).
+"""
 cls = sender
-if not getattr(cls, '_default_manager', None) and not cls._meta.abstract:
+if cls._meta.abstract:
+return
+if not getattr(cls, '_default_manager', None):
 # Create the default manager, if needed.
 try:
 cls._meta.get_field('objects')
@@ -14,6 +22,22 @@
 except FieldDoesNotExist:
 pass
 cls.add_to_class('objects', Manager())
+cls._base_manager = cls.objects
+elif not getattr(cls, '_base_manager', None):
+default_mgr = cls._default_manager.__class__
+if (default_mgr is Manager or
+getattr(default_mgr, "use_for_related_fields", False)):
+cls._base_manager = cls._default_manager
+else:
+# Default manager isn't a plain Manager class, or a suitable
+# replacement, so we walk up the base class hierarchy until we hit
+# something appropriate.
+for base_class in default_mgr.mro()[1:]:
+if (base_class is Manager or
+getattr(base_class, "use_for_related_fields", False)):
+cls.add_to_class('_base_manager', base_class())
+return
+raise AssertionError("Should never get here. Please report a bug, 
including your model and model manager setup.")
 
 signals.class_prepared.connect(ensure_default_manager)
 

Added: 
django/branches/releases/1.0.X/tests/regressiontests/custom_managers_regress/__init__.py
===

Added: 
django/branches/releases/1.0.X/tests/regressiontests/custom_managers_regress/models.py
===
--- 
django/branches/releases/1.0.X/tests/regressiontests/custom_managers_regress/models.py
  (rev 0)

[Changeset] r10058 - django/trunk/docs/topics/db

[noreply]

Author: mtredinnick
Date: 2009-03-14 22:42:31 -0500 (Sat, 14 Mar 2009)
New Revision: 10058

Modified:
   django/trunk/docs/topics/db/managers.txt
Log:
Documented patterns for adding extra managers to model subclasses.

This seems to have been a source of confusion, so now we have some explicit
examples. Fixed #9676.

Modified: django/trunk/docs/topics/db/managers.txt
===
--- django/trunk/docs/topics/db/managers.txt2009-03-15 03:42:08 UTC (rev 
10057)
+++ django/trunk/docs/topics/db/managers.txt2009-03-15 03:42:31 UTC (rev 
10058)
@@ -217,7 +217,7 @@
class, using Python's normal name resolution order (names on the child
class override all others; then come names on the first parent class,
and so on). Abstract base classes are designed to capture information
-   and behaviour that is common to their child classes. Defining common
+   and behavior that is common to their child classes. Defining common
managers is an appropriate part of this common information.
 
 3. The default manager on a class is either the first manager declared on
@@ -226,6 +226,54 @@
manager is explicitly declared, Django's normal default manager is
used.
 
+These rules provide the necessary flexibility if you want to install a
+collection of custom managers on a group of models, via an abstract base
+class, but still customize the default manager. For example, suppose you have
+this base class::
+
+class AbstractBase(models.Model):
+...
+objects = CustomerManager()
+
+class Meta:
+abstract = True
+
+If you use this directly in a subclass, ``objects`` will be the default
+manager if you declare no managers in the base class::
+
+class ChildA(AbstractBase):
+...
+# This class has CustomManager as the default manager.
+
+If you want to inherit from ``AbstractBase``, but provide a different default
+manager, you can provide the default manager on the child class::
+
+class ChildB(AbstractBase):
+...
+# An explicit default manager.
+default_manager = OtherManager()
+
+Here, ``default_manager`` is the default. The ``objects`` manager is
+still available, since it's inherited. It just isn't used as the default.
+
+Finally for this example, suppose you want to add extra managers to the child
+class, but still use the default from ``AbstractBase``. You can't add the new
+manager directly in the child class, as that would override the default and 
you would
+have to also explicitly include all the managers from the abstract base class.
+The solution is to put the extra managers in another base class and introduce
+it into the inheritance hierarchy *after* the defaults::
+
+class ExtraManager(models.Model):
+extra_manager = OtherManager()
+
+class Meta:
+abstract = True
+
+class ChildC(AbstractBase, ExtraManager):
+...
+# Default manager is CustomManager, but OtherManager is
+# also available via the "extra_manager" attribute.
+
 .. _manager-types:
 
 Controlling Automatic Manager Types


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

[noreply]

Author: mtredinnick
Date: 2009-03-14 22:42:08 -0500 (Sat, 14 Mar 2009)
New Revision: 10057

Modified:
   django/trunk/docs/topics/db/managers.txt
Log:
Clarified and expanded documentation for Manager.use_for_related_fields.

This is for Manager subclasses that are default managers, but only
sometimes.  The general rule is: "don't use it." If you really need it,
read the instructions.

Modified: django/trunk/docs/topics/db/managers.txt
===
--- django/trunk/docs/topics/db/managers.txt2009-03-15 03:41:33 UTC (rev 
10056)
+++ django/trunk/docs/topics/db/managers.txt2009-03-15 03:42:08 UTC (rev 
10057)
@@ -16,6 +16,8 @@
 document specifically touches on model options that customize ``Manager``
 behavior.
 
+.. _manager-names:
+
 Manager names
 =
 
@@ -175,20 +177,23 @@
 avoid a situation where overriding of ``get_query_set()`` results in
 an inability to retrieve objects you'd like to work with.
 
+.. _managers-for-related-objects:
+
 Using managers for related object access
 
 
-By default, Django uses a "bare" (i.e. default) manager when accessing related
-objects (i.e. ``choice.poll``). If this default isn't appropriate for your
-default manager, you can force Django to use a custom manager for related 
object
-attributes by giving it a ``use_for_related_fields`` property::
+By default, Django uses an instance of a "plain" manager class when accessing
+related objects (i.e. ``choice.poll``), not the default manager on the related
+object. This is because Django needs to be able to retrieve the related
+object, even if it would otherwise be filtered out (and hence be inaccessible)
+by the default manager.
 
-class MyManager(models.Manager)::
-use_for_related_fields = True
-...
-
+If the normal plain manager class (:class:`django.db.models.Manager`) is not
+appropriate for your circumstances, you can force Django to use the same class
+as the default manager for your model by setting the `use_for_related_fields`
+attribute on the manager class. This is documented fully below_.
 
-...
+.. _below: manager-types_
 
 Custom managers and model inheritance
 -
@@ -221,3 +226,103 @@
manager is explicitly declared, Django's normal default manager is
used.
 
+.. _manager-types:
+
+Controlling Automatic Manager Types
+===
+
+This document has already mentioned a couple of places where Django creates a
+manager class for you: `default managers`_ and the "plain" manager used to
+`access related objects`_. There are other places in the implementation of
+Django where temporary plain managers are needed. Those automatically created
+managers will normally be instances of the :class:`django.db.models.Manager`
+class.
+
+.. _default managers: manager-names_
+.. _access related objects: managers-for-related-objects_
+
+Throughout this section, we will use the term "automatic manager" to mean a
+manager that Django creates for you -- either as a default manager on a model
+with no managers, or to use temporarily when accessing related objects.
+
+Sometimes this default class won't be the right choice. One example is in the
+`django.contrib.gis` application that ships with Django itself. All `gis`
+models must use a special manager class (``GeoManager``) because they need a
+special queryset (``GeoQuerySet``) to be used for interacting with the
+database.  It turns out that models which require a special manager like this
+need to use the same manager class wherever an automatic manager is created.
+
+Django provides a way for custom manager developers to say that their manager
+class should be used for automatic managers whenever it is the default manager
+on a model. This is done by setting the ``use_for_related_fields`` attribute on
+the manager class::
+
+class MyManager(models.Manager):
+use_for_related_fields = True
+
+...
+
+If this attribute is set on the *default* manager for a model (only the
+default manager is considered in these situations), Django will use that class
+whenever it needs to automatically create a manager for the class.  Otherwise,
+it will use :class:`django.db.models.Manager`.
+
+.. admonition:: Historical Note
+
+Given the purpose for which it's used, the name of this attribute
+(``use_for_related_fields``) might seem a little odd. Originally, the
+attribute only controlled the type of manager used for related field
+access, which is where the name came from. As it became clear the concept
+was more broadly useful, the name hasn't been changed. This is primarily
+so that existing code will :ref:`continue to work ` in
+future Django versions.
+
+Writing Correct Managers For Use In Automatic Manager Instances
+---
+
+As already suggested by the `django.co

[Changeset] r10056 - in django/trunk: django/db/models tests/regressiontests tests/regressiontests/custom_managers_regress

[noreply]

Author: mtredinnick
Date: 2009-03-14 22:41:33 -0500 (Sat, 14 Mar 2009)
New Revision: 10056

Added:
   django/trunk/tests/regressiontests/custom_managers_regress/
   django/trunk/tests/regressiontests/custom_managers_regress/__init__.py
   django/trunk/tests/regressiontests/custom_managers_regress/models.py
Modified:
   django/trunk/django/db/models/base.py
   django/trunk/django/db/models/manager.py
Log:
Use plain model.Manager, or suitable proxy, for model saving.

We can't use the default manager in Model.save_base(), since we need to
retrieve existing objects which might be filtered out by that manager. We now
always use a plain Manager instance at that point (or something that can
replace it, such as a GeoManager), making all existing rows in the
database visible to the saving code.

The logic for detecting a "suitable replacement" plain base is the same as for
related fields: if the use_for_related_fields is set on the manager subclass,
we can use it. The general requirement here is that we want a base class that
returns the appropriate QuerySet subclass, but does not restrict the rows
returned.

Fixed #8990, #9527.

Refs #2698 (which is not fixed by this change, but it's the first part of a
larger change to fix that bug.)

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2009-03-14 22:51:05 UTC (rev 
10055)
+++ django/trunk/django/db/models/base.py   2009-03-15 03:41:33 UTC (rev 
10056)
@@ -69,6 +69,7 @@
 
 if getattr(new_class, '_default_manager', None):
 new_class._default_manager = None
+new_class._base_manager = None
 
 # Bail out early if we have already created this class.
 m = get_model(new_class._meta.app_label, name, False)
@@ -369,7 +370,7 @@
 pk_val = self._get_pk_val(meta)
 pk_set = pk_val is not None
 record_exists = True
-manager = cls._default_manager
+manager = cls._base_manager
 if pk_set:
 # Determine whether a record with the primary key already exists.
 if (force_update or (not force_insert and

Modified: django/trunk/django/db/models/manager.py
===
--- django/trunk/django/db/models/manager.py2009-03-14 22:51:05 UTC (rev 
10055)
+++ django/trunk/django/db/models/manager.py2009-03-15 03:41:33 UTC (rev 
10056)
@@ -5,8 +5,16 @@
 from django.db.models.fields import FieldDoesNotExist
 
 def ensure_default_manager(sender, **kwargs):
+"""
+Ensures that a Model subclass contains a default manager  and sets the
+_default_manager attribute on the class. Also sets up the _base_manager
+points to a plain Manager instance (which could be the same as
+_default_manager if it's not a subclass of Manager).
+"""
 cls = sender
-if not getattr(cls, '_default_manager', None) and not cls._meta.abstract:
+if cls._meta.abstract:
+return
+if not getattr(cls, '_default_manager', None):
 # Create the default manager, if needed.
 try:
 cls._meta.get_field('objects')
@@ -14,6 +22,22 @@
 except FieldDoesNotExist:
 pass
 cls.add_to_class('objects', Manager())
+cls._base_manager = cls.objects
+elif not getattr(cls, '_base_manager', None):
+default_mgr = cls._default_manager.__class__
+if (default_mgr is Manager or
+getattr(default_mgr, "use_for_related_fields", False)):
+cls._base_manager = cls._default_manager
+else:
+# Default manager isn't a plain Manager class, or a suitable
+# replacement, so we walk up the base class hierarchy until we hit
+# something appropriate.
+for base_class in default_mgr.mro()[1:]:
+if (base_class is Manager or
+getattr(base_class, "use_for_related_fields", False)):
+cls.add_to_class('_base_manager', base_class())
+return
+raise AssertionError("Should never get here. Please report a bug, 
including your model and model manager setup.")
 
 signals.class_prepared.connect(ensure_default_manager)
 

Added: django/trunk/tests/regressiontests/custom_managers_regress/__init__.py
===

Added: django/trunk/tests/regressiontests/custom_managers_regress/models.py
===
--- django/trunk/tests/regressiontests/custom_managers_regress/models.py
(rev 0)
+++ django/trunk/tests/regressiontests/custom_managers_regress/models.py
2009-03-15 03:41:33 UTC (rev 10056)
@@ -0,0 +1,38 @@
+"""
+Regression tests for custom manager classes.
+"""
+
+from django.db import models
+
+class RestrictedManager(models.Manager):
+"""
+A manag

Re: [Django] #10505: Integrate django-batchadmin

[Django]

#10505: Integrate django-batchadmin
---+
  Reporter:  jezdez| Owner:  jezdez
Status:  assigned  | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * stage:  Unreviewed => Accepted

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

Re: [Django] #5420: Allow database API users to specify the fields to exclude in a SELECT statement

[Django]

#5420: Allow database API users to specify the fields to exclude in a SELECT
statement
---+
  Reporter:  adrian| Owner:  mtredinnick
Status:  new   | Milestone:  1.1 beta   
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  qs-rf  
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Changes (by anonymous):

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

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #10505: Integrate django-batchadmin

[Django]

#10505: Integrate django-batchadmin
---+
  Reporter:  jezdez| Owner:  jezdez
Status:  assigned  | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by jezdez):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * needs_tests:  => 1
  * owner:  nobody => jezdez
  * needs_docs:  => 1
  * has_patch:  0 => 1

Comment:

 The current code can also be found at Github,
 http://github.com/jezdez/django/commits/admin-actions.

 The code differs from django-batchadmin in multiple ways:

   * Removed dependency on jQuery, added unobtrusive Actions code
   * Replaced select/deselect button with global checkbox (screenshot:
 http://www.quicksnapper.com/jezdez/image/batchadmin)
   * Added ability to directly use callables as actions, also looks in
 model class for action with given name (~list_display)
   * Fixes various bugs in batchadmin regarding non-ASCII data, e.g. i18n

 Needs tests and docs

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #10505: Integrate django-batchadmin

[Django]

#10505: Integrate django-batchadmin
--+-
 Reporter:  jezdez|   Owner:  nobody
   Status:  new   |   Milestone:  1.1   
Component:  django.contrib.admin  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The integration of [http://code.google.com/p/django-batchadmin/ django-
 batchadmin] is one of the [wiki:Version1.1Features "maby" features of 1.1]
 (Admin-02).

 It allows the user to define lists of callables in ModelAdmin classes that
 are used to perform custom actions on a list of objects retrieved from
 checkbox inputs.

-- 
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] #8193: `__import__(mod, {}, {}, [''])` causes double import of modules ('module' and 'module' + '.')

[Django]

#8193: `__import__(mod, {}, {}, [''])` causes double import of modules ('module'
and 'module' + '.')
+---
  Reporter:  i_i| Owner:  jacob 
Status:  new| Milestone:  1.1   
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:  import
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * milestone:  => 1.1

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

Re: [Django] #8193: `__import__(mod, {}, {}, [''])` causes double import of modules ('module' and 'module' + '.')

[Django]

#8193: `__import__(mod, {}, {}, [''])` causes double import of modules ('module'
and 'module' + '.')
+---
  Reporter:  i_i| Owner:  jacob 
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  SVN   
Resolution: |  Keywords:  import
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by brettcannon):

  * owner:  brettcannon => jacob
  * needs_better_patch:  1 => 0

Comment:

 Assigning to jacob as he said he would review the patch when I was
 finished with it.

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

[Changeset] r10055 - django/trunk/docs/topics

[noreply]

Author: adrian
Date: 2009-03-14 17:51:05 -0500 (Sat, 14 Mar 2009)
New Revision: 10055

Modified:
   django/trunk/docs/topics/cache.txt
Log:
Made a bunch of edits to docs/topics/cache.txt, mostly based on stuff from the 
Django Book

Modified: django/trunk/docs/topics/cache.txt
===
--- django/trunk/docs/topics/cache.txt  2009-03-14 05:18:02 UTC (rev 10054)
+++ django/trunk/docs/topics/cache.txt  2009-03-14 22:51:05 UTC (rev 10055)
@@ -50,7 +50,7 @@
 performance; yes, some cache types are faster than others.
 
 Your cache preference goes in the ``CACHE_BACKEND`` setting in your settings
-file. Here's an explanation of all available values for CACHE_BACKEND.
+file. Here's an explanation of all available values for ``CACHE_BACKEND``.
 
 Memcached
 -
@@ -58,18 +58,18 @@
 By far the fastest, most efficient type of cache available to Django, Memcached
 is an entirely memory-based cache framework originally developed to handle high
 loads at LiveJournal.com and subsequently open-sourced by Danga Interactive.
-It's used by sites such as Slashdot and Wikipedia to reduce database access and
+It's used by sites such as Facebook and Wikipedia to reduce database access and
 dramatically increase site performance.
 
 Memcached is available for free at http://danga.com/memcached/ . It runs as a
 daemon and is allotted a specified amount of RAM. All it does is provide an
-interface -- a *lightning-fast* interface -- for adding, retrieving and
-deleting arbitrary data in the cache. All data is stored directly in memory,
-so there's no overhead of database or filesystem usage.
+fast interface for adding, retrieving and deleting arbitrary data in the cache.
+All data is stored directly in memory, so there's no overhead of database or
+filesystem usage.
 
 After installing Memcached itself, you'll need to install the Memcached Python
-bindings. Two versions of this are available. Choose and install *one* of the
-following modules:
+bindings, which are not bundled with Django directly. Two versions of this are
+available. Choose and install *one* of the following modules:
 
 * The fastest available option is a module called ``cmemcache``, available
   at http://gijsbert.org/cmemcache/ .
@@ -93,19 +93,29 @@
 CACHE_BACKEND = 'memcached://127.0.0.1:11211/'
 
 One excellent feature of Memcached is its ability to share cache over multiple
-servers. To take advantage of this feature, include all server addresses in
-``CACHE_BACKEND``, separated by semicolons. In this example, the cache is
-shared over Memcached instances running on IP address 172.19.26.240 and
-172.19.26.242, both on port 11211::
+servers. This means you can run Memcached daemons on multiple machines, and the
+program will treat the group of machines as a *single* cache, without the need
+to duplicate cache values on each machine. To take advantage of this feature,
+include all server addresses in ``CACHE_BACKEND``, separated by semicolons.
 
+In this example, the cache is shared over Memcached instances running on IP
+address 172.19.26.240 and 172.19.26.242, both on port 11211::
+
 CACHE_BACKEND = 'memcached://172.19.26.240:11211;172.19.26.242:11211/'
 
-Memory-based caching has one disadvantage: Because the cached data is stored in
-memory, the data will be lost if your server crashes. Clearly, memory isn't
-intended for permanent data storage, so don't rely on memory-based caching as
-your only data storage. Actually, none of the Django caching backends should be
-used for permanent storage -- they're all intended to be solutions for caching,
-not storage -- but we point this out here because memory-based caching is
+In the following example, the cache is shared over Memcached instances running
+on the IP addresses 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), and
+172.19.26.244 (port 11213)::
+
+CACHE_BACKEND = 
'memcached://172.19.26.240:11211;172.19.26.242:11212;172.19.26.244:11213/'
+
+A final point about Memcached is that memory-based caching has one
+disadvantage: Because the cached data is stored in memory, the data will be
+lost if your server crashes. Clearly, memory isn't intended for permanent data
+storage, so don't rely on memory-based caching as your only data storage.
+Without a doubt, *none* of the Django caching backends should be used for
+permanent storage -- they're all intended to be solutions for caching, not
+storage -- but we point this out here because memory-based caching is
 particularly temporary.
 
 Database caching
@@ -128,6 +138,9 @@
 
 CACHE_BACKEND = 'db://my_cache_table'
 
+The database caching backend uses the same database as specified in your
+settings file. You can't use a different database backend for your cache table.
+
 Database caching works best if you've got a fast, well-indexed database server.
 
 Filesystem caching
@@ -141,8 +154,11 @@
 
 Note that there are three forward slashes toward the beginning of that exam

Re: [Django] #10504: Consistency between HttpResponse* params and render_to_response

[Django]

#10504: Consistency between HttpResponse* params and render_to_response
+---
  Reporter:  bhagany| Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by bhagany):

  * component:  Uncategorized => HTTP handling

-- 
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] #10504: Consistency between HttpResponse* params and render_to_response

[Django]

#10504: Consistency between HttpResponse* params and render_to_response
+---
  Reporter:  bhagany| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by bhagany):

 * cc: brent.hag...@gmail.com (added)
  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * 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] #10482: Unify access to response.context in test client

[Django]

#10482: Unify access to response.context in test client
+---
  Reporter:  julien | Owner:  julien
Status:  new| Milestone:  1.1   
 Component:  Testing framework  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by julien):

  * component:  Uncategorized => Testing framework
  * milestone:  => 1.1

Comment:

 The patch is backward compatible. I hope it makes it into 1.1 as it makes
 testers' life a bit easier. And we want testers' life to be easy ;)

-- 
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] #10504: Consistency between HttpResponse* params and render_to_response

[Django]

#10504: Consistency between HttpResponse* params and render_to_response
---+
 Reporter:  bhagany|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I was just browsing through some of the Django code and came across the
 new-ish (to me) addition of the content_type alias for the mimetype
 parameter to HttpResponse and company.  Wondering about the rationale
 behind this decision, I came across ticket #3526, which may be helpful to
 review in evaluating this ticket.

 In light of this, (and just for consistency) I thought it would probably
 be a good idea to allow render_to_response to pass content_type along to
 HttpResponse.  I'll attach a simple patch that does this.

 Also, this patch will conflict with another patch (#9081) I've submitted
 that has been accepted but not yet committed.  It'll be very easy to
 resolve, but I'm unsure if I should take any special measures about this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #10497: Added 'stat' method to class Storage and FileSystemStorage

[Django]

#10497: Added 'stat' method to class Storage and FileSystemStorage
-+--
  Reporter:  HuCy| Owner:  nobody 
Status:  new | Milestone: 
 Component:  Core framework  |   Version:  1.0
Resolution:  |  Keywords:  storage
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 An HTTP HEAD request would give you some valuable information:

 {{{
 HEAD /testmeplease-us/10mb.bin HTTP/1.1
 Host: s3.amazonaws.com

 HTTP/1.1 200 OK
 Date: Sat, 14 Mar 2009 21:13:16 GMT
 Last-Modified: Fri, 30 Nov 2007 19:36:55 GMT
 ETag: "1a54772a48158d16a8ede6ef10b4ea25"
 Content-Type:
 Content-Length: 10485760
 Server: AmazonS3
 }}}

-- 
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] #9362: InlineAdminForm breaks content_type FK on model

[Django]

#9362: InlineAdminForm breaks content_type FK on model
---+
  Reporter:  carljm| Owner:  brosner
Status:  assigned  | Milestone:  1.1
 Component:  django.contrib.admin  |   Version:  1.0
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by jacob):

  * milestone:  => 1.1

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

Re: [Django] #10460: Better redirect for logout view of Authentication

[Django]

#10460: Better redirect for logout view of Authentication
-+--
  Reporter:  chronos | Owner:  nobody   
  
Status:  new | Milestone:  1.1  
  
 Component:  Authentication  |   Version:  SVN  
  
Resolution:  |  Keywords:  Authentication, login, 
logout, redirect
 Stage:  Accepted| Has_patch:  1
  
Needs_docs:  1   |   Needs_tests:  1
  
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

  * stage:  Design decision needed => Accepted
  * milestone:  => 1.1

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

Re: [Django] #10420: Running gis tests via runtests doesn't work.

[Django]

#10420: Running gis tests via runtests doesn't work.
--+-
  Reporter:  mtredinnick  | Owner:  nobody
Status:  new  | Milestone:  1.1   
 Component:  GIS  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by jacob):

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

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

Re: [Django] #10503: trans noop documentation could be made more clear

[Django]

#10503: trans noop documentation could be made more clear
+---
  Reporter:  liangent   | Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jacob):

  * milestone:  => 1.1

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

Re: [Django] #10497: Added 'stat' method to class Storage and FileSystemStorage

[Django]

#10497: Added 'stat' method to class Storage and FileSystemStorage
-+--
  Reporter:  HuCy| Owner:  nobody 
Status:  new | Milestone: 
 Component:  Core framework  |   Version:  1.0
Resolution:  |  Keywords:  storage
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

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

Comment:

 I'm not sure this is appropriate for a generic backend interface: how
 would you implement `stat()` for S3, for example?

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

Re: [Django] #10503: trans noop documentation could be made more clear

[Django]

#10503: trans noop documentation could be made more clear
+---
  Reporter:  liangent   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

  * summary:  trans noop doesn'twork => trans noop documentation could be
  made more clear
  * component:  Template system => Documentation
  * stage:  Unreviewed => Accepted

Comment:

 This seems to do exactly what it said it would do, it does the variable
 lookup but doesn't translate it.  Perhaps the docs could be made a tiny
 bit more clear.  Changed the title to reflect this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #10494: show query params DoesNotExist from QuerySet.get

[Django]

#10494: show query params DoesNotExist from QuerySet.get
---+
  Reporter:  brondsem  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Design decision needed
  * 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] #9620: Spatial database tables don't work right with AppCache routines

[Django]

#9620: Spatial database tables don't work right with AppCache routines
---+
  Reporter:  jbronn| Owner:  jbronn 
Status:  reopened  | Milestone:  1.1
 Component:  GIS   |   Version:  SVN
Resolution:|  Keywords:  gis models appcache loading
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Changes (by Alex):

  * stage:  Unreviewed => Accepted

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

Re: [Django] #10486: DateTimeFormat in admin doesn't use DATETIME_FORMAT from settings

[Django]

#10486: DateTimeFormat in admin doesn't use DATETIME_FORMAT from settings
---+
  Reporter:  powerfox  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Translations  |   Version:  SVN   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 Duplicate of #2203

-- 
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] #10485: Incomplete file interface for django.core.files.temp.TemporaryFile (Windows only)

[Django]

#10485: Incomplete file interface for django.core.files.temp.TemporaryFile 
(Windows
only)
---+
  Reporter:  tzonghao  | Owner:  tzonghao
Status:  closed| Milestone:  1.0.3   
 Component:  File uploads/storage  |   Version:  1.0 
Resolution:  duplicate |  Keywords:  file, seek, tell
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 Duplicate of #9344, #10047

-- 
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] #10484: Problem logging in to the admin after upgrading django framework.

[Django]

#10484: Problem logging in to the admin after upgrading django framework.
--+-
  Reporter:  Jonas Fogelberg  | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Documentation|   Version:  1.0   
Resolution:  invalid  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by jacob):

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

Comment:

 The `XViewMiddleware` doesn't cause the problem you describe: if it did,
 we'd have a lot more bug reports of this nature.

-- 
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] #10479: Use funtools.partial instead of django.utils.functional.curry

[Django]

#10479: Use funtools.partial instead of django.utils.functional.curry
--+-
  Reporter:  sebastian_noack  | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Uncategorized|   Version:  1.0   
Resolution:  wontfix  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by jacob):

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

Comment:

 `curry` and `partial` do have slightly different binding semantics (mostly
 because `curry` was written far before `partial` made its way into the
 stdlib. And I really doubt that in an actual application the difference is
 noticeable: a difference of 1.5 seconds over a ''million'' calls is
 peanuts in real life. Thus, I can't see a pragmatic reason to make this
 change.

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

Re: [Django] #10493: admin interface doesn't list members of a group

[Django]

#10493: admin interface doesn't list members of a group
-+--
  Reporter:  brondsem| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Authentication  |   Version:  1.0   
Resolution:  wontfix |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

Comment:

 Marking as wonfix, it is now very easy for you to overide the UserAdmin in
 your own code.

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

Re: [Django] #10464: Django Lighttpd Deployment Addition

[Django]

#10464: Django Lighttpd Deployment Addition
-+--
  Reporter:  dgt84   | Owner:  nobody
Status:  new | Milestone:
 Component:  Documentation   |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

  * stage:  Unreviewed => Design decision needed

Comment:

 We can't really expect to document every single quirk of every server
 Django could run on -- at a certain point, people are going to have to
 read the web server documentation, too. Still, this is probably worth
 mentioning somewhere.

-- 
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] #9871: MyModel.object.values('mygeometryfield') doesn't work

[Django]

#9871: MyModel.object.values('mygeometryfield') doesn't work
-+--
  Reporter:  de...@2ni.net   | Owner:  nobody
Status:  new | Milestone:
 Component:  GIS |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

Comment:

 Moving to DDN, it's generally been said that values() is expected to
 return the raw DB values(such as with ForeignKeys).

-- 
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] #10464: Django Lighttpd Deployment Addition

[Django]

#10464: Django Lighttpd Deployment Addition
+---
  Reporter:  dgt84  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jacob):

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

Old description:

> It appears that lighttpd will IGNORE mod_rewrite rules within blocks
> using $HTTP["url"] to match on URLs (a fairly common thing to do to
> redirect to HTTPS for example). In order to do that you must NOT use
> $HTTP["url"], for example using "host" will work:
>
> $HTTP["url"] =~ "/login" {
> url.redirect = "https://../login";
> } else $HTTP["host"] ~= ".*" {
> fastcgi.server = 
> }
>
> I think the docs should be updated to reflect this as it will save others
> horrible headaches.

New description:

 It appears that lighttpd will IGNORE mod_rewrite rules within blocks using
 `$HTTP["url"]` to match on URLs (a fairly common thing to do to redirect
 to HTTPS for example). In order to do that you must NOT use
 `$HTTP["url"]`, for example using "host" will work:

 {{{
 $HTTP["url"] =~ "/login" {
 url.redirect = "https://../login";
 } else $HTTP["host"] ~= ".*" {
 fastcgi.server = 
 }
 }}}

 I think the docs should be updated to reflect this as it will save others
 horrible headaches.

Comment:

 [fixed formatting]

-- 
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] #10461: Annotation and generic relations do not work well together

[Django]

#10461: Annotation and generic relations do not work well together
--+-
  Reporter:  mk   | Owner:   
Status:  new  | Milestone:   
 Component:  ORM aggregation  |   Version:  SVN  
Resolution:   |  Keywords:  generic relations
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by jacob):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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] #10458: next_month and previous_month in views.generic.date_based.archive_month return wrong dates

[Django]

#10458: next_month and previous_month in views.generic.date_based.archive_month
return wrong dates
+---
  Reporter:  alasdair   | Owner:  nobody   
Status:  new| Milestone:  1.1  
 Component:  Generic views  |   Version:  1.0  
Resolution: |  Keywords:  next_month previous_month
 Stage:  Accepted   | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by jacob):

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

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

Re: [Django] #10457: date_based view archive_today should update kwargs for month/day_format

[Django]

#10457: date_based view archive_today should update kwargs for month/day_format
+---
  Reporter:  Dirk Datzert   | Owner:  
nobody
Status:  new| Milestone:

 Component:  Uncategorized  |   Version:  
1.0   
Resolution: |  Keywords:

 Stage:  Design decision needed | Has_patch:  0 

Needs_docs:  0  |   Needs_tests:  0 

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

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Design decision needed
  * 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] #10434: Lighttpd and FastCGi configuration

[Django]

#10434: Lighttpd and FastCGi configuration
+---
  Reporter:  vithlani   | Owner:  nobody

Status:  new| Milestone:  1.1   

 Component:  Documentation  |   Version:  1.0   

Resolution: |  Keywords:  lighttpd, FastCGI, fcgi, 
admin
 Stage:  Accepted   | Has_patch:  0 

Needs_docs:  0  |   Needs_tests:  0 

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

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

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

Re: [Django] #10428: django.utils.dateformat: unknown encoding: gbk2312

[Django]

#10428: django.utils.dateformat: unknown encoding: gbk2312
---+
  Reporter:  anonymous | Owner:  nobody
Status:  closed| Milestone:
 Component:  Internationalization  |   Version:  1.0   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 Duplicate of #10335

-- 
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] #10454: IntegrityError while deleting object with complex constraint

[Django]

#10454: IntegrityError while deleting object with complex constraint
---+
  Reporter:  liangent  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ikelly):

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

Comment:

 Sounds like this is the same issue as #9308.  That ticket has a patch that
 is supposed to resolve it.

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

Re: [Django] #8060: Admin Inlines do not respect user permissions

[Django]

#8060: Admin Inlines do not respect user permissions
+---
  Reporter:  p.patr...@iperbole.bologna.it  | Owner:  dgouldin  
 
Status:  new| Milestone:
 
 Component:  django.contrib.admin   |   Version:  SVN   
 
Resolution: |  Keywords:  inlines 
User authentication
 Stage:  Design decision needed | Has_patch:  0 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

  * milestone:  1.1 beta =>

Comment:

 Something that hasn't even been Accepted is an unlikely candidate for 1.1
 beta, especially when placed there anonymously.

-- 
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] #6523: PostgreSQL 8.3 cannot do text matching on uncast non-text columns

[Django]

#6523: PostgreSQL 8.3 cannot do text matching on uncast non-text columns
---+
  Reporter:  pat.j.ander...@gmail.com  | Owner:  mtredinnick
Status:  closed| Milestone:  1.0
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
Resolution:  fixed |  Keywords:  postgresql 
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 Please open new tickets for new problems.  This one was marked fixed more
 than six months ago, it would have been reopened almost immediately if the
 original fix really did not fix the problem, so you are likely seeing
 something at least slightly different.

 Also, please use WikiFormatting, not html (follow the link that's on every
 page to learn about it) and please please please use the "Preview" button.
 Both of your updates to this ticket are largely unreadable because the
 formatting is so messed up.  It is also not necessary to quote the whole
 comment you are responding to when replying to a comment -- it's all right
 there in the ticket so quoting should be used only in cases where you want
 to identify something specific in a previous comment that you want to
 reply to.

 Finally, you changed the version from SVN to 1.0-beta1 -- surely you are
 not actually running 1.0-beta1 at this point?  If so the first thing to
 try would be updating to the latest 1.0 release which is 1.0.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-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] #10495: django documentation titles contain html tags

[Django]

#10495: django documentation titles contain html tags
--+-
  Reporter:  WoLpH| Owner:  nobody 
Status:  closed   | Milestone: 
 Component:  Django Web site  |   Version:  1.0
Resolution:  duplicate|  Keywords:  documentation html tags
 Stage:  Unreviewed   | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by kmtracey):

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

Comment:

 #8885 already covers this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #8885: HTML markup appearing in title of doc page

[Django]

#8885: HTML markup appearing in title of doc page
--+-
  Reporter:  gkelly   | Owner:  nobody
Status:  reopened | Milestone:
 Component:  Django Web site  |   Version:  1.0   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by kmtracey):

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

Comment:

 Meant to close the other one, not this one.

-- 
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] #8885: HTML markup appearing in title of doc page

[Django]

#8885: HTML markup appearing in title of doc page
--+-
  Reporter:  gkelly   | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Django Web site  |   Version:  1.0   
Resolution:  duplicate|  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by kmtracey):

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

Comment:

 #10495 reported this again and also suggested a striptags filter on the
 title tag.

-- 
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] #9596: Comparing a DateTimeField to a date is too hard

[Django]

#9596: Comparing a DateTimeField to a date is too hard
---+
  Reporter:  dja...@mashi.org  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  
lookup_type date datetimefield compare comparison query_term field lookup
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #2131: [patch] HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: [patch] HttpResponseSendFile for serving static files handler-specific
sendfile mechanism
---+
  Reporter:  ymasuda[at]ethercube.com  | Owner:  alsleme 
Status:  new   | Milestone:  1.1 beta
 Component:  Core framework|   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  1   
Needs_better_patch:  1 |  
---+
Comment (by mrts):

 As for middleware, they can explicitly bypass `HttpResponseSendFile`
 responses as follows:

 {{{
 def process_response(self, request, response):
 if isinstance(response, HttpResponseSendFile):
 return response
 }}}

 or the handlers can bypass `HttpResponseSendFile` implicitly in
 `__call__`:

 {{{
 if not isinstance(response, HttpResponseSendFile):
 for middleware_method in self._response_middleware:
 response = middleware_method(request, response)
 }}}

-- 
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] #2131: [patch] HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: [patch] HttpResponseSendFile for serving static files handler-specific
sendfile mechanism
---+
  Reporter:  ymasuda[at]ethercube.com  | Owner:  alsleme 
Status:  new   | Milestone:  1.1 beta
 Component:  Core framework|   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  1   
Needs_better_patch:  1 |  
---+
Comment (by mrts):

 > RAM also seems to 'hang around' after each request, so I suspect that
 .close() isn't being called properly on self._container, or _get_content
 needs to add a signal-hook to signals.request_finished to expire the
 content from RAM by deleting the variable or setting it to '' or somesuch.

 There's a slight possibility that the cause may be `return iter(lambda:
 filelike.read(block_size), '')` that was used in the previous patch if.
 There's no `close()` in the resulting iterator. I used the `FileWrapper`
 from basehttp.py instead, please try if this changes things.

-- 
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] #2131: [patch] HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: [patch] HttpResponseSendFile for serving static files handler-specific
sendfile mechanism
---+
  Reporter:  ymasuda[at]ethercube.com  | Owner:  alsleme 
Status:  new   | Milestone:  1.1 beta
 Component:  Core framework|   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  1   
Needs_better_patch:  1 |  
---+
Comment (by mrts):

 As far as I can see, `HttpResponseSendFile` should not mimic
 `HttpResponse` in the sense that it should always be specially handled.
 Ordinary `HttpResponse` can take a file object in the `content` parameter
 already and serve the file from within Python, so that behaviour should be
 explicitly disallowed in `HttpResponseSendFile`.

 Attaching a patch that does exactly this, i.e. doesn't `open()` the file
 and passes `None` as `content` to parent constructor to make it explicit
 that the content is neither a string nor can be handled with the default
 behaviour. I'm not sure about the ''Content-Length'' header though, I've
 currently added it to be compatible with
 `ServerHandler.cleanup_headers()`, but it may need more thought.

 Btw, how `mod_python` handles `req.sendfile` can be seen here:
 
https://svn.apache.org/repos/asf/quetzalcoatl/mod_python/trunk/src/requestobject.c
 .

-- 
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] #10503: trans noop doesn'twork

[Django]

#10503: trans noop doesn'twork
--+-
  Reporter:  liangent | Owner:  nobody
Status:  new  | Milestone:
 Component:  Template system  |   Version:  1.0   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by liangent):

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

Comment:

 i'm not sure if it's because of my misunderstanding of document.

 in document:

 {{{

 If the noop option is present, variable lookup still takes place but the
 translation is skipped. This is useful when "stubbing out" content that
 will require translation in the future:

 }}}

 i think it means that the tag will output nothing.

-- 
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] #10503: trans noop doesn'twork

[Django]

#10503: trans noop doesn'twork
-+--
 Reporter:  liangent |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Template system  | Version:  1.0   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 i used {{{ {% trans "yes" noop %} }}} in templates and {{{ yes }}} appears
 unless i comment it out.

-- 
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] #10490: Very small vocabulary problem in docs

[Django]

#10490: Very small vocabulary problem in docs
+---
  Reporter:  matehat| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
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

Comment:

 nice catch!

-- 
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] #10501: Grammar in documentation of models.Model

[Django]

#10501: Grammar in documentation of models.Model
--+-
  Reporter:  Paul Menzel   | 
Owner:  nobody
Status:  new  | 
Milestone:
 Component:  Documentation|   
Version:  1.0   
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] #10502: Typos in tutorial part 2

[Django]

#10502: Typos in tutorial part 2
--+-
  Reporter:  Paul Menzel   | 
Owner:  nobody
Status:  new  | 
Milestone:
 Component:  Documentation|   
Version:  1.0   
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-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] #10502: Typos in tutorial part 2

[Django]

#10502: Typos in tutorial part 2
-+--
 Reporter:  Paul Menzel   |   Owner:  
nobody
   Status:  new  |   Milestone: 
   
Component:  Documentation| Version:  
1.0   
 Keywords:   |   Stage:  
Unreviewed
Has_patch:  0|  
-+--
 Dear developers,


 thank you for this great tutorial. I am no native speaker but I think I
 found a typo.

 “…, Django just lets you edit the object and "guess" at how to display it
 within the admin.” [1]

 s/guess/guesses/

 And while we are at it. You can use typographically correct quotation
 marks. “guesses”


 Thanks,

 Paul


 [1] http://docs.djangoproject.com/en/dev/intro/tutorial02/#intro-
 tutorial02

-- 
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] #10454: IntegrityError while deleting object with complex constraint

[Django]

#10454: IntegrityError while deleting object with complex constraint
---+
  Reporter:  liangent  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by liangent):

 the bug also disappears after removing {{{ and filter(lambda f: f.column
 == field.column, field.rel.to._meta.fields)}}}, but i'm not sure if
 there's other side-effect.

-- 
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] #10501: Grammar in documentation of models.Model

[Django]

#10501: Grammar in documentation of models.Model
-+--
 Reporter:  Paul Menzel   |   Owner:  
nobody
   Status:  new  |   Milestone: 
   
Component:  Documentation| Version:  
1.0   
 Keywords:   |   Stage:  
Unreviewed
Has_patch:  0|  
-+--
 Dear developers,

 I am no native speaker, but

 “The keyword arguments to are simply …” [1]

 sounds not right to me. I guess either omit “to” or add model or something
 like this.


 Thanks,

 Paul


 [1]
 
http://docs.djangoproject.com/en/dev/ref/models/instances/#django.db.models.Model

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #2131: [patch] HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: [patch] HttpResponseSendFile for serving static files handler-specific
sendfile mechanism
---+
  Reporter:  ymasuda[at]ethercube.com  | Owner:  alsleme 
Status:  new   | Milestone:  1.1 beta
 Component:  Core framework|   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  1   
Needs_better_patch:  1 |  
---+
Changes (by mrts):

  * needs_better_patch:  0 => 1
  * needs_docs:  0 => 1

Comment:

 Questions:

  1. Why to you first do an expensive call to `getsize` in `self['Content-
 Length'] = os.path.getsize(path_to_file)` and later discard it in `if
 hasattr(response, 'sendfile_filename') and response.has_header('Content-
 Length'): del response['Content-Length']` in WSGI handler? I didn't find
 anything in [http://www.python.org/dev/peps/pep-0333/ PEP 333] that would
 suggest this is needed. Please correct me or remove that bit.
  1. Although this is mostly a conceptual/taste matter, wouldn't it be more
 clear to use `isinstance(response, HttpResponseSendFile)` instead of
 `hasattr(response, 'sendfile_filename')` to discern `HttpResponseSendFile`
 objects?

 Nitpicking `HttpResponseSendFile.__init__`:
  1. ''Comparisons to singletons like None should always be done with 'is'
 or 'is not', never the equality operators.'' --
 [http://www.python.org/dev/peps/pep-0008/ PEP 8], thus `content_type ==
 None` should be `content_type is None` instead.
  1. Opening the file needs to be consistent. You open it in the
 constructor and later reopen again in handlers, so the file is opened
 twice.
  1. The logic of parent constructor should be reused, I suggest the
 following instead:
  {{{
 class HttpResponseSendFile(HttpResponse):
 def __init__(self, path_to_file, content_type=None, blocksize=8192):
 if not content_type: # or even if content_type is None
 from mimetypes import guess_type
 content_type = guess_type(path_to_file)[0]
 if content_type is None: # probably windows w/o proper
 mimetype lookup
 content_type = "application/octet-stream"
 container = open(path_to_file) # be consistent, either open() here
 and don't reopen in handlers or don't open() here
 super(HttpResponseSendFile, self).__init__(content=container,
 content_type=content_type)
 self.sendfile_filename = path_to_file
 self.block_size = blocksize
 # compatibility; fake being a regular HttpResponse if needed
 self._headers['content-length'] = ('Content-Length',
 os.path.getsize(path_to_file))
  }}}

 Looks like more thought has to be given to the general context
 (basehttp.py etc). Docs and tests are missing as well.

 Otherwise, nice work!

-- 
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] #8060: Admin Inlines do not respect user permissions

[Django]

#8060: Admin Inlines do not respect user permissions
+---
  Reporter:  p.patr...@iperbole.bologna.it  | Owner:  dgouldin  
 
Status:  new| Milestone:  1.1 beta  
 
 Component:  django.contrib.admin   |   Version:  SVN   
 
Resolution: |  Keywords:  inlines 
User authentication
 Stage:  Design decision needed | Has_patch:  0 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

  * milestone:  => 1.1 beta

-- 
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] #10500: Update information on Debian packages in Third-party distributions of Django

[Django]

#10500: Update information on Debian packages in Third-party distributions of
Django
--+-
  Reporter:  Paul Menzel   | 
Owner:  nobody
Status:  closed   | 
Milestone:
 Component:  Documentation|   
Version:  1.0   
Resolution:  duplicate|  
Keywords:
 Stage:  Unreviewed   | 
Has_patch:  0 
Needs_docs:  0|   
Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by ubernostrum):

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

Comment:

 Duplicate of #10424, which is working on ways to provide more usefully-up-
 to-date info on third-party distributions.

-- 
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] #10500: Update information on Debian packages in Third-party distributions of Django

[Django]

#10500: Update information on Debian packages in Third-party distributions of
Django
-+--
 Reporter:  Paul Menzel   |   Owner:  
nobody
   Status:  new  |   Milestone: 
   
Component:  Documentation| Version:  
1.0   
 Keywords:   |   Stage:  
Unreviewed
Has_patch:  0|  
-+--
 Dear caretakers,


 since Lenny is released Django 1.0.2 is available in stable, testing and
 unstable.

 Please also use aptitude instead of apt-get in

 „you can install Django by typing apt-get install python-django“

 since it is since Etch the recommended fronted for APT [1][2].


 Thanks a lot,

 Paul


 [1] http://www.debian.org/releases/lenny/i386/release-notes/ch-whats-
 new.en.html#pkgmgmt

 [2] http://www.debian.org/releases/etch/i386/release-notes/ch-whats-
 new.en.html#pkgmgmt

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