[Changeset] r14834 - in django/branches/releases/1.2.X/docs: ref/files topics

[noreply]

Author: gabrielhurley
Date: 2010-12-05 01:36:40 -0600 (Sun, 05 Dec 2010)
New Revision: 14834

Modified:
   django/branches/releases/1.2.X/docs/ref/files/file.txt
   django/branches/releases/1.2.X/docs/ref/files/index.txt
   django/branches/releases/1.2.X/docs/topics/files.txt
Log:
[1.2.X] Fixed #13162 and #11597 -- Improved the file handling documentation: 
Removed documentation of methods on django.core.files.File that did not exist, 
added documentation for undocumented methods and attributes that did exist, did 
a general cleanup of the text and organization, and added more metadata 
targets. Thanks to amenasse and tyrion.mx for the reports.

Backport of [14833] from trunk.

Modified: django/branches/releases/1.2.X/docs/ref/files/file.txt
===
--- django/branches/releases/1.2.X/docs/ref/files/file.txt  2010-12-05 
07:35:10 UTC (rev 14833)
+++ django/branches/releases/1.2.X/docs/ref/files/file.txt  2010-12-05 
07:36:40 UTC (rev 14834)
@@ -1,56 +1,54 @@
 The ``File`` object
 ===
 
+The :mod:`django.core.files` module and its submodules contain built-in classes
+for basic file handling in Django.
+
 .. currentmodule:: django.core.files
 
-``File`` attributes and methods

+The ``File`` Class
+--
 
-The :mod:`django.core.files` module contains a built-in class for basic file
-handling in Django. The :class:`File` class has the following attributes and
-methods:
-
 .. class:: File(file_object)
 
+The :class:`File` is a thin wrapper around Python's built-in file object
+with some Django-specific additions. Internally, Django uses this class
+any time it needs to represent a file.
+
+:class:`File` objects have the following attributes and methods:
+
 .. attribute:: name
 
-The name of file including the relative path from 
:setting:`MEDIA_ROOT`.
+The name of file including the relative path from
+:setting:`MEDIA_ROOT`.
 
-.. attribute:: path
+.. attribute:: size
 
-The absolute path to the file's location on a local filesystem.
+The size of the file in bytes.
 
-:doc:`Custom file storage systems ` may 
not store
-files locally; files stored on these systems will have a ``path`` of
-``None``.
+.. attribute:: file
 
-.. attribute:: url
+The underlying Python ``file`` object passed to
+:class:`~django.core.files.File`.
 
-The URL where the file can be retrieved. This is often useful in
-:doc:`templates `; for example, a bit of a template 
for
-displaying a ``Car`` (see above) might look like:
+.. attribute:: mode
 
-.. code-block:: html+django
+The read/write mode for the file.
 
-
-
-.. attribute:: size
-
-The size of the file in bytes.
-
 .. method:: open([mode=None])
 
-Open or reopen the file (which by definition also does 
``File.seek(0)``).
-The ``mode`` argument allows the same values as Python's standard
-``open()``.
+Open or reopen the file (which by definition also does
+``File.seek(0)``). The ``mode`` argument allows the same values
+as Python's standard ``open()``.
 
-When reopening a file, ``mode`` will override whatever mode the file 
was
-originally opened with; ``None`` means to reopen with the original 
mode.
+When reopening a file, ``mode`` will override whatever mode the file
+was originally opened with; ``None`` means to reopen with the original
+mode.
 
 .. method:: read([num_bytes=None])
 
-Read content from the file. The optional ``size`` is the number of 
bytes to
-read; if not specified, the file will be read to the end.
+Read content from the file. The optional ``size`` is the number of
+bytes to read; if not specified, the file will be read to the end.
 
 .. method:: __iter__()
 
@@ -61,38 +59,65 @@
 Iterate over the file yielding "chunks" of a given size. ``chunk_size``
 defaults to 64 KB.
 
-This is especially useful with very large files since it allows them 
to be
-streamed off disk and avoids storing the whole file in memory.
+This is especially useful with very large files since it allows them to
+be streamed off disk and avoids storing the whole file in memory.
 
 .. method:: multiple_chunks([chunk_size=None])
 
-Returns ``True`` if the file is large enough to require multiple 
chunks to
-access all of its content give some ``chunk_size``.
+Returns ``True`` if the file is large enough to require multiple chunks
+to access all of its content give some ``chunk_size``.
 
 .. method:: write([content])
 
-Writes the specified content string to the file. Depending on the 
storage
-system behind the scenes, this content might not be fully 

[Changeset] r14833 - in django/trunk/docs: ref/files topics

[noreply]

Author: gabrielhurley
Date: 2010-12-05 01:35:10 -0600 (Sun, 05 Dec 2010)
New Revision: 14833

Modified:
   django/trunk/docs/ref/files/file.txt
   django/trunk/docs/ref/files/index.txt
   django/trunk/docs/topics/files.txt
Log:
Fixed #13162 and #11597 -- Improved the file handling documentation: Removed 
documentation of methods on django.core.files.File that did not exist, added 
documentation for undocumented methods and attributes that did exist, did a 
general cleanup of the text and organization, and added more metadata targets. 
Thanks to amenasse and tyrion.mx for the reports.

Modified: django/trunk/docs/ref/files/file.txt
===
--- django/trunk/docs/ref/files/file.txt2010-12-05 06:46:23 UTC (rev 
14832)
+++ django/trunk/docs/ref/files/file.txt2010-12-05 07:35:10 UTC (rev 
14833)
@@ -1,56 +1,54 @@
 The ``File`` object
 ===
 
+The :mod:`django.core.files` module and its submodules contain built-in classes
+for basic file handling in Django.
+
 .. currentmodule:: django.core.files
 
-``File`` attributes and methods

+The ``File`` Class
+--
 
-The :mod:`django.core.files` module contains a built-in class for basic file
-handling in Django. The :class:`File` class has the following attributes and
-methods:
-
 .. class:: File(file_object)
 
+The :class:`File` is a thin wrapper around Python's built-in file object
+with some Django-specific additions. Internally, Django uses this class
+any time it needs to represent a file.
+
+:class:`File` objects have the following attributes and methods:
+
 .. attribute:: name
 
-The name of file including the relative path from 
:setting:`MEDIA_ROOT`.
+The name of file including the relative path from
+:setting:`MEDIA_ROOT`.
 
-.. attribute:: path
+.. attribute:: size
 
-The absolute path to the file's location on a local filesystem.
+The size of the file in bytes.
 
-:doc:`Custom file storage systems ` may 
not store
-files locally; files stored on these systems will have a ``path`` of
-``None``.
+.. attribute:: file
 
-.. attribute:: url
+The underlying Python ``file`` object passed to
+:class:`~django.core.files.File`.
 
-The URL where the file can be retrieved. This is often useful in
-:doc:`templates `; for example, a bit of a template 
for
-displaying a ``Car`` (see above) might look like:
+.. attribute:: mode
 
-.. code-block:: html+django
+The read/write mode for the file.
 
-
-
-.. attribute:: size
-
-The size of the file in bytes.
-
 .. method:: open([mode=None])
 
-Open or reopen the file (which by definition also does 
``File.seek(0)``).
-The ``mode`` argument allows the same values as Python's standard
-``open()``.
+Open or reopen the file (which by definition also does
+``File.seek(0)``). The ``mode`` argument allows the same values
+as Python's standard ``open()``.
 
-When reopening a file, ``mode`` will override whatever mode the file 
was
-originally opened with; ``None`` means to reopen with the original 
mode.
+When reopening a file, ``mode`` will override whatever mode the file
+was originally opened with; ``None`` means to reopen with the original
+mode.
 
 .. method:: read([num_bytes=None])
 
-Read content from the file. The optional ``size`` is the number of 
bytes to
-read; if not specified, the file will be read to the end.
+Read content from the file. The optional ``size`` is the number of
+bytes to read; if not specified, the file will be read to the end.
 
 .. method:: __iter__()
 
@@ -61,38 +59,65 @@
 Iterate over the file yielding "chunks" of a given size. ``chunk_size``
 defaults to 64 KB.
 
-This is especially useful with very large files since it allows them 
to be
-streamed off disk and avoids storing the whole file in memory.
+This is especially useful with very large files since it allows them to
+be streamed off disk and avoids storing the whole file in memory.
 
 .. method:: multiple_chunks([chunk_size=None])
 
-Returns ``True`` if the file is large enough to require multiple 
chunks to
-access all of its content give some ``chunk_size``.
+Returns ``True`` if the file is large enough to require multiple chunks
+to access all of its content give some ``chunk_size``.
 
 .. method:: write([content])
 
-Writes the specified content string to the file. Depending on the 
storage
-system behind the scenes, this content might not be fully committed 
until
-``close()`` is called on the file.
+Writes the specified content string to the file. Depending on the
+

Re: [Django] #13564: Provide class attributes for form fields

[Django]

#13564: Provide class attributes for form fields
---+
  Reporter:  h3| Owner:  trebor74hr
Status:  assigned  | Milestone:  1.3   
 Component:  Forms |   Version:  1.2-beta  
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by gg):

 * cc: gg (added)

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

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

Re: [Django] #12865: There is information about module that holds File in the File object reference.

[Django]

#12865: There is information about module that holds File in the File object
reference.
+---
  Reporter:  pczapla| Owner:  nobody  
Status:  closed | Milestone:  
 Component:  Documentation  |   Version:  1.2-beta
Resolution:  worksforme |  Keywords:  
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

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

Comment:

 The first result on Google for "django file object" is
 [http://docs.djangoproject.com/en/dev/ref/files/file/ The File object
 reference documentation], and the first thing it says is "The
 django.core.files module contains a built-in class for basic file handling
 in Django. The File class..."

 I don't think it could be much clearer.

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

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

[Changeset] r14832 - in django/branches/releases/1.2.X/docs/ref: . files

[noreply]

Author: gabrielhurley
Date: 2010-12-05 00:46:23 -0600 (Sun, 05 Dec 2010)
New Revision: 14832

Modified:
   django/branches/releases/1.2.X/docs/ref/files/storage.txt
   django/branches/releases/1.2.X/docs/ref/settings.txt
Log:
[1.2.X] Fixed #13605 -- Improved documentation of the django.core.files.storage 
module. Added documentation for DefaultStorage, get_storage_class, 
FileSystemStorage, and some missing public methods on Storage. New metadata 
targets included for everything. Thanks to kopernikus for the report and 
elbarto for contributing to the patch.

Backport of [14831] from trunk.

Modified: django/branches/releases/1.2.X/docs/ref/files/storage.txt
===
--- django/branches/releases/1.2.X/docs/ref/files/storage.txt   2010-12-05 
06:45:34 UTC (rev 14831)
+++ django/branches/releases/1.2.X/docs/ref/files/storage.txt   2010-12-05 
06:46:23 UTC (rev 14832)
@@ -1,52 +1,119 @@
 File storage API
 
 
-``Storage.exists(name)``
-
+.. module:: django.core.files.storage
 
-``True`` if a file exists given some ``name``.
+Getting the current storage class
+-
 
-``Storage.path(name)``
-~~
+Django provides two convenient ways to access the current storage class:
 
-The local filesystem path where the file can be opened using Python's standard
-``open()``. For storage systems that aren't accessible from the local
-filesystem, this will raise ``NotImplementedError`` instead.
+.. class:: DefaultStorage
 
-``Storage.size(name)``
-~~
+:class:`~django.core.files.storage.DefaultStorage` provides
+lazy access to the current default storage system as defined by
+:setting:`DEFAULT_FILE_STORAGE`. :class:`DefaultStorage` uses
+:func:`~django.core.files.storage.get_storage_class` internally.
 
-Returns the total size, in bytes, of the file referenced by ``name``.
+.. function:: get_storage_class([import_path=None])
 
-``Storage.url(name)``
-~
+Returns a class or module which implements the storage API.
+
+When called without the ``import_path`` parameter ``get_storage_class``
+will return the current default storage system as defined by
+:setting:`DEFAULT_FILE_STORAGE`. If ``import_path`` is provided,
+``get_storage_class`` will attempt to import the class or module from the
+given path and will return it if successful. An exception will be
+raised if the import is unsuccessful.
 
-Returns the URL where the contents of the file referenced by ``name`` can be
-accessed.
+The FileSystemStorage Class
+---
 
-``Storage.open(name, mode='rb')``
-~
+.. class:: FileSystemStorage
 
-Opens the file given by ``name``. Note that although the returned file is
-guaranteed to be a ``File`` object, it might actually be some subclass. In the
-case of remote file storage this means that reading/writing could be quite 
slow,
-so be warned.
+The :class:`~django.core.files.storage.FileSystemStorage` class implements
+basic file storage on a local filesystem. It inherits from
+:class:`~django.core.files.storage.Storage` and provides implementations
+for all the public methods thereof.
+
+.. note::
+
+The :class:`FileSystemStorage.delete` method will not raise
+raise an exception if the given file name does not exist.
 
-``Storage.save(name, content)``
-~~~
+The Storage Class
+-
 
-Saves a new file using the storage system, preferably with the name specified.
-If there already exists a file with this name ``name``, the storage system may
-modify the filename as necessary to get a unique name. The actual name of the
-stored file will be returned.
+.. class:: Storage
 
-The ``content`` argument must be an instance of
-:class:`django.core.files.File` or of a subclass of
-:class:`~django.core.files.File`.
+The :class:`~django.core.files.storage.Storage` class provides a
+standardized API for storing files, along with a set of default
+behaviors that all other storage systems can inherit or override
+as necessary.
 
-``Storage.delete(name)``
-
+.. method:: delete(name)
 
-Deletes the file referenced by ``name``. This method won't raise an exception 
if
-the file doesn't exist.
+Deletes the file referenced by ``name``. If deletion is not supported
+on the targest storage system this will raise ``NotImplementedError``
+instead
 
+.. method:: exists(name)
+
+Returns ``True`` if a file referened by the given name already exists
+in the storage system, or ``False`` if the name is available for a new
+file.
+
+.. method:: get_available_name(name)
+
+Returns a filename based on the ``name`` parameter that's free and
+available for new content to be written to on the 

[Changeset] r14831 - in django/trunk/docs/ref: . files

[noreply]

Author: gabrielhurley
Date: 2010-12-05 00:45:34 -0600 (Sun, 05 Dec 2010)
New Revision: 14831

Modified:
   django/trunk/docs/ref/files/storage.txt
   django/trunk/docs/ref/settings.txt
Log:
Fixed #13605 -- Improved documentation of the django.core.files.storage module. 
Added documentation for DefaultStorage, get_storage_class, FileSystemStorage, 
and some missing public methods on Storage. New metadata targets included for 
everything. Thanks to kopernikus for the report and elbarto for contributing to 
the patch.

Modified: django/trunk/docs/ref/files/storage.txt
===
--- django/trunk/docs/ref/files/storage.txt 2010-12-05 04:52:31 UTC (rev 
14830)
+++ django/trunk/docs/ref/files/storage.txt 2010-12-05 06:45:34 UTC (rev 
14831)
@@ -1,79 +1,143 @@
 File storage API
 
 
-``Storage.exists(name)``
-
+.. module:: django.core.files.storage
 
-``True`` if a file exists given some ``name``.
+Getting the current storage class
+-
 
-``Storage.path(name)``
-~~
+Django provides two convenient ways to access the current storage class:
 
-The local filesystem path where the file can be opened using Python's standard
-``open()``. For storage systems that aren't accessible from the local
-filesystem, this will raise ``NotImplementedError`` instead.
+.. class:: DefaultStorage
 
-``Storage.accessed_time(name)``
-~~~
+:class:`~django.core.files.storage.DefaultStorage` provides
+lazy access to the current default storage system as defined by
+:setting:`DEFAULT_FILE_STORAGE`. :class:`DefaultStorage` uses
+:func:`~django.core.files.storage.get_storage_class` internally.
 
-.. versionadded:: 1.3
+.. function:: get_storage_class([import_path=None])
 
-Returns a ``datetime`` object containing the last accessed time of the file.
-For storage systems that aren't able to return the last accessed time, this
-will raise ``NotImplementedError`` instead.
+Returns a class or module which implements the storage API.
+
+When called without the ``import_path`` parameter ``get_storage_class``
+will return the current default storage system as defined by
+:setting:`DEFAULT_FILE_STORAGE`. If ``import_path`` is provided,
+``get_storage_class`` will attempt to import the class or module from the
+given path and will return it if successful. An exception will be
+raised if the import is unsuccessful.
 
-``Storage.created_time(name)``
-~~
+The FileSystemStorage Class
+---
 
-.. versionadded:: 1.3
+.. class:: FileSystemStorage
 
-Returns a ``datetime`` object containing the creation time of the file.
-For storage systems that aren't able to return the creation time, this
-will raise ``NotImplementedError`` instead.
+The :class:`~django.core.files.storage.FileSystemStorage` class implements
+basic file storage on a local filesystem. It inherits from
+:class:`~django.core.files.storage.Storage` and provides implementations
+for all the public methods thereof.
+
+.. note::
+
+The :class:`FileSystemStorage.delete` method will not raise
+raise an exception if the given file name does not exist.
 
-``Storage.modified_time(name)``
-~~~
+The Storage Class
+-
 
-.. versionadded:: 1.3
+.. class:: Storage
 
-Returns a ``datetime`` object containing the last modified time. For storage
-systems that aren't able to return the last modified time, this will raise
-``NotImplementedError`` instead.
+The :class:`~django.core.files.storage.Storage` class provides a
+standardized API for storing files, along with a set of default
+behaviors that all other storage systems can inherit or override
+as necessary.
 
-``Storage.size(name)``
-~~
+.. method:: accessed_time(name)
 
-Returns the total size, in bytes, of the file referenced by ``name``.
+.. versionadded:: 1.3
 
-``Storage.url(name)``
-~
+Returns a ``datetime`` object containing the last accessed time of the
+file. For storage systems that aren't able to return the last accessed
+time this will raise ``NotImplementedError`` instead.
 
-Returns the URL where the contents of the file referenced by ``name`` can be
-accessed.
+.. method:: created_time(name)
 
-``Storage.open(name, mode='rb')``
-~
+.. versionadded:: 1.3
 
-Opens the file given by ``name``. Note that although the returned file is
-guaranteed to be a ``File`` object, it might actually be some subclass. In the
-case of remote file storage this means that reading/writing could be quite 
slow,
-so be warned.
+Returns a ``datetime`` object containing the creation time of the file.
+For storage systems that aren't able to return the 

Re: [Django] #14358: History changes in admin don't show verbose_name

[Django]

#14358: History changes in admin don't show verbose_name
-+--
  Reporter:  mordicuac   | Owner:  nobody   
 
Status:  new | Milestone:  1.3  
 
 Component:  django.contrib.admin|   Version:  SVN  
 
Resolution:  |  Keywords:  history, 
verbose_name, admin,sprintdec2010
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by cogat):

  * stage:  Accepted => Design decision needed

Comment:

 I think this counts as a problem for end-users seeing the changelist, who
 would understand verbose names better. OTOH, for debug purposes, it would
 be more useful to have the field names, as they are necessarily unique,
 untranslated, etc.

 Perhaps both is best?

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

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

Re: [Django] #14802: feature request: ability to override default hidden_widget used to render a custom model field when marked as readonly in the admin

[Django]

#14802: feature request: ability to override default hidden_widget used to 
render a
custom model field when marked as readonly in the admin
-+--
  Reporter:  nickname123 | Owner:  nobody   
  
Status:  closed  | Milestone:  1.3  
  
 Component:  django.contrib.admin|   Version:  1.2  
  
Resolution:  wontfix |  Keywords:  sprintdec2010 
hidden_widget
 Stage:  Design decision needed  | Has_patch:  0
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by cogat):

  * status:  new => closed
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * keywords:  hidden_widget => sprintdec2010 hidden_widget
  * needs_docs:  => 0
  * resolution:  => wontfix
  * stage:  Unreviewed => Design decision needed

Comment:

 The admin app doesn't render hidden_widget at all, it just displays
 readonly fields (using `getattr(modelinstance, fieldname)`). AFAICS
 hidden_widget is only used by form previews and form wizards for holding
 on to copies of fields that were entered in an earlier view.

 If you are asking for a customised way to render a read-only field, then
 it might be helpful to know that you can pass a callable to
 readonly_fields that renders the result you want.

 {{{
 class Song(models.Model):
 band = models.ForeignKey(Band)
 title = CustomModelField(max_length=100)

 def rendertitle(self):
 return "A custom rendering of %s" % self.title

 class SongAdmin(admin.ModelAdmin):
 exclude = ('title',)
 readonly_fields = ('rendertitle', )

 }}}

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

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

Re: [Django] #14358: History changes in admin don't show verbose_name

[Django]

#14358: History changes in admin don't show verbose_name
---+
  Reporter:  mordicuac | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  django.contrib.admin  |   Version:  SVN
   
Resolution:|  Keywords:  history, 
verbose_name, admin,sprintdec2010
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by julien):

  * keywords:  history, verbose_name, admin => history, verbose_name,
   admin,sprintdec2010
  * has_patch:  0 => 1
  * stage:  Unreviewed => Accepted
  * milestone:  => 1.3

Comment:

 Confirming the bug. Patch coming.

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

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

Re: [Django] #14586: Make interpolate JS function not require the named parameter.

[Django]

#14586: Make interpolate JS function not require the named parameter.
-+--
  Reporter:  aminland| Owner:  nobody
Status:  new | Milestone:
 Component:  Internationalization|   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by julien):

  * stage:  Unreviewed => Design decision needed
  * milestone:  1.3 =>

Comment:

 Making this change would likely break backwards compatibility. Needs more
 design discussion.

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

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

Re: [Django] #5481: ChoiceField/ModelChoiceField always returns strings, regardless of type in choices

[Django]

#5481: ChoiceField/ModelChoiceField always returns strings, regardless of type 
in
choices
---+
  Reporter:  rcoup | Owner:  nobody 
Status:  closed| Milestone: 
 Component:  Forms |   Version:  SVN
Resolution:  wontfix   |  Keywords:  sprint14sep
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Changes (by russellm):

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

Comment:

 r14829 added a TypedMultipleChoiceField, making this a wontfix.

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

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

[Changeset] r14829 - in django/trunk: django/forms docs/ref/forms tests/regressiontests/forms/tests

[noreply]

Author: russellm
Date: 2010-12-04 22:47:19 -0600 (Sat, 04 Dec 2010)
New Revision: 14829

Modified:
   django/trunk/django/forms/fields.py
   django/trunk/docs/ref/forms/fields.txt
   django/trunk/tests/regressiontests/forms/tests/fields.py
Log:
Fixed #12398 -- Added a TypedMultipleChoiceField. Thanks to Tai Lee.

Modified: django/trunk/django/forms/fields.py
===
--- django/trunk/django/forms/fields.py 2010-12-05 04:32:36 UTC (rev 14828)
+++ django/trunk/django/forms/fields.py 2010-12-05 04:47:19 UTC (rev 14829)
@@ -40,7 +40,7 @@
 'BooleanField', 'NullBooleanField', 'ChoiceField', 'MultipleChoiceField',
 'ComboField', 'MultiValueField', 'FloatField', 'DecimalField',
 'SplitDateTimeField', 'IPAddressField', 'FilePathField', 'SlugField',
-'TypedChoiceField'
+'TypedChoiceField', 'TypedMultipleChoiceField'
 )
 
 def en_format(name):
@@ -700,7 +700,7 @@
 
 def to_python(self, value):
 """
-Validate that the value is in self.choices and can be coerced to the
+Validates that the value is in self.choices and can be coerced to the
 right type.
 """
 value = super(TypedChoiceField, self).to_python(value)
@@ -742,6 +742,32 @@
 if not self.valid_value(val):
 raise ValidationError(self.error_messages['invalid_choice'] % 
{'value': val})
 
+class TypedMultipleChoiceField(MultipleChoiceField):
+def __init__(self, *args, **kwargs):
+self.coerce = kwargs.pop('coerce', lambda val: val)
+self.empty_value = kwargs.pop('empty_value', [])
+super(TypedMultipleChoiceField, self).__init__(*args, **kwargs)
+
+def to_python(self, value):
+"""
+Validates that the values are in self.choices and can be coerced to the
+right type.
+"""
+value = super(TypedMultipleChoiceField, self).to_python(value)
+super(TypedMultipleChoiceField, self).validate(value)
+if value == self.empty_value or value in validators.EMPTY_VALUES:
+return self.empty_value
+new_value = []
+for choice in value:
+try:
+new_value.append(self.coerce(choice))
+except (ValueError, TypeError, ValidationError):
+raise ValidationError(self.error_messages['invalid_choice'] % 
{'value': choice})
+return new_value
+
+def validate(self, value):
+pass
+
 class ComboField(Field):
 """
 A Field whose clean() method calls multiple Field clean() methods.

Modified: django/trunk/docs/ref/forms/fields.txt
===
--- django/trunk/docs/ref/forms/fields.txt  2010-12-05 04:32:36 UTC (rev 
14828)
+++ django/trunk/docs/ref/forms/fields.txt  2010-12-05 04:47:19 UTC (rev 
14829)
@@ -361,13 +361,14 @@
 
 .. class:: TypedChoiceField(**kwargs)
 
-Just like a :class:`ChoiceField`, except :class:`TypedChoiceField` takes an
-extra ``coerce`` argument.
+Just like a :class:`ChoiceField`, except :class:`TypedChoiceField` takes two
+extra arguments, ``coerce`` and ``empty_value``.
 
 * Default widget: ``Select``
 * Empty value: Whatever you've given as ``empty_value``
-* Normalizes to: the value returned by the ``coerce`` argument.
-* Validates that the given value exists in the list of choices.
+* Normalizes to: A value of the type provided by the ``coerce`` argument.
+* Validates that the given value exists in the list of choices and can be
+  coerced.
 * Error message keys: ``required``, ``invalid_choice``
 
 Takes extra arguments:
@@ -635,8 +636,26 @@
   of choices.
 * Error message keys: ``required``, ``invalid_choice``, ``invalid_list``
 
-Takes one extra argument, ``choices``, as for ``ChoiceField``.
+Takes one extra required argument, ``choices``, as for ``ChoiceField``.
 
+``TypedMultipleChoiceField``
+
+
+.. class:: TypedMultipleChoiceField(**kwargs)
+
+Just like a :class:`MultipleChoiceField`, except 
:class:`TypedMultipleChoiceField`
+takes two extra arguments, ``coerce`` and ``empty_value``.
+
+* Default widget: ``SelectMultiple``
+* Empty value: Whatever you've given as ``empty_value``
+* Normalizes to: A list of values of the type provided by the ``coerce``
+  argument.
+* Validates that the given values exists in the list of choices and can be
+  coerced.
+* Error message keys: ``required``, ``invalid_choice``
+
+Takes two extra arguments, ``coerce`` and ``empty_value``, as for 
``TypedChoiceField``.
+
 ``NullBooleanField``
 
 

Modified: django/trunk/tests/regressiontests/forms/tests/fields.py
===
--- django/trunk/tests/regressiontests/forms/tests/fields.py2010-12-05 
04:32:36 UTC (rev 14828)
+++ django/trunk/tests/regressiontests/forms/tests/fields.py2010-12-05 
04:47:19 UTC 

Re: [Django] #14835: Improper indentation for docs/ref/contrib/admin/index.txt

[Django]

#14835: Improper indentation for docs/ref/contrib/admin/index.txt
+---
  Reporter:  cogat  | Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.3  
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:  sprintdec2010
 Stage:  Accepted   | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * owner:  cogat => gabrielhurley
  * status:  new => assigned
  * stage:  Unreviewed => Accepted
  * summary:  Indents for descriptions of documentation attributes =>
  Improper indentation for
  docs/ref/contrib/admin/index.txt
  * milestone:  => 1.3

Comment:

 I've noted it on other tickets before, but this is a reST markup problem,
 not a CSS problem. Basically, it's a lack of proper indentation in the
 file such that the `` elements aren't created. There are a lot of
 older chunks of the docs that have this problem.

 When the markup is correct the indentation of the elements is also
 correct. I prefer fixing the markup (the real problem) to applying CSS
 hacks to correct for bad markup.

 I'm changing this ticket to be about fixing the markup in that file, and
 will commit the fix to close it momentarily.

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

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

Re: [Django] #13978: Allow inline js/css in forms.Media

[Django]

#13978: Allow inline js/css in forms.Media
+---
  Reporter:  nathforge  | Owner:  nobody   
Status:  new| Milestone:  1.3  
 Component:  Forms  |   Version:  SVN  
Resolution: |  Keywords:  sprintdec2010
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  1  |   Needs_tests:  1
Needs_better_patch:  0  |  
+---
Changes (by julien):

  * keywords:  => sprintdec2010
  * stage:  Design decision needed => Accepted
  * milestone:  => 1.3

Comment:

 This sounds like a really useful feature. You'd need to add some tests and
 documentation if you want it to have a chance of shipping with 1.3?

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

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

Re: [Django] #14720: Settings imported twice as separate modules when manage.py is used

[Django]

#14720: Settings imported twice as separate modules when manage.py is used
-+--
  Reporter:  zimnyx  | Owner:  bretth
Status:  assigned| Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Someday/Maybe   | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by bretth):

  * owner:  nobody => bretth
  * status:  new => assigned
  * version:  1.2 => SVN
  * stage:  Unreviewed => Someday/Maybe

Comment:

 Note: you cannot use 'from project_module import settings' unless you have
 explicitly added project_module to your PYTHONPATH

 Graham Dumpleton has a good post on this:
 http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html

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

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

Re: [Django] #11206: The floatformat template tag doesn't work with a value of 0 and a precision of 7 or higher.

[Django]

#11206: The floatformat template tag doesn't work with a value of 0 and a 
precision
of 7 or higher.
--+-
  Reporter:  mrmachine| Owner:  nobody  
 
Status:  new  | Milestone:  1.3 
 
 Component:  Template system  |   Version:  SVN 
 
Resolution:   |  Keywords:  floatformat precision 7 
decimal sprintdec2010
 Stage:  Accepted | Has_patch:  1   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Comment (by mrmachine):

 Updated the patch to use a list comprehension and consistent unicode
 strings as per brodie's feedback in #django-sprint.

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

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

Re: [Django] #14671: Allow overriding of ModelChoiceField.choices

[Django]

#14671: Allow overriding of ModelChoiceField.choices
---+
  Reporter:  simon29   | Owner:  nobody   
Status:  new   | Milestone:  1.3  
 Component:  Forms |   Version:  SVN  
Resolution:|  Keywords:  sprintdec2010
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  1
Needs_better_patch:  0 |  
---+
Changes (by cogat):

  * keywords:  => sprintdec2010

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

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

Re: [Django] #14671: Allow overriding of ModelChoiceField.choices

[Django]

#14671: Allow overriding of ModelChoiceField.choices
---+
  Reporter:  simon29   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Forms |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by cogat):

 * cc: cogat (removed)
  * needs_tests:  0 => 1
  * stage:  Unreviewed => Accepted

Comment:

 -1 on the addition of BaseModelFormSet to `__all__`. Although the classes
 can be useful, they are abstract, and can be imported explicitly with:

 {{{
 from forms.models import BaseModelFormSet
 }}}

 For the problem at hand, a test that illustrates the bug would help
 immensely. Reviewing the patch, it looks reasonable, except the choice of
 variable name for `pk`, given that something else could be in
 `self.to_field_name`.

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

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

[Changeset] r14828 - in django/trunk: django/views/generic docs/ref tests/regressiontests/generic_views

[noreply]

Author: russellm
Date: 2010-12-04 22:32:36 -0600 (Sat, 04 Dec 2010)
New Revision: 14828

Modified:
   django/trunk/django/views/generic/list.py
   django/trunk/docs/ref/class-based-views.txt
   django/trunk/tests/regressiontests/generic_views/list.py
   django/trunk/tests/regressiontests/generic_views/urls.py
   django/trunk/tests/regressiontests/generic_views/views.py
Log:
Fixed #14773 -- Modified MultipleObjectMixin to allow for custom paginators. 
Thanks to piquadrat for the report and initial patch.

Modified: django/trunk/django/views/generic/list.py
===
--- django/trunk/django/views/generic/list.py   2010-12-05 02:09:29 UTC (rev 
14827)
+++ django/trunk/django/views/generic/list.py   2010-12-05 04:32:36 UTC (rev 
14828)
@@ -10,6 +10,7 @@
 model = None
 paginate_by = None
 context_object_name = None
+paginator_class = Paginator
 
 def get_queryset(self):
 """
@@ -32,7 +33,7 @@
 Paginate the queryset, if needed.
 """
 if queryset.count() > page_size:
-paginator = Paginator(queryset, page_size, 
allow_empty_first_page=self.get_allow_empty())
+paginator = self.get_paginator(queryset, page_size, 
allow_empty_first_page=self.get_allow_empty())
 page = self.kwargs.get('page', None) or 
self.request.GET.get('page', 1)
 try:
 page_number = int(page)
@@ -55,6 +56,12 @@
 """
 return self.paginate_by
 
+def get_paginator(self, queryset, per_page, orphans=0, 
allow_empty_first_page=True):
+"""
+Return an instance of the paginator for this view.
+"""
+return self.paginator_class(queryset, per_page, orphans=orphans, 
allow_empty_first_page=allow_empty_first_page)
+
 def get_allow_empty(self):
 """
 Returns ``True`` if the view should display empty lists, and ``False``

Modified: django/trunk/docs/ref/class-based-views.txt
===
--- django/trunk/docs/ref/class-based-views.txt 2010-12-05 02:09:29 UTC (rev 
14827)
+++ django/trunk/docs/ref/class-based-views.txt 2010-12-05 04:32:36 UTC (rev 
14828)
@@ -305,6 +305,14 @@
 expect either a ``page`` query string parameter (via ``GET``) or a
 ``page`` variable specified in the URLconf.
 
+.. attribute:: paginator_class
+
+   The paginator class to be used for pagination. By default,
+   :class:`django.core.paginator.Paginator` is used. If the custom 
paginator
+   class doesn't have the same constructor interface as
+   :class:`django.core.paginator.Paginator`, you will also need to
+   provide an implementation for :meth:`MultipleObjectMixin.get_paginator`.
+
 .. attribute:: context_object_name
 
 Designates the name of the variable to use in the context.
@@ -329,6 +337,11 @@
 pagination. By default this simply returns the value of
 :attr:`MultipleObjectMixin.paginate_by`.
 
+.. method:: get_paginator(queryset, queryset, per_page, orphans=0, 
allow_empty_first_page=True)
+
+Returns an instance of the paginator to use for this view. By default,
+instantiates an instance of :attr:`paginator_class`.
+
 .. method:: get_allow_empty()
 
 Return a boolean specifying whether to display the page if no objects

Modified: django/trunk/tests/regressiontests/generic_views/list.py
===
--- django/trunk/tests/regressiontests/generic_views/list.py2010-12-05 
02:09:29 UTC (rev 14827)
+++ django/trunk/tests/regressiontests/generic_views/list.py2010-12-05 
04:32:36 UTC (rev 14828)
@@ -2,8 +2,8 @@
 from django.test import TestCase
 
 from regressiontests.generic_views.models import Author
+from regressiontests.generic_views.views import CustomPaginator
 
-
 class ListViewTests(TestCase):
 fixtures = ['generic-views-test-data.json']
 urls = 'regressiontests.generic_views.urls'
@@ -86,6 +86,21 @@
 res = self.client.get('/list/authors/paginated/?page=frog')
 self.assertEqual(res.status_code, 404)
 
+def test_paginated_custom_paginator_class(self):
+self._make_authors(7)
+res = self.client.get('/list/authors/paginated/custom_class/')
+self.assertEqual(res.status_code, 200)
+self.assertIsInstance(res.context['paginator'], CustomPaginator)
+# Custom pagination allows for 2 orphans on a page size of 5
+self.assertEqual(len(res.context['object_list']), 7)
+
+def test_paginated_custom_paginator_constructor(self):
+self._make_authors(7)
+res = self.client.get('/list/authors/paginated/custom_constructor/')
+self.assertEqual(res.status_code, 200)
+# Custom pagination allows for 2 orphans on a page size of 5
+self.assertEqual(len(res.context['object_list']), 7)
+
 def test_allow_empty_false(self):
 

Re: [Django] #14410: django.db.models.fields.__init__.py class Field.validate failed

[Django]

#14410: django.db.models.fields.__init__.py class Field.validate failed
--+-
  Reporter:  ctao | Owner:  
Status:  closed   | Milestone:  
 Component:  ORM aggregation  |   Version:  1.2 
Resolution:  invalid  |  Keywords:  db models Field validate
 Stage:  Unreviewed   | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by mariarchi):

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

Comment:

 I'm afraid it's not entirely clear what are you trying to achieve. Please
 open a thread on django-developers if you have a feature suggestion and
 want some feedback.

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

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

Re: [Django] #14041: Templates in function calls for sitemap

[Django]

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

  * owner:  julien =>
  * has_patch:  0 => 1

Comment:

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

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

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

Re: [Django] #13724: Calling QuerySet.delete() through a relation the DB router is ignored.

[Django]

#13724: Calling QuerySet.delete() through a relation the DB router is ignored.
---+
  Reporter:  Chris Targett   | Owner:  nobody 
Status:  closed| Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  1.2
Resolution:  invalid   |  Keywords:  multidb
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by mariarchi):

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

Comment:

 I'm pretty sure it belongs to django-multidb-router ticket tracker. Please
 reopen if I'm wrong.

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

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

Re: [Django] #14800: Development server should NOT elide favicon from the logs

[Django]

#14800: Development server should NOT elide favicon from the logs
+---
  Reporter:  RoySmith   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  django-admin.py runserver  |   Version:  1.2
Resolution: |  Keywords:  logging
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  1  |  
+---
Changes (by mariarchi):

  * stage:  Unreviewed => Accepted

Comment:

 Looks like a good idea to me.

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

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

Re: [Django] #14066: Shouldn't ModelFormMetaclass be public for inheritance issues?

[Django]

#14066: Shouldn't ModelFormMetaclass  be public for inheritance issues?
-+--
  Reporter:  rm4dillo| Owner:  nobody
Status:  closed  | Milestone:  2.0   
 Component:  Core framework  |   Version:  1.2   
Resolution:  invalid |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mariarchi):

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

Comment:

 You can still import it, _ _ all _ _ does not impose restrictions on
 importing.

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

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

Re: [Django] #14610: fixtures should be able to specify their database

[Django]

#14610: fixtures should be able to specify their database
+---
  Reporter:  cyberlogi  | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by mariarchi):

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

Comment:

 Sounds like a reasonable idea to me. Can you propose a syntax for fixtures
 to specify DB?

 P.S. You don't actually need to explicitly "return None", function which
 is not returning anything is returning None anyway.

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

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

[Django] #14836: Improve semantics of docs:

[Django]

#14836: Improve semantics of docs:
---+
 Reporter:  cogat  |   Owner:  cogat 
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords:  sprintdec2010  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Everything is mostly good, except:

  * #14835 and other things that can be fixed in the doc source file

  * 'This document describes Django 1.2. For development docs, go here.' is
 an ``. It should be a ``.

  * This one came up when viewing the docs with site CSS turned off.
 Admonition titles are 'p.admonition-title'. I suggest including 'strong',
 rather than a heading, since it isn't context-free enough to be a heading
 (the HTML5 tag would be ``), but it needs to be higher up the chain
 than plain text.

 I will patch these when we establish the way to update djangoproject's
 base.css file (discussion at http://groups.google.com/group/django-
 developers/browse_thread/thread/2d14c16358069b37)

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

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

Re: [Django] #14834: Colour issues in CSS - particularly documentation

[Django]

#14834: Colour issues in CSS - particularly documentation
+---
  Reporter:  cogat  | Owner:  cogat
Status:  new| Milestone:  1.3  
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:  sprintdec2010
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  1  |  
+---
Changes (by gabrielhurley):

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

Comment:

 Good call on the contrast check. I'd made a mental note of the grey on
 green before, but had never gotten around to opening a ticket for it.

 My concern with the current patch is that it makes the various colors all
 pretty similar. They all tend towards blending in with the black text, and
 at that point you've lost the advantage of code highlighting.

 One thing I think might help would be lightening the background color of
 the code blocks rather than darkening the foreground colors. (That'd mean
 changing `pre, .literal-block`'s `background-color` property)

 So, whatever can be done to increase contrast without losing the clear
 distinction of the colors would improve this patch IMHO.

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

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

Re: [Django] #14835: Indents for descriptions of documentation attributes

[Django]

#14835: Indents for descriptions of documentation attributes
+---
  Reporter:  cogat  | Owner:  cogat
Status:  new| Milestone:   
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:  sprintdec2010
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by cogat):

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

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

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

[Django] #14835: Indents for descriptions of documentation attributes

[Django]

#14835: Indents for descriptions of documentation attributes
---+
 Reporter:  cogat  |   Owner:  cogat 
   Status:  new|   Milestone:  1.3   
Component:  Documentation  | Version:  1.2   
 Keywords:  sprintdec2010  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In docs/ref/contrib/admin/index.txt, the attributes for ModelAdmin aren't
 indented. The effect in the resulting HTML is that `` elements are
 created with no `` elements. Instead, there is an empty ``, the
 enclosing `` is terminated and the definition appears in the following
 ``. For InlineModelAdmin, the markup is correct, but the styling
 indents the dt, which I guess looks ugly to some.

 Both problems are addressed by modifying djangoproject CSS so that ``
 does not appear indented, and also to fix the markup so that ``s are
 populated. I'll do so once we establish a way to update djangoproject's
 css (discussion at http://groups.google.com/group/django-
 developers/browse_thread/thread/2d14c16358069b37).

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

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

Re: [Django] #14820: Use `TextField` instead of `PositiveIntegerField` in docs and examples for generic relations.

[Django]

#14820: Use `TextField` instead of `PositiveIntegerField` in docs and examples 
for
generic relations.
+---
  Reporter:  mrmachine  | Owner:
 
Status:  new| Milestone:  1.3   
 
 Component:  Documentation  |   Version:  SVN   
 
Resolution: |  Keywords:  generic relation 
genericforeignkey object_id type textfield
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  1  |  
+---
Changes (by gabrielhurley):

  * needs_better_patch:  0 => 1
  * stage:  Unreviewed => Accepted
  * milestone:  => 1.3

Comment:

 Being realistic, whatever ends up in the example there is going to be
 copied and pasted and become the official recommendation despite whatever
 is said around it.

 I suppose one of my problems with recommending the use of a `TextField` is
 that you're implicitly trading wider compatibility for a performance
 penalty (varying by DB): `text` columns often use more memory, can be less
 performant when returned by DB queries, and can have indexing woes
 depending on the database configuration... the best practice performance-
 wise is to use a field of the appropriate type (`CharField`,
 `IntegerField`, or `PositiveIntegerField`) if you know for a fact that the
 values will always be of that type.

 What it all boils down to is that there isn't one right answer here.

 If someone feels they have enough to say to write a whole section on best
 practices for using GFK's in reusable apps I'd love to see it.

 If not, then I'd rather see this patch in reverse: keep the primary
 recommendation as "use a field of the appropriate type" and add a big
 solid note that authors of reusable apps may want to use a `TextField` in
 order to support both integer and non-integer PK's. The point is
 definitely important, though; I think it could have an `admonition`
 directive to call attention to it.

 And in the end, I firmly believe there are more people reading this
 section of the docs just trying to make their own Django app work than
 there are folks trying to write reusable apps that are having bugs because
 their GFK didn't support a non-integer PK.

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

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

Re: [Django] #14834: Colour issues in CSS - particularly documentation

[Django]

#14834: Colour issues in CSS - particularly documentation
+---
  Reporter:  cogat  | Owner:  cogat
Status:  new| Milestone:  1.3  
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:  sprintdec2010
 Stage:  Unreviewed | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by cogat):

 And the CSS audit is #11930.

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

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

Re: [Django] #14834: Colour issues in CSS - particularly documentation

[Django]

#14834: Colour issues in CSS - particularly documentation
+---
  Reporter:  cogat  | Owner:  cogat
Status:  new| Milestone:  1.3  
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:  sprintdec2010
 Stage:  Unreviewed | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by cogat):

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

Comment:

 The questions/feedback is in the footer by the way.

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

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

[Django] #14834: Colour issues in CSS - particularly documentation

[Django]

#14834: Colour issues in CSS - particularly documentation
---+
 Reporter:  cogat  |   Owner:  cogat 
   Status:  new|   Milestone:  1.3   
Component:  Documentation  | Version:  1.2   
 Keywords:  sprintdec2010  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 As part of a CSS audit (qv #11390) I ran a colour contrast checker over
 docs.djangoproject.com, and the issues it highlighted were:

   - code snippets: grey text on green (e.g. comments, 'self': low
 contrast)
   - code snippets: orange text on green (e.g. strings: low contrast for
 colour blind visitors)
   - "Questions/feedback: orange text on green (links: low contrast for
 colour-blind visitors)

 The attached patch for pygments.css corrects the code snippets. However
 there are no css files in the djangoproject.com repository so I'm unsure
 who will

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

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

Re: [Django] #11206: The floatformat template tag doesn't work with a value of 0 and a precision of 7 or higher.

[Django]

#11206: The floatformat template tag doesn't work with a value of 0 and a 
precision
of 7 or higher.
--+-
  Reporter:  mrmachine| Owner:  nobody  
 
Status:  new  | Milestone:  1.3 
 
 Component:  Template system  |   Version:  SVN 
 
Resolution:   |  Keywords:  floatformat precision 7 
decimal sprintdec2010
 Stage:  Accepted | Has_patch:  1   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Changes (by mrmachine):

  * keywords:  floatformat precision 7 decimal => floatformat precision 7
   decimal sprintdec2010
  * has_patch:  0 => 1
  * milestone:  => 1.3

Comment:

 Just uploaded a patch that fixes this with tests. It reconstructs the
 number from the `DecimalTuple` object to avoid conversion into scientific
 format. I don't think the implementation is too complex or difficult to
 maintain. I don't think docs are needed as this is a fix to unexpected
 behaviour.

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

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

Re: [Django] #14661: A couple of MySQL/MyISAM test failures

[Django]

#14661: A couple of MySQL/MyISAM test failures
+---
  Reporter:  kmtracey   | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Testing framework  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 This is obviously a blocker for the 1.3 release.

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

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

[Changeset] r14827 - django/branches/releases/1.2.X/django/contrib/sitemaps/tests

[noreply]

Author: russellm
Date: 2010-12-04 20:09:29 -0600 (Sat, 04 Dec 2010)
New Revision: 14827

Modified:
   django/branches/releases/1.2.X/django/contrib/sitemaps/tests/basic.py
Log:
[1.2.X] Fixed #14833 -- Skip the sitemaps localization test if i18n isn't 
enabled. Thanks to Julien Phalip for the report and patch.

Backport of r14826 from trunk.

Modified: django/branches/releases/1.2.X/django/contrib/sitemaps/tests/basic.py
===
--- django/branches/releases/1.2.X/django/contrib/sitemaps/tests/basic.py   
2010-12-05 02:07:46 UTC (rev 14826)
+++ django/branches/releases/1.2.X/django/contrib/sitemaps/tests/basic.py   
2010-12-05 02:09:29 UTC (rev 14827)
@@ -33,19 +33,20 @@
 
 """ % date.today().strftime('%Y-%m-%d'))
 
-def test_localized_priority(self):
-"The priority value should not be localized (Refs #14164)"
-# Localization should be active
-settings.USE_L10N = True
-activate('fr')
-self.assertEqual(u'0,3', localize(0.3))
+if settings.USE_I18N:
+def test_localized_priority(self):
+"The priority value should not be localized (Refs #14164)"
+# Localization should be active
+settings.USE_L10N = True
+activate('fr')
+self.assertEqual(u'0,3', localize(0.3))
 
-# Retrieve the sitemap. Check that priorities
-# haven't been rendered in localized format
-response = self.client.get('/simple/sitemap.xml')
-self.assertContains(response, '0.5')
-self.assertContains(response, '%s' % 
date.today().strftime('%Y-%m-%d'))
-deactivate()
+# Retrieve the sitemap. Check that priorities
+# haven't been rendered in localized format
+response = self.client.get('/simple/sitemap.xml')
+self.assertContains(response, '0.5')
+self.assertContains(response, '%s' % 
date.today().strftime('%Y-%m-%d'))
+deactivate()
 
 def test_generic_sitemap(self):
 "A minimal generic sitemap can be rendered"

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

Re: [Django] #13900: New admin feature: Delete and replace with existing ocject

[Django]

#13900: New admin feature: Delete and replace with existing ocject
-+--
  Reporter:  riccardodivirgilio  | Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  django.contrib.admin|   Version:  SVN  
 
Resolution:  |  Keywords:  admin, 
delete_view
 Stage:  Design decision needed  | Has_patch:  0
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by mariarchi):

  * stage:  Unreviewed => Design decision needed

Comment:

 might be useful

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

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

[Changeset] r14826 - django/trunk/django/contrib/sitemaps/tests

[noreply]

Author: russellm
Date: 2010-12-04 20:07:46 -0600 (Sat, 04 Dec 2010)
New Revision: 14826

Modified:
   django/trunk/django/contrib/sitemaps/tests/basic.py
Log:
Fixed #14833 -- Skip the sitemaps localization test if i18n isn't enabled. 
Thanks to Julien Phalip for the report and patch.

Modified: django/trunk/django/contrib/sitemaps/tests/basic.py
===
--- django/trunk/django/contrib/sitemaps/tests/basic.py 2010-12-05 01:54:15 UTC 
(rev 14825)
+++ django/trunk/django/contrib/sitemaps/tests/basic.py 2010-12-05 02:07:46 UTC 
(rev 14826)
@@ -34,6 +34,7 @@
 
 """ % date.today().strftime('%Y-%m-%d'))
 
+@skipUnless(settings.USE_I18N, "Internationalization is not enabled")
 def test_localized_priority(self):
 "The priority value should not be localized (Refs #14164)"
 # Localization should be active

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

Re: [Django] #13978: Allow inline js/css in forms.Media

[Django]

#13978: Allow inline js/css in forms.Media
-+--
  Reporter:  nathforge   | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  0   |  
-+--
Changes (by mariarchi):

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

Comment:

 Needs tests and docs [and maybe design decision]

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

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

Re: [Django] #14772: Reversing a URL with optional arguments fails

[Django]

#14772: Reversing a URL with optional arguments fails
-+--
  Reporter:  robhudson   | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Core framework  |   Version:  1.2   
Resolution:  |  Keywords:  reverse, sprintdec2010
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by julien):

  * keywords:  reverse => reverse, sprintdec2010
  * stage:  Unreviewed => Accepted
  * milestone:  => 1.3

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

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

Re: [Django] #13977: Indeterministic PicklingError

[Django]

#13977: Indeterministic PicklingError
+---
  Reporter:  etam   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Serialization  |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Changes (by mariarchi):

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

Comment:

 => it's related to mod_wsgi, not Django. Moreover, using pickling in your
 web application is usually a bad idea, because pickled files are easily
 corruptible and can cause security issues.

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

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

Re: [Django] #10863: Email full stack traces like in the debug error pages

[Django]

#10863: Email full stack traces like in the debug error pages
-+--
  Reporter:  boxed   | Owner:  brodie  
Status:  new | Milestone:  1.3 
 Component:  Core framework  |   Version:  SVN 
Resolution:  |  Keywords:  stack, errors, email
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  1   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by brodie):

  * owner:  nobody => brodie
  * needs_better_patch:  1 => 0
  * needs_tests:  1 => 0
  * milestone:  => 1.3

Comment:

 I've attached two patches for this feature.

 The first patch cleans up the debug exception template so that pretty
 printed values retain their whitespace. The second patch is based on
 boxed's and robhudson's work but updated for Django 1.3 and with some
 minor improvements.

 AdminEmailHandler has been updated to send out HTML emails, and
 ExceptionReporter has grown a new is_email keyword argument. If is_email
 is True, JS and Pastebin-related code is omitted from the template. If
 request is None, request-related info is also omitted.

 I've included robhudson's doc updates, but we should probably also update
 the AdminEmailHandler section of docs/topics/logging.txt to mention this
 new behavior.

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

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

Re: [Django] #14664: MiddlewareNotUsed should display a warning

[Django]

#14664: MiddlewareNotUsed should display a warning
-+--
  Reporter:  teserak | Owner:  nobody   
Status:  new | Milestone:   
 Component:  Core framework  |   Version:  1.2  
Resolution:  |  Keywords:  sprintdec2010
 Stage:  Accepted| Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by julien):

  * keywords:  => sprintdec2010
  * stage:  Unreviewed => Accepted
  * milestone:  1.3 =>

Comment:

 This would be reasonable if DEBUG=True. This is a feature request, so
 removing from the 1.3 milestone which is now focused on bug fixing.

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

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

Re: [Django] #14028: setting db_column to same value as another column should not validate

[Django]

#14028: setting db_column to same value as another column should not validate
---+
  Reporter:  akaariai  | Owner:  tttallis   
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.2
  
Resolution:|  Keywords:  
validation, sprintdec2010
 Stage:  Accepted  | Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by tttallis):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * summary:  setting db_column to same value than another column should
  not validate => setting db_column to same value
  as another column should not validate
  * owner:  nobody => tttallis
  * keywords:  validation => validation, sprintdec2010
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

Comment:

 Agreed, let's fix it. I'll work up a patch.

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

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

Re: [Django] #14369: TEMPLATE_STRING_IF_INVALID settable per template rendering

[Django]

#14369: TEMPLATE_STRING_IF_INVALID settable per template rendering
-+--
  Reporter:  vanschelven | Owner:  nobody
Status:  new | Milestone:
 Component:  Template system |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mariarchi):

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

Comment:

 I think it's arguable whether this feature is a good idea. I would
 recommend raising a discussion on django-developers

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

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

[Changeset] r14825 - in django/branches/releases/1.2.X: django/test docs/ref docs/releases docs/topics tests/regressiontests/test_runner

[noreply]

Author: russellm
Date: 2010-12-04 19:54:15 -0600 (Sat, 04 Dec 2010)
New Revision: 14825

Added:
   django/branches/releases/1.2.X/docs/releases/1.2.4.txt
Modified:
   django/branches/releases/1.2.X/django/test/simple.py
   django/branches/releases/1.2.X/docs/ref/settings.txt
   django/branches/releases/1.2.X/docs/releases/index.txt
   django/branches/releases/1.2.X/docs/topics/testing.txt
   django/branches/releases/1.2.X/tests/regressiontests/test_runner/tests.py
Log:
[1.2.X] Fixed #14799 -- Provided a full solution for test database creation 
order problems.

Backport of r14822, r14823 and r14824 from trunk.

Modified: django/branches/releases/1.2.X/django/test/simple.py
===
--- django/branches/releases/1.2.X/django/test/simple.py2010-12-05 
01:23:23 UTC (rev 14824)
+++ django/branches/releases/1.2.X/django/test/simple.py2010-12-05 
01:54:15 UTC (rev 14825)
@@ -3,11 +3,18 @@
 import unittest
 
 from django.conf import settings
+from django.core.exceptions import ImproperlyConfigured
 from django.db.models import get_app, get_apps
 from django.test import _doctest as doctest
 from django.test.utils import setup_test_environment, teardown_test_environment
 from django.test.testcases import OutputChecker, DocTestRunner, TestCase
 
+
+try:
+all
+except NameError:
+from django.utils.itercompat import all
+
 # The module name for tests outside models.py
 TEST_MODULE = 'tests'
 
@@ -222,7 +229,41 @@
 bins[0].addTests(bins[i+1])
 return bins[0]
 
+def dependency_ordered(test_databases, dependencies):
+"""Reorder test_databases into an order that honors the dependencies
+described in TEST_DEPENDENCIES.
+"""
+ordered_test_databases = []
+resolved_databases = set()
+while test_databases:
+changed = False
+deferred = []
 
+while test_databases:
+signature, aliases = test_databases.pop()
+dependencies_satisfied = True
+for alias in aliases:
+if alias in dependencies:
+if all(a in resolved_databases for a in 
dependencies[alias]):
+# all dependencies for this alias are satisfied
+dependencies.pop(alias)
+resolved_databases.add(alias)
+else:
+dependencies_satisfied = False
+else:
+resolved_databases.add(alias)
+
+if dependencies_satisfied:
+ordered_test_databases.append((signature, aliases))
+changed = True
+else:
+deferred.append((signature, aliases))
+
+if not changed:
+raise ImproperlyConfigured("Circular dependency in 
TEST_DEPENDENCIES")
+test_databases = deferred
+return ordered_test_databases
+
 class DjangoTestSuiteRunner(object):
 def __init__(self, verbosity=1, interactive=True, failfast=True, **kwargs):
 self.verbosity = verbosity
@@ -260,6 +301,7 @@
 # and which ones are test mirrors or duplicate entries in DATABASES
 mirrored_aliases = {}
 test_databases = {}
+dependencies = {}
 for alias in connections:
 connection = connections[alias]
 if connection.settings_dict['TEST_MIRROR']:
@@ -276,21 +318,17 @@
 connection.settings_dict['ENGINE'],
 connection.settings_dict['NAME'],
 ), []).append(alias)
-
-# Re-order the list of databases to create, making sure the default
-# database is first. Otherwise, creation order is semi-random (i.e. 
-# dict ordering dependent).
-dbs_to_create = []
-for dbinfo, aliases in test_databases.items():
-if DEFAULT_DB_ALIAS in aliases:
-dbs_to_create.insert(0, (dbinfo, aliases))
-else:
-dbs_to_create.append((dbinfo, aliases))
-
-# Final pass -- actually create the databases.
+
+if 'TEST_DEPENDENCIES' in connection.settings_dict:
+dependencies[alias] = 
connection.settings_dict['TEST_DEPENDENCIES']
+else:
+if alias != 'default':
+dependencies[alias] = 
connection.settings_dict.get('TEST_DEPENDENCIES', ['default'])
+
+# Second pass -- actually create the databases.
 old_names = []
 mirrors = []
-for (host, port, engine, db_name), aliases in dbs_to_create:
+for (host, port, engine, db_name), aliases in 
dependency_ordered(test_databases.items(), dependencies):
 # Actually create the database for the first connection
 connection = connections[aliases[0]]
 old_names.append((connection, db_name, True))

Modified: django/branches/releases/1.2.X/docs/ref/settings.txt

Re: [Django] #14046: Template tag errors masked if including based on context variable name

[Django]

#14046: Template tag errors masked if including based on context variable name
+---
  Reporter:  defcube| Owner:  mariarchi 
  
Status:  assigned   | Milestone:
  
 Component:  Template system|   Version:  1.2   
  
Resolution: |  Keywords:  template exception 
sprintdec2010
 Stage:  Ready for checkin  | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Comment (by mariarchi):

 Russel says "ready for check-in"

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

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

Re: [Django] #14046: Template tag errors masked if including based on context variable name

[Django]

#14046: Template tag errors masked if including based on context variable name
+---
  Reporter:  defcube| Owner:  mariarchi 
  
Status:  assigned   | Milestone:
  
 Component:  Template system|   Version:  1.2   
  
Resolution: |  Keywords:  template exception 
sprintdec2010
 Stage:  Ready for checkin  | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by mariarchi):

  * keywords:  template exception => template exception sprintdec2010
  * needs_tests:  1 => 0
  * stage:  Accepted => Ready for checkin

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

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

Re: [Django] #14555: Session loss with psycopg2 db backend

[Django]

#14555: Session loss with psycopg2 db backend
--+-
  Reporter:  tomaszswiderski  | Owner:  nobody   
Status:  closed   | Milestone:   
 Component:  django.contrib.sessions  |   Version:  1.2  
Resolution:  worksforme   |  Keywords:  sprintdec2010
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by bretth):

  * status:  new => closed
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * keywords:  => sprintdec2010
  * needs_docs:  => 0
  * resolution:  => worksforme
  * stage:  Unreviewed => Accepted

Comment:

 I can't reproduce this error. It works fine for me.

 You'll need to do further investigation on why it doesn't work for you. I
 suggest loading something like django-devserver and having a look at the
 SQL that is setting the expiry datetime and try executing that statement
 directly using psycopg2 (outside of django), and then seeing what is
 stored on the db.

 I also can't see that there is any difference in the connection handling
 of timezones in 1.2 from 1.1. Perhaps you can put some logging on the TIME
 ZONE settings on connection creation.

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

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

Re: [Django] #14022: context_processors debug() Fails with no DB Backend

[Django]

#14022: context_processors debug() Fails with no DB Backend
-+--
  Reporter:  dvine   | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Core framework  |   Version:  1.2  
Resolution:  worksforme  |  Keywords:  sprintdec2010
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by julien):

  * status:  new => closed
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * keywords:  => sprintdec2010
  * needs_docs:  => 0
  * resolution:  => worksforme

Comment:

 If you do not specify any DATABASE_ settings then the connection is
 set to a django.db.backends.dummy.base.DatabaseWrapper instance, which
 does have a `queries` attribute (an empty list). Therefore no exception is
 raised in this context processor. For that reason (and after discussing
 this with russellm) I'm closing this as worksforme.

 I do not doubt you're having an issue with this, but if you'd like it to
 be addressed you need to provide more information about how to reproduce
 it:

  * What do you mean by "the debug() function fails at"? What exception is
 raised?
  * What do you mean by "if no database backend is defined"? As I said, if
 you do not specify any database settings then it should just work. So what
 are you doing to disable (or not enable) the database backend in your
 project?

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

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

Re: [Django] #11930: Django docs styles confuse H3 & H4

[Django]

#11930: Django docs styles confuse H3 & H4
--+-
  Reporter:  da...@whatcould.com  | Owner:  cogat
Status:  assigned | Milestone:  1.3  
 Component:  Documentation|   Version:  1.1  
Resolution:   |  Keywords:  sprintdec2010
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Comment (by cogat):

 It seems the core reason for the h3/h4 discrepancy is that h4 has to
 compete with Verdana bold, which is VERY black. See
 http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#filters-
 and-auto-escaping for a typical example.

 The patch I just attached reduces the prominence of Verdana bold in
 documentation, allowing h4 to be brought into alignment with the other
 headings. The only way of doing this that doesn't look strange is to make
 the color of  paler.

 I have also toned down the appearance of "New in Django 1.x" callouts.
 Currently they are way too prominent, competing with headings. The
 information is too ambient/meta for such visual dominance, especially
 given the version note heading every documentation page.

 HOWEVER, the base.css that the patch works against ISN'T in the repository
 - I had to save it from the site directly. Who is the custodian of this
 file? (NB the Sphinx theme CSS doesn't have the h3/h4 problem).

 I'll attach screenshots of the changes now.

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

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

[Changeset] r14824 - django/trunk/docs/ref

[noreply]

Author: russellm
Date: 2010-12-04 19:23:23 -0600 (Sat, 04 Dec 2010)
New Revision: 14824

Modified:
   django/trunk/docs/ref/settings.txt
Log:
Added versionadded markup to the TEST_DEPENDENCIES setting.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2010-12-05 01:03:39 UTC (rev 14823)
+++ django/trunk/docs/ref/settings.txt  2010-12-05 01:23:23 UTC (rev 14824)
@@ -432,6 +432,8 @@
 TEST_DEPENDENCIES
 ~
 
+.. versionadded:: 1.3
+
 Default: ``['default']``, for all databases other than ``default``,
 which has no dependencies.
 

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

[Changeset] r14823 - in django/trunk/docs: ref topics

[noreply]

Author: russellm
Date: 2010-12-04 19:03:39 -0600 (Sat, 04 Dec 2010)
New Revision: 14823

Modified:
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/topics/testing.txt
Log:
Corrected incomplete and incorrect docs from r14822.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2010-12-05 00:44:34 UTC (rev 14822)
+++ django/trunk/docs/ref/settings.txt  2010-12-05 01:03:39 UTC (rev 14823)
@@ -427,6 +427,18 @@
 
 .. _MySQL manual: MySQL_
 
+.. setting:: TEST_DEPENDENCIES
+
+TEST_DEPENDENCIES
+~
+
+Default: ``['default']``, for all databases other than ``default``,
+which has no dependencies.
+
+The creation-order dependencies of the database. See the documentation
+on :ref:`controlling the creation order of test databases
+` for details.
+
 .. setting:: TEST_MIRROR
 
 TEST_MIRROR

Modified: django/trunk/docs/topics/testing.txt
===
--- django/trunk/docs/topics/testing.txt2010-12-05 00:44:34 UTC (rev 
14822)
+++ django/trunk/docs/topics/testing.txt2010-12-05 01:03:39 UTC (rev 
14823)
@@ -473,22 +473,22 @@
 DATABASES = {
 'default': {
  # ... db settings
- TEST_DEPENDENCIES = ['diamonds']
+ 'TEST_DEPENDENCIES': ['diamonds']
 },
 'diamonds': {
 # ... db settings
-}
+},
 'clubs': {
 # ... db settings
-TEST_DEPENDENCIES = ['diamonds']
-}
+'TEST_DEPENDENCIES': ['diamonds']
+},
 'spades': {
 # ... db settings
-TEST_DEPENDENCIES = ['diamonds','hearts']
-}
+'TEST_DEPENDENCIES': ['diamonds','hearts']
+},
 'hearts': {
 # ... db settings
-TEST_DEPENDENCIES = ['diamonds','clubs']
+'TEST_DEPENDENCIES': ['diamonds','clubs']
 }
 }
 

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

Re: [Django] #14766: ordering by a field that does not exists returns an empty QuerySet

[Django]

#14766: ordering by a field that does not exists returns an empty QuerySet
---+
  Reporter:  robhudson | Owner:  nobody 
   
Status:  reopened  | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  
sprintdec2010 order_by
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  1 |  
---+
Changes (by Aramgutang):

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

Comment:

 I added a patch, but I'm not happy with its DRYness. All tests in the
 suite pass. I'll leave it to someone else to improve upon.

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

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

[Changeset] r14822 - in django/trunk: django/test docs/topics tests/regressiontests/test_runner

[noreply]

Author: russellm
Date: 2010-12-04 18:44:34 -0600 (Sat, 04 Dec 2010)
New Revision: 14822

Modified:
   django/trunk/django/test/simple.py
   django/trunk/docs/topics/testing.txt
   django/trunk/tests/regressiontests/test_runner/tests.py
Log:
Fixed #14799 -- Provided a full solution for test database creation order 
problems.

Modified: django/trunk/django/test/simple.py
===
--- django/trunk/django/test/simple.py  2010-12-04 22:32:28 UTC (rev 14821)
+++ django/trunk/django/test/simple.py  2010-12-05 00:44:34 UTC (rev 14822)
@@ -2,12 +2,21 @@
 import signal
 
 from django.conf import settings
+from django.core.exceptions import ImproperlyConfigured
 from django.db.models import get_app, get_apps
 from django.test import _doctest as doctest
 from django.test.utils import setup_test_environment, teardown_test_environment
 from django.test.testcases import OutputChecker, DocTestRunner, TestCase
 from django.utils import unittest
 
+try:
+all
+except NameError:
+from django.utils.itercompat import all
+
+
+__all__ = ('DjangoTestRunner', 'DjangoTestSuiteRunner', 'run_tests')
+
 # The module name for tests outside models.py
 TEST_MODULE = 'tests'
 
@@ -183,7 +192,41 @@
 bins[0].addTests(bins[i+1])
 return bins[0]
 
+def dependency_ordered(test_databases, dependencies):
+"""Reorder test_databases into an order that honors the dependencies
+described in TEST_DEPENDENCIES.
+"""
+ordered_test_databases = []
+resolved_databases = set()
+while test_databases:
+changed = False
+deferred = []
 
+while test_databases:
+signature, aliases = test_databases.pop()
+dependencies_satisfied = True
+for alias in aliases:
+if alias in dependencies:
+if all(a in resolved_databases for a in 
dependencies[alias]):
+# all dependencies for this alias are satisfied
+dependencies.pop(alias)
+resolved_databases.add(alias)
+else:
+dependencies_satisfied = False
+else:
+resolved_databases.add(alias)
+
+if dependencies_satisfied:
+ordered_test_databases.append((signature, aliases))
+changed = True
+else:
+deferred.append((signature, aliases))
+
+if not changed:
+raise ImproperlyConfigured("Circular dependency in 
TEST_DEPENDENCIES")
+test_databases = deferred
+return ordered_test_databases
+
 class DjangoTestSuiteRunner(object):
 def __init__(self, verbosity=1, interactive=True, failfast=True, **kwargs):
 self.verbosity = verbosity
@@ -222,6 +265,7 @@
 # and which ones are test mirrors or duplicate entries in DATABASES
 mirrored_aliases = {}
 test_databases = {}
+dependencies = {}
 for alias in connections:
 connection = connections[alias]
 if connection.settings_dict['TEST_MIRROR']:
@@ -238,21 +282,17 @@
 connection.settings_dict['ENGINE'],
 connection.settings_dict['NAME'],
 ), []).append(alias)
-
-# Re-order the list of databases to create, making sure the default
-# database is first. Otherwise, creation order is semi-random (i.e. 
-# dict ordering dependent).
-dbs_to_create = []
-for dbinfo, aliases in test_databases.items():
-if DEFAULT_DB_ALIAS in aliases:
-dbs_to_create.insert(0, (dbinfo, aliases))
-else:
-dbs_to_create.append((dbinfo, aliases))
-
-# Final pass -- actually create the databases.
+
+if 'TEST_DEPENDENCIES' in connection.settings_dict:
+dependencies[alias] = 
connection.settings_dict['TEST_DEPENDENCIES']
+else:
+if alias != 'default':
+dependencies[alias] = 
connection.settings_dict.get('TEST_DEPENDENCIES', ['default'])
+
+# Second pass -- actually create the databases.
 old_names = []
 mirrors = []
-for (host, port, engine, db_name), aliases in dbs_to_create:
+for (host, port, engine, db_name), aliases in 
dependency_ordered(test_databases.items(), dependencies):
 # Actually create the database for the first connection
 connection = connections[aliases[0]]
 old_names.append((connection, db_name, True))

Modified: django/trunk/docs/topics/testing.txt
===
--- django/trunk/docs/topics/testing.txt2010-12-04 22:32:28 UTC (rev 
14821)
+++ django/trunk/docs/topics/testing.txt2010-12-05 00:44:34 UTC (rev 
14822)
@@ -454,6 +454,53 @@
 the same database, not because 

Re: [Django] #14041: Templates in function calls for sitemap

[Django]

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

  * stage:  Unreviewed => Accepted

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

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

Re: [Django] #14041: Templates in function calls for sitemap

[Django]

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

  * keywords:  sitemaps => sitemaps, sprintdec2010
  * owner:  nobody => julien

Comment:

 This makes sense. Patch coming soon.

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

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

[Django] #14833: Sitemaps tests fail if run from your project and USE_I18N is False

[Django]

#14833: Sitemaps tests fail if run from your project and USE_I18N is False
---+
 Reporter:  julien |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Contrib apps   | Version:  1.2   
 Keywords:  sprintdec2010  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Here's what you get:

 {{{
 FAIL: test_localized_priority
 (django.contrib.sitemaps.tests.basic.SitemapTests)
 The priority value should not be localized (Refs #14164)
 --
 Traceback (most recent call last):
   File
 
"/Users/julien/.virtualenvs/djangotests/src/django/django/contrib/sitemaps/tests/basic.py",
 line 45, in test_localized_priority
 self.assertEqual(u'0,3', localize(0.3))
 AssertionError: u'0,3' != u'0.3'
 - 0,3+ 0.3
 }}}

 Turning `USE_I18N` to True in `setUp()` doesn't work because it's already
 too late: the translations methods have already been loaded by then based
 on the project's settings. As discussed with Russ, the solution here is to
 simply skip the test.

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

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

Re: [Django] #9964: Transaction middleware closes the transaction only when it's marked as dirty

[Django]

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---+
  Reporter:  ishirav   | Owner:  
mtredinnick 
Status:  assigned  | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by brodie):

 * cc: brodie (added)

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

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

Re: [Django] #14051: Signals for transaction commit/rollback

[Django]

#14051: Signals for transaction commit/rollback
+---
  Reporter:  Ask Solem   | Owner:  
nobody
Status:  new| Milestone:
 Component:  Database layer (models, ORM)   |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Design decision needed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by brodie):

 * cc: brodie (added)

Comment:

 Some thoughts:

  At first glance, the API seems kind of unwieldy. I think it'd be better
 to either have a set of on-commit signals for models, or to change post_*
 to only fire when a transaction is successful, and to include some kind of
 transaction ID in dispatch_uid.

 Regarding the example, how would you make the API proposed in the patch
 work in that case? How would user.pk be passed to the signal handler?

 I brought this ticket up to Russell at the Sydney sprint the other day,
 and he suggested implementing this functionality through a context
 manager. That might be something else to consider.

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

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

Re: [Django] #13870: psycopg2 backend never terminates isolating transactions

[Django]

#13870: psycopg2 backend never terminates isolating transactions
---+
  Reporter:  patrys| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by brodie):

 It looks like this might be the same issue that #9964 is trying to
 address. Can you confirm if it is?

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

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

Re: [Django] #14766: ordering by a field that does not exists returns an empty QuerySet

[Django]

#14766: ordering by a field that does not exists returns an empty QuerySet
---+
  Reporter:  robhudson | Owner:  nobody 
   
Status:  reopened  | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  
sprintdec2010 order_by
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by Aramgutang):

  * keywords:  order_by => sprintdec2010 order_by
  * stage:  Unreviewed => Accepted

Comment:

 The actual issue appears to be that the validation of the arguments to
 order_by doesn't occur until the query is about to be evaluated. So `q =
 Model.objects.order_by('monkeys')` doesn't raise a FieldError, but
 `list(Model.objects.order_by('monkeys'))` does. However, the validation
 occurs before the query is passed to the database, which is comforting.

 d0ugal: it makes sense for count() to work, since order_by is ignored
 completely when getting a count.

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

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

[Changeset] r14821 - django/branches/releases/1.2.X/docs/topics/db

[noreply]

Author: timo
Date: 2010-12-04 16:32:28 -0600 (Sat, 04 Dec 2010)
New Revision: 14821

Modified:
   django/branches/releases/1.2.X/docs/topics/db/queries.txt
Log:
[1.2.X] Fixed #14120 - Document get() in Making Queries - thanks danielr and 
adamv for work on the patch.

Backport of r14820 from trunk.

Modified: django/branches/releases/1.2.X/docs/topics/db/queries.txt
===
--- django/branches/releases/1.2.X/docs/topics/db/queries.txt   2010-12-04 
22:32:01 UTC (rev 14820)
+++ django/branches/releases/1.2.X/docs/topics/db/queries.txt   2010-12-04 
22:32:28 UTC (rev 14821)
@@ -163,6 +163,7 @@
 that cannot be evaluated. The ``all()`` method returns a ``QuerySet`` that
 *can* be evaluated.)
 
+
 Retrieving specific objects with filters
 
 
@@ -258,12 +259,43 @@
 ``QuerySet`` is *evaluated* by accessing the database. For more details on
 exactly when evaluation takes place, see :ref:`when-querysets-are-evaluated`.
 
+
+.. _retrieving-single-object-with-get:
+
+Retrieving a single object with get
+---
+
+``.filter()`` will always give you a ``QuerySet``, even if only a single
+object matches the query - in this case, it will be a ``QuerySet`` containing
+a single element.
+
+If you know there is only one object that matches your query, you can use
+the ``get()`` method on a `Manager` which returns the object directly::
+
+>>> one_entry = Entry.objects.get(pk=1)
+
+You can use any query expression with ``get()``, just like with ``filter()`` -
+again, see `Field lookups`_ below.
+
+Note that there is a difference between using ``.get()``, and using
+``.filter()`` with a slice of ``[0]``. If there are no results that match the
+query, ``.get()`` will raise a ``DoesNotExist`` exception. This exception is an
+attribute of the model class that the query is being performed on - so in the
+code above, if there is no ``Entry`` object with a primary key of 1, Django 
will
+raise ``Entry.DoesNotExist``.
+
+Similarly, Django will complain if more than one item matches the ``get()``
+query. In this case, it will raise ``MultipleObjectsReturned``, which again is
+an attribute of the model class itself.
+
+
 Other QuerySet methods
-~~
+--
 
-Most of the time you'll use ``all()``, ``filter()`` and ``exclude()`` when you
-need to look up objects from the database. However, that's far from all there 
is; see the :ref:`QuerySet API Reference ` for a complete list
-of all the various ``QuerySet`` methods.
+Most of the time you'll use ``all()``, ``get()``, ``filter()`` and 
``exclude()``
+when you need to look up objects from the database. However, that's far from 
all
+there is; see the :ref:`QuerySet API Reference ` for a complete
+list of all the various ``QuerySet`` methods.
 
 .. _limiting-querysets:
 
@@ -304,7 +336,7 @@
 
 Note, however, that the first of these will raise ``IndexError`` while the
 second will raise ``DoesNotExist`` if no objects match the given criteria. See
-``get()`` for more details.
+:meth:`~django.db.models.QuerySet.get` for more details.
 
 .. _field-lookups-intro:
 

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

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

[noreply]

Author: timo
Date: 2010-12-04 16:32:01 -0600 (Sat, 04 Dec 2010)
New Revision: 14820

Modified:
   django/trunk/docs/topics/db/queries.txt
Log:
Fixed #14120 - Document get() in Making Queries - thanks danielr and adamv for 
work on the patch.

Modified: django/trunk/docs/topics/db/queries.txt
===
--- django/trunk/docs/topics/db/queries.txt 2010-12-04 20:58:36 UTC (rev 
14819)
+++ django/trunk/docs/topics/db/queries.txt 2010-12-04 22:32:01 UTC (rev 
14820)
@@ -163,6 +163,7 @@
 that cannot be evaluated. The ``all()`` method returns a ``QuerySet`` that
 *can* be evaluated.)
 
+
 Retrieving specific objects with filters
 
 
@@ -258,12 +259,43 @@
 ``QuerySet`` is *evaluated* by accessing the database. For more details on
 exactly when evaluation takes place, see :ref:`when-querysets-are-evaluated`.
 
+
+.. _retrieving-single-object-with-get:
+
+Retrieving a single object with get
+---
+
+``.filter()`` will always give you a ``QuerySet``, even if only a single
+object matches the query - in this case, it will be a ``QuerySet`` containing
+a single element.
+
+If you know there is only one object that matches your query, you can use
+the ``get()`` method on a `Manager` which returns the object directly::
+
+>>> one_entry = Entry.objects.get(pk=1)
+
+You can use any query expression with ``get()``, just like with ``filter()`` -
+again, see `Field lookups`_ below.
+
+Note that there is a difference between using ``.get()``, and using
+``.filter()`` with a slice of ``[0]``. If there are no results that match the
+query, ``.get()`` will raise a ``DoesNotExist`` exception. This exception is an
+attribute of the model class that the query is being performed on - so in the
+code above, if there is no ``Entry`` object with a primary key of 1, Django 
will
+raise ``Entry.DoesNotExist``.
+
+Similarly, Django will complain if more than one item matches the ``get()``
+query. In this case, it will raise ``MultipleObjectsReturned``, which again is
+an attribute of the model class itself.
+
+
 Other QuerySet methods
-~~
+--
 
-Most of the time you'll use ``all()``, ``filter()`` and ``exclude()`` when you
-need to look up objects from the database. However, that's far from all there 
is; see the :ref:`QuerySet API Reference ` for a complete list
-of all the various ``QuerySet`` methods.
+Most of the time you'll use ``all()``, ``get()``, ``filter()`` and 
``exclude()``
+when you need to look up objects from the database. However, that's far from 
all
+there is; see the :ref:`QuerySet API Reference ` for a complete
+list of all the various ``QuerySet`` methods.
 
 .. _limiting-querysets:
 
@@ -304,7 +336,7 @@
 
 Note, however, that the first of these will raise ``IndexError`` while the
 second will raise ``DoesNotExist`` if no objects match the given criteria. See
-``get()`` for more details.
+:meth:`~django.db.models.QuerySet.get` for more details.
 
 .. _field-lookups-intro:
 

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

Re: [Django] #12694: Adding an object-tool requires template code duplication

[Django]

#12694: Adding an object-tool requires template code duplication
---+
  Reporter:  andybak   | Owner:  DrMeers
 
Status:  closed| Milestone:  1.3
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:  fixed |  Keywords:  admin, blocks, 
template, object-tools, sprintdec2010
 Stage:  Ready for checkin | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 One suggestion that just came up at the sprints: Change the UL to be a
 DIV. DIVs are allowed to have no child elements, so the empty case ceases
 to be a problem.

 Of course, this means a bunch of changes to templates that could have all
 sorts of follow-on consequences.

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

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

Re: [Django] #12694: Adding an object-tool requires template code duplication

[Django]

#12694: Adding an object-tool requires template code duplication
---+
  Reporter:  andybak   | Owner:  DrMeers
 
Status:  closed| Milestone:  1.3
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:  fixed |  Keywords:  admin, blocks, 
template, object-tools, sprintdec2010
 Stage:  Ready for checkin | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by DrMeers):

 Replying to [comment:7 adamv]:
 > On change_list, I'm not sure that this block should be within the "user
 has add permission" if block, since you may want to add tools/links that
 don't require the add permission.

 I agree, however we've been unable to come up with a solution to allow
 this that won't result in an (invalid) empty  if the user does not
 have add permission and no additional tools are added. Suggestions most
 welcome.

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

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

[Changeset] r14819 - django/branches/releases/1.2.X/docs/ref

[noreply]

Author: timo
Date: 2010-12-04 14:58:36 -0600 (Sat, 04 Dec 2010)
New Revision: 14819

Modified:
   django/branches/releases/1.2.X/docs/ref/django-admin.txt
Log:
[1.2.X] Fixed #12407 - Document 'call_command' - thanks UloPe for the 
suggestion and adamv for the patch.

Backport of r14818 from trunk.

Modified: django/branches/releases/1.2.X/docs/ref/django-admin.txt
===
--- django/branches/releases/1.2.X/docs/ref/django-admin.txt2010-12-04 
20:58:07 UTC (rev 14818)
+++ django/branches/releases/1.2.X/docs/ref/django-admin.txt2010-12-04 
20:58:36 UTC (rev 14819)
@@ -1267,3 +1267,27 @@
 
 
 See :doc:`/howto/custom-management-commands` for how to add customized actions.
+
+
+==
+Running management commands from your code
+==
+
+.. function:: django.core.management.call_command(name, *args, **options)
+
+To call a management command from code use ``call_command``.
+
+``name``
+  the name of the command to call.
+
+``*args``
+  a list of arguments accepted by the command.
+
+``**options``
+  named options accepted on the command-line.
+
+Examples::
+
+  from django.core import management
+  management.call_command('flush', verbosity=0, interactive=False)
+  management.call_command('loaddata', 'test_data', verbosity=0)

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

[Changeset] r14818 - django/trunk/docs/ref

[noreply]

Author: timo
Date: 2010-12-04 14:58:07 -0600 (Sat, 04 Dec 2010)
New Revision: 14818

Modified:
   django/trunk/docs/ref/django-admin.txt
Log:
Fixed #12407 - Document 'call_command' - thanks UloPe for the suggestion and 
adamv for the patch.

Modified: django/trunk/docs/ref/django-admin.txt
===
--- django/trunk/docs/ref/django-admin.txt  2010-12-04 20:42:07 UTC (rev 
14817)
+++ django/trunk/docs/ref/django-admin.txt  2010-12-04 20:58:07 UTC (rev 
14818)
@@ -1338,3 +1338,27 @@
 
 
 See :doc:`/howto/custom-management-commands` for how to add customized actions.
+
+
+==
+Running management commands from your code
+==
+
+.. function:: django.core.management.call_command(name, *args, **options)
+
+To call a management command from code use ``call_command``.
+
+``name``
+  the name of the command to call.
+
+``*args``
+  a list of arguments accepted by the command.
+
+``**options``
+  named options accepted on the command-line.
+
+Examples::
+
+  from django.core import management
+  management.call_command('flush', verbosity=0, interactive=False)
+  management.call_command('loaddata', 'test_data', verbosity=0)

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

[Changeset] r14817 - django/branches/releases/1.2.X/docs/ref/models

[noreply]

Author: timo
Date: 2010-12-04 14:42:07 -0600 (Sat, 04 Dec 2010)
New Revision: 14817

Modified:
   django/branches/releases/1.2.X/docs/ref/models/querysets.txt
Log:
[1.2.X] Fixed #9033 - Add bullets to QuerySet extra() arguments. thanks julien 
for the suggestion and dwillis for the patch.

Backport of r14816 from trunk.

Modified: django/branches/releases/1.2.X/docs/ref/models/querysets.txt
===
--- django/branches/releases/1.2.X/docs/ref/models/querysets.txt
2010-12-04 20:41:35 UTC (rev 14816)
+++ django/branches/releases/1.2.X/docs/ref/models/querysets.txt
2010-12-04 20:42:07 UTC (rev 14817)
@@ -690,151 +690,151 @@
 Specify one or more of ``params``, ``select``, ``where`` or ``tables``. None
 of the arguments is required, but you should use at least one of them.
 
-``select``
-The ``select`` argument lets you put extra fields in the ``SELECT`` clause.
-It should be a dictionary mapping attribute names to SQL clauses to use to
-calculate that attribute.
+* ``select``
+The ``select`` argument lets you put extra fields in the ``SELECT`` 
clause.
+It should be a dictionary mapping attribute names to SQL clauses to 
use to
+calculate that attribute.
 
-Example::
+Example::
 
-Entry.objects.extra(select={'is_recent': "pub_date > '2006-01-01'"})
+Entry.objects.extra(select={'is_recent': "pub_date > 
'2006-01-01'"})
 
-As a result, each ``Entry`` object will have an extra attribute,
-``is_recent``, a boolean representing whether the entry's ``pub_date`` is
-greater than Jan. 1, 2006.
+As a result, each ``Entry`` object will have an extra attribute,
+``is_recent``, a boolean representing whether the entry's ``pub_date`` 
is
+greater than Jan. 1, 2006.
 
-Django inserts the given SQL snippet directly into the ``SELECT``
-statement, so the resulting SQL of the above example would be something
-like::
+Django inserts the given SQL snippet directly into the ``SELECT``
+statement, so the resulting SQL of the above example would be something
+like::
 
-SELECT blog_entry.*, (pub_date > '2006-01-01') AS is_recent
-FROM blog_entry;
+SELECT blog_entry.*, (pub_date > '2006-01-01') AS is_recent
+FROM blog_entry;
 
 
-The next example is more advanced; it does a subquery to give each
-resulting ``Blog`` object an ``entry_count`` attribute, an integer count
-of associated ``Entry`` objects::
+The next example is more advanced; it does a subquery to give each
+resulting ``Blog`` object an ``entry_count`` attribute, an integer 
count
+of associated ``Entry`` objects::
 
-Blog.objects.extra(
-select={
-'entry_count': 'SELECT COUNT(*) FROM blog_entry WHERE 
blog_entry.blog_id = blog_blog.id'
-},
-)
+Blog.objects.extra(
+select={
+'entry_count': 'SELECT COUNT(*) FROM blog_entry WHERE 
blog_entry.blog_id = blog_blog.id'
+},
+)
 
-(In this particular case, we're exploiting the fact that the query will
-already contain the ``blog_blog`` table in its ``FROM`` clause.)
+(In this particular case, we're exploiting the fact that the query will
+already contain the ``blog_blog`` table in its ``FROM`` clause.)
 
-The resulting SQL of the above example would be::
+The resulting SQL of the above example would be::
 
-SELECT blog_blog.*, (SELECT COUNT(*) FROM blog_entry WHERE 
blog_entry.blog_id = blog_blog.id) AS entry_count
-FROM blog_blog;
+SELECT blog_blog.*, (SELECT COUNT(*) FROM blog_entry WHERE 
blog_entry.blog_id = blog_blog.id) AS entry_count
+FROM blog_blog;
 
-Note that the parenthesis required by most database engines around
-subqueries are not required in Django's ``select`` clauses. Also note that
-some database backends, such as some MySQL versions, don't support
-subqueries.
+Note that the parenthesis required by most database engines around
+subqueries are not required in Django's ``select`` clauses. Also note 
that
+some database backends, such as some MySQL versions, don't support
+subqueries.
 
-.. versionadded:: 1.0
+.. versionadded:: 1.0
 
-In some rare cases, you might wish to pass parameters to the SQL fragments
-in ``extra(select=...)``. For this purpose, use the ``select_params``
-parameter. Since ``select_params`` is a sequence and the ``select``
-attribute is a dictionary, some care is required so that the parameters
-are matched up correctly with the extra select pieces.  In this situation,
-you should use a ``django.utils.datastructures.SortedDict`` for the
-``select`` value, not just a normal Python dictionary.
+In some 

[Changeset] r14816 - django/trunk/docs/ref/models

[noreply]

Author: timo
Date: 2010-12-04 14:41:35 -0600 (Sat, 04 Dec 2010)
New Revision: 14816

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Fixed #9033 - Add bullets to QuerySet extra() arguments. thanks julien for the 
suggestion and dwillis for the patch.

Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2010-12-04 20:21:49 UTC (rev 
14815)
+++ django/trunk/docs/ref/models/querysets.txt  2010-12-04 20:41:35 UTC (rev 
14816)
@@ -709,151 +709,151 @@
 Specify one or more of ``params``, ``select``, ``where`` or ``tables``. None
 of the arguments is required, but you should use at least one of them.
 
-``select``
-The ``select`` argument lets you put extra fields in the ``SELECT`` clause.
-It should be a dictionary mapping attribute names to SQL clauses to use to
-calculate that attribute.
+* ``select``
+The ``select`` argument lets you put extra fields in the ``SELECT`` 
clause.
+It should be a dictionary mapping attribute names to SQL clauses to 
use to
+calculate that attribute.
 
-Example::
+Example::
 
-Entry.objects.extra(select={'is_recent': "pub_date > '2006-01-01'"})
+Entry.objects.extra(select={'is_recent': "pub_date > 
'2006-01-01'"})
 
-As a result, each ``Entry`` object will have an extra attribute,
-``is_recent``, a boolean representing whether the entry's ``pub_date`` is
-greater than Jan. 1, 2006.
+As a result, each ``Entry`` object will have an extra attribute,
+``is_recent``, a boolean representing whether the entry's ``pub_date`` 
is
+greater than Jan. 1, 2006.
 
-Django inserts the given SQL snippet directly into the ``SELECT``
-statement, so the resulting SQL of the above example would be something
-like::
+Django inserts the given SQL snippet directly into the ``SELECT``
+statement, so the resulting SQL of the above example would be something
+like::
 
-SELECT blog_entry.*, (pub_date > '2006-01-01') AS is_recent
-FROM blog_entry;
+SELECT blog_entry.*, (pub_date > '2006-01-01') AS is_recent
+FROM blog_entry;
 
 
-The next example is more advanced; it does a subquery to give each
-resulting ``Blog`` object an ``entry_count`` attribute, an integer count
-of associated ``Entry`` objects::
+The next example is more advanced; it does a subquery to give each
+resulting ``Blog`` object an ``entry_count`` attribute, an integer 
count
+of associated ``Entry`` objects::
 
-Blog.objects.extra(
-select={
-'entry_count': 'SELECT COUNT(*) FROM blog_entry WHERE 
blog_entry.blog_id = blog_blog.id'
-},
-)
+Blog.objects.extra(
+select={
+'entry_count': 'SELECT COUNT(*) FROM blog_entry WHERE 
blog_entry.blog_id = blog_blog.id'
+},
+)
 
-(In this particular case, we're exploiting the fact that the query will
-already contain the ``blog_blog`` table in its ``FROM`` clause.)
+(In this particular case, we're exploiting the fact that the query will
+already contain the ``blog_blog`` table in its ``FROM`` clause.)
 
-The resulting SQL of the above example would be::
+The resulting SQL of the above example would be::
 
-SELECT blog_blog.*, (SELECT COUNT(*) FROM blog_entry WHERE 
blog_entry.blog_id = blog_blog.id) AS entry_count
-FROM blog_blog;
+SELECT blog_blog.*, (SELECT COUNT(*) FROM blog_entry WHERE 
blog_entry.blog_id = blog_blog.id) AS entry_count
+FROM blog_blog;
 
-Note that the parenthesis required by most database engines around
-subqueries are not required in Django's ``select`` clauses. Also note that
-some database backends, such as some MySQL versions, don't support
-subqueries.
+Note that the parenthesis required by most database engines around
+subqueries are not required in Django's ``select`` clauses. Also note 
that
+some database backends, such as some MySQL versions, don't support
+subqueries.
 
-.. versionadded:: 1.0
+.. versionadded:: 1.0
 
-In some rare cases, you might wish to pass parameters to the SQL fragments
-in ``extra(select=...)``. For this purpose, use the ``select_params``
-parameter. Since ``select_params`` is a sequence and the ``select``
-attribute is a dictionary, some care is required so that the parameters
-are matched up correctly with the extra select pieces.  In this situation,
-you should use a ``django.utils.datastructures.SortedDict`` for the
-``select`` value, not just a normal Python dictionary.
+In some rare cases, you might wish to pass parameters to the SQL 
fragments
+in ``extra(select=...)``. For this purpose, use 

[Changeset] r14815 - django/branches/releases/1.2.X/docs/topics/http

[noreply]

Author: timo
Date: 2010-12-04 14:21:49 -0600 (Sat, 04 Dec 2010)
New Revision: 14815

Modified:
   django/branches/releases/1.2.X/docs/topics/http/shortcuts.txt
Log:
[1.2.X] Fixed #14811 - Add clarifying note to render_to_response - thanks adamv.

Backport of r14814 from trunk.

Modified: django/branches/releases/1.2.X/docs/topics/http/shortcuts.txt
===
--- django/branches/releases/1.2.X/docs/topics/http/shortcuts.txt   
2010-12-04 20:20:54 UTC (rev 14814)
+++ django/branches/releases/1.2.X/docs/topics/http/shortcuts.txt   
2010-12-04 20:21:49 UTC (rev 14815)
@@ -24,7 +24,10 @@
 --
 
 ``template``
-The full name of a template to use or sequence of template names.
+The full name of a template to use or sequence of template names. If a
+sequence is given, the first template that exists will be used. See the
+:ref:`template loader documentation `
+for more information on how templates are found.
 
 Optional arguments
 --
@@ -47,9 +50,6 @@
   context_instance=RequestContext(request))
 
 ``mimetype``
-
-.. versionadded:: 1.0
-
 The MIME type to use for the resulting document. Defaults to the value of
 the :setting:`DEFAULT_CONTENT_TYPE` setting.
 

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

[Changeset] r14814 - django/trunk/docs/topics/http

[noreply]

Author: timo
Date: 2010-12-04 14:20:54 -0600 (Sat, 04 Dec 2010)
New Revision: 14814

Modified:
   django/trunk/docs/topics/http/shortcuts.txt
Log:
Fixed #14811 - Add clarifying note to render_to_response - thanks adamv.

Modified: django/trunk/docs/topics/http/shortcuts.txt
===
--- django/trunk/docs/topics/http/shortcuts.txt 2010-12-04 17:42:54 UTC (rev 
14813)
+++ django/trunk/docs/topics/http/shortcuts.txt 2010-12-04 20:20:54 UTC (rev 
14814)
@@ -24,7 +24,10 @@
 --
 
 ``template``
-The full name of a template to use or sequence of template names.
+The full name of a template to use or sequence of template names. If a
+sequence is given, the first template that exists will be used. See the
+:ref:`template loader documentation `
+for more information on how templates are found.
 
 Optional arguments
 --
@@ -47,9 +50,6 @@
   context_instance=RequestContext(request))
 
 ``mimetype``
-
-.. versionadded:: 1.0
-
 The MIME type to use for the resulting document. Defaults to the value of
 the :setting:`DEFAULT_CONTENT_TYPE` setting.
 

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

Re: [Django] #13062: Can't see PendingDeprecationWarnings in the development server on Linux

[Django]

#13062: Can't see PendingDeprecationWarnings in the development server on Linux
+---
  Reporter:  gremmie| Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  django-admin.py runserver  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by claudep):

  * has_patch:  0 => 1

Comment:

 I absolutely don't know if this is the right fix, but at least the
 attached patch works on my system. Someone on Windows could check if it
 doesn't break 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14827: Authentication Backends should be responsible for checking and setting passwords

[Django]

#14827: Authentication Backends should be responsible for checking and setting
passwords
-+--
  Reporter:  andornaut   | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Authentication  |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by DavidReynolds):

 * cc: DavidReynolds (added)

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

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

Re: [Django] #14827: Authentication Backends should be responsible for checking and setting passwords

[Django]

#14827: Authentication Backends should be responsible for checking and setting
passwords
-+--
  Reporter:  andornaut   | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Authentication  |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by DavidReynolds):

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

Comment:

 I like the idea of this, not only because it allows you to change hash
 method easily, but it makes it easier to use the standard auth forms/views
 to manage users from different authentication providers

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

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

[Changeset] r14813 - in django/trunk: django/core/management/commands django/template django/utils/translation tests/regressiontests/i18n/commands tests/regressiontests/i18n/commands/locale tests/regr

[noreply]

Author: ramiro
Date: 2010-12-04 11:42:54 -0600 (Sat, 04 Dec 2010)
New Revision: 14813

Added:
   
django/trunk/tests/regressiontests/i18n/commands/templates/template_with_error.txt
Removed:
   django/trunk/tests/regressiontests/i18n/commands/locale/dummy
Modified:
   django/trunk/django/core/management/commands/makemessages.py
   django/trunk/django/template/base.py
   django/trunk/django/utils/translation/__init__.py
   django/trunk/django/utils/translation/trans_real.py
   django/trunk/tests/regressiontests/i18n/commands/extraction.py
Log:
Fixed #12201 -- Added a lineno attibute to template Token so e.g. we can report 
line numbers in errors during i18n literals extraction. Thanks madewulf for the 
report and Claude Paroz for the patch.


Modified: django/trunk/django/core/management/commands/makemessages.py
===
--- django/trunk/django/core/management/commands/makemessages.py
2010-12-04 13:11:54 UTC (rev 14812)
+++ django/trunk/django/core/management/commands/makemessages.py
2010-12-04 17:42:54 UTC (rev 14813)
@@ -220,18 +220,15 @@
 os.unlink(os.path.join(dirpath, thefile))
 elif domain == 'django' and (file_ext == '.py' or file_ext in 
extensions):
 thefile = file
+orig_file = os.path.join(dirpath, file)
 if file_ext in extensions:
-src = open(os.path.join(dirpath, file), "rU").read()
+src = open(orig_file, "rU").read()
 thefile = '%s.py' % file
+f = open(os.path.join(dirpath, thefile), "w")
 try:
-f = open(os.path.join(dirpath, thefile), "w")
-try:
-f.write(templatize(src))
-finally:
-f.close()
-except SyntaxError, msg:
-msg = "%s (file: %s)" % (msg, os.path.join(dirpath, 
file))
-raise SyntaxError(msg)
+f.write(templatize(src, orig_file[2:]))
+finally:
+f.close()
 if verbosity > 1:
 sys.stdout.write('processing file %s in %s\n' % (file, 
dirpath))
 cmd = (
@@ -250,7 +247,7 @@
 
 if thefile != file:
 old = '#: '+os.path.join(dirpath, thefile)[2:]
-new = '#: '+os.path.join(dirpath, file)[2:]
+new = '#: '+orig_file[2:]
 msgs = msgs.replace(old, new)
 if os.path.exists(potfile):
 # Strip the header

Modified: django/trunk/django/template/base.py
===
--- django/trunk/django/template/base.py2010-12-04 13:11:54 UTC (rev 
14812)
+++ django/trunk/django/template/base.py2010-12-04 17:42:54 UTC (rev 
14813)
@@ -139,6 +139,7 @@
 def __init__(self, token_type, contents):
 # token_type must be TOKEN_TEXT, TOKEN_VAR, TOKEN_BLOCK or 
TOKEN_COMMENT.
 self.token_type, self.contents = token_type, contents
+self.lineno = None
 
 def __str__(self):
 return '<%s token: "%s...">' % \
@@ -164,6 +165,7 @@
 def __init__(self, template_string, origin):
 self.template_string = template_string
 self.origin = origin
+self.lineno = 1
 
 def tokenize(self):
 "Return a list of tokens from a given template_string."
@@ -193,6 +195,8 @@
 token = Token(TOKEN_COMMENT, content)
 else:
 token = Token(TOKEN_TEXT, token_string)
+token.lineno = self.lineno
+self.lineno += token_string.count('\n')
 return token
 
 class Parser(object):

Modified: django/trunk/django/utils/translation/__init__.py
===
--- django/trunk/django/utils/translation/__init__.py   2010-12-04 13:11:54 UTC 
(rev 14812)
+++ django/trunk/django/utils/translation/__init__.py   2010-12-04 17:42:54 UTC 
(rev 14813)
@@ -104,8 +104,8 @@
 def get_language_from_request(request):
 return _trans.get_language_from_request(request)
 
-def templatize(src):
-return _trans.templatize(src)
+def templatize(src, origin=None):
+return _trans.templatize(src, origin)
 
 def deactivate_all():
 return _trans.deactivate_all()

Modified: django/trunk/django/utils/translation/trans_real.py
===
--- django/trunk/django/utils/translation/trans_real.py 2010-12-04 13:11:54 UTC 
(rev 14812)
+++ django/trunk/django/utils/translation/trans_real.py 2010-12-04 17:42:54 UTC 
(rev 14813)
@@ -421,7 +421,7 @@
 plural_re = re.compile(r"""^\s*plural$""")
 constant_re = re.compile(r"""_\(((?:".*?")|(?:'.*?'))\)""")
 
-def templatize(src):
+def templatize(src, 

Re: [Django] #14808: i18n is not safe.

[Django]

#14808: i18n is not safe.
--+-
  Reporter:  steveire | Owner:  nobody
Status:  new  | Milestone:  1.3   
 Component:  Template system  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by claudep):

 * cc: claudep (added)

Comment:

 I'm not sure this can be fixed at all. What about a translatable string
 which contains markup? Example: "Today", translated in the French
 po file by "Aujourd'hui".

 If there is anything that can cause security problems in the translated
 strings, shouldn't they be fixed in the po file in the first place?

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

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

Re: [Django] #12201: django-admin.py makemessages could show the line number when it fails

[Django]

#12201: django-admin.py makemessages could show the line number when it fails
---+
  Reporter:  madewulf  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Internationalization  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  1 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by claudep):

  * needs_tests:  1 => 0

Comment:

 I updated the patch to apply again on trunk, and I added a test. Does this
 really need documentation?

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

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

Re: [Django] #14303: admin inline form id attribute numbering order and uniqueness is lost

[Django]

#14303: admin inline form id attribute numbering order and uniqueness is lost
---+
  Reporter:  m0nonoke  | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  inline javascript, 
sprintdec2010
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by julien):

  * keywords:  inline javascript => inline javascript, sprintdec2010
  * has_patch:  0 => 1
  * stage:  Unreviewed => Accepted

Comment:

 I confirm this is a bug. This can be fixed by keeping `nextIndex` static
 and not refreshing it with the TOTAL_FORMS value each time. See patch
 attached.

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

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

Re: [Django] #14336: list_display should be able to contain sortable references to extra and/or annotated fields

[Django]

#14336: list_display should be able to contain sortable references to extra 
and/or
annotated fields
---+
  Reporter:  pmclanahan| Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by DrMeers):

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

Comment:

 We don't really want to encourage the use of `extra` in general, however
 making additional queryset attributes available in `list_display` could be
 quite useful when used in conjunction with `annotate`.

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

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

[Changeset] r14811 - django/branches/releases/1.2.X/docs/ref/contrib/comments

[noreply]

Author: DrMeers
Date: 2010-12-04 05:38:26 -0600 (Sat, 04 Dec 2010)
New Revision: 14811

Modified:
   django/branches/releases/1.2.X/docs/ref/contrib/comments/custom.txt
Log:
[1.2.X] Fixed #12812 -- added warning about cyclic imports in contrib.comments. 
Thanks to Beetle_B, bjourne and philgyford for the reports, and Russ for the 
wording.

Backport of r14810 from trunk.

Modified: django/branches/releases/1.2.X/docs/ref/contrib/comments/custom.txt
===
--- django/branches/releases/1.2.X/docs/ref/contrib/comments/custom.txt 
2010-12-04 11:35:22 UTC (rev 14810)
+++ django/branches/releases/1.2.X/docs/ref/contrib/comments/custom.txt 
2010-12-04 11:38:26 UTC (rev 14811)
@@ -110,6 +110,18 @@
 def get_form():
 return CommentFormWithTitle
 
+
+.. warning::
+
+Be careful not to create cyclic imports in your custom comments app.
+If you feel your comment configuration isn't being used as defined --
+for example, if your comment moderation policy isn't being applied --
+you may have a cyclic import problem.
+
+If you are having unexplained problems with comments behavior, check
+if your custom comments application imports (even indirectly)
+any module that itself imports Django's comments module.
+
 The above process should take care of most common situations. For more
 advanced usage, there are additional methods you can define. Those are
 explained in the next section.

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

[Changeset] r14810 - django/trunk/docs/ref/contrib/comments

[noreply]

Author: DrMeers
Date: 2010-12-04 05:35:22 -0600 (Sat, 04 Dec 2010)
New Revision: 14810

Modified:
   django/trunk/docs/ref/contrib/comments/custom.txt
Log:
Fixed #12812 -- added warning about cyclic imports in contrib.comments. Thanks 
to Beetle_B, bjourne and philgyford for the reports, and Russ for the wording.

Modified: django/trunk/docs/ref/contrib/comments/custom.txt
===
--- django/trunk/docs/ref/contrib/comments/custom.txt   2010-12-04 11:20:52 UTC 
(rev 14809)
+++ django/trunk/docs/ref/contrib/comments/custom.txt   2010-12-04 11:35:22 UTC 
(rev 14810)
@@ -110,6 +110,18 @@
 def get_form():
 return CommentFormWithTitle
 
+
+.. warning::
+
+Be careful not to create cyclic imports in your custom comments app.
+If you feel your comment configuration isn't being used as defined --
+for example, if your comment moderation policy isn't being applied --
+you may have a cyclic import problem.
+
+If you are having unexplained problems with comments behavior, check
+if your custom comments application imports (even indirectly)
+any module that itself imports Django's comments module.
+
 The above process should take care of most common situations. For more
 advanced usage, there are additional methods you can define. Those are
 explained in the next section.

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

Re: [Django] #14095: Objects not saved when readonly_fields is set for inline admin

[Django]

#14095: Objects not saved when readonly_fields is set for inline admin
---+
  Reporter:  si...@pewpewlabs.com  | Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  django.contrib.admin  |   Version:  1.2
  
Resolution:  invalid   |  Keywords:  TabularInline, 
inline, readonly_fields, sprintdec2010
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by julien):

  * keywords:  TabularInline, inline, readonly_fields => TabularInline,
   inline, readonly_fields, sprintdec2010
  * status:  new => closed
  * resolution:  => invalid

Comment:

 Thank you for the report, Simon. It is true that Django is behaving oddly
 here. However, this is caused by the way inlines are currently designed to
 work. If you make the `code` field readonly, then there will not be any
 input added to the form for it, which means that Django has no way of
 detecting that anything has changed in the form, and therefore cannot know
 that an object should be created.

 I've discussed this at length with russelm and DrMeers (both core
 committers), and the answer is that this cannot be fixed. To achieve what
 you want you'd probably have to not make the `code` field readonly, and
 then use a bit of javascript to prevent the user from modifying it.

 For that reason I'm closing this ticket as invalid. I also invite you to
 look into ticket #14832, which has in fact emerged after looking at this
 one and which discusses a related issue.

 Finally, for the record, here's the code I've used to study this issue
 (some elements like `generate_balance_code` or `SERIES_CODE_COUNT` were
 missing in your description):

 Models:
 {{{
 #!python

 import datetime, hashlib

 from django.db import models
 from django.contrib.auth.models import User

 def generate_balance_code():
 return hashlib.md5(str(datetime.datetime.now())).hexdigest()


 class RefillSeries(models.Model):
 issued = models.DateField(default=datetime.datetime.today)
 least_valid_until = models.DateField(default=datetime.datetime.today()
 + datetime.timedelta(days=1))

 class BalanceCode(models.Model):
 created_at = models.DateField(auto_now_add=True)
 code = models.CharField(max_length=100, unique=True,
 default=generate_balance_code,)
 value = models.PositiveIntegerField(default=10)
 refill_series = models.ForeignKey(RefillSeries)
 used_by = models.ForeignKey(User, null=True, blank=True)
 used_at = models.DateField(blank=True, null=True)
 }}}

 Admin:
 {{{
 #!python

 from django.contrib import admin

 from .models import BalanceCode, RefillSeries

 class BalanceCodeAdmin(admin.ModelAdmin):
 readonly_fields = ('code', )

 class BalanceCodeInline(admin.TabularInline):
 readonly_fields = ('code', )
 model = BalanceCode
 extra = 2
 max_num = 5

 class RefillSeriesAdmin(admin.ModelAdmin):
 inlines = [BalanceCodeInline]

 admin.site.register(BalanceCode, BalanceCodeAdmin)
 admin.site.register(RefillSeries, RefillSeriesAdmin)
 }}}

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

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

[Changeset] r14809 - in django/trunk: django/views/generic tests/regressiontests/generic_views

[noreply]

Author: russellm
Date: 2010-12-04 05:20:52 -0600 (Sat, 04 Dec 2010)
New Revision: 14809

Modified:
   django/trunk/django/views/generic/edit.py
   django/trunk/tests/regressiontests/generic_views/edit.py
   django/trunk/tests/regressiontests/generic_views/tests.py
   django/trunk/tests/regressiontests/generic_views/views.py
Log:
Fixed #14797 -- Corrected the handling of get_form_class() when a custom 
queryset has been defined, but a model hasn't. Thanks to Gabriel Grant for the 
report and patch.

Modified: django/trunk/django/views/generic/edit.py
===
--- django/trunk/django/views/generic/edit.py   2010-12-04 11:20:30 UTC (rev 
14808)
+++ django/trunk/django/views/generic/edit.py   2010-12-04 11:20:52 UTC (rev 
14809)
@@ -72,10 +72,7 @@
 if self.form_class:
 return self.form_class
 else:
-if self.model is None:
-model = self.queryset.model
-else:
-model = self.model
+model = self.get_queryset().model
 return model_forms.modelform_factory(model)
 
 def get_form(self, form_class):

Modified: django/trunk/tests/regressiontests/generic_views/edit.py
===
--- django/trunk/tests/regressiontests/generic_views/edit.py2010-12-04 
11:20:30 UTC (rev 14808)
+++ django/trunk/tests/regressiontests/generic_views/edit.py2010-12-04 
11:20:52 UTC (rev 14809)
@@ -7,6 +7,10 @@
 from regressiontests.generic_views.models import Artist, Author
 from regressiontests.generic_views import views
 
+class ModelFormMixinTests(TestCase):
+def test_get_form(self):
+form_class = views.AuthorGetQuerySetFormView().get_form_class()
+self.assertEqual(form_class.Meta.model, Author)
 
 class CreateViewTests(TestCase):
 urls = 'regressiontests.generic_views.urls'

Modified: django/trunk/tests/regressiontests/generic_views/tests.py
===
--- django/trunk/tests/regressiontests/generic_views/tests.py   2010-12-04 
11:20:30 UTC (rev 14808)
+++ django/trunk/tests/regressiontests/generic_views/tests.py   2010-12-04 
11:20:52 UTC (rev 14809)
@@ -1,5 +1,5 @@
 from regressiontests.generic_views.base import ViewTest, TemplateViewTest, 
RedirectViewTest
 from regressiontests.generic_views.dates import ArchiveIndexViewTests, 
YearArchiveViewTests, MonthArchiveViewTests, WeekArchiveViewTests, 
DayArchiveViewTests, DateDetailViewTests
 from regressiontests.generic_views.detail import DetailViewTest
-from regressiontests.generic_views.edit import CreateViewTests, 
UpdateViewTests, DeleteViewTests
+from regressiontests.generic_views.edit import ModelFormMixinTests, 
CreateViewTests, UpdateViewTests, DeleteViewTests
 from regressiontests.generic_views.list import ListViewTests

Modified: django/trunk/tests/regressiontests/generic_views/views.py
===
--- django/trunk/tests/regressiontests/generic_views/views.py   2010-12-04 
11:20:30 UTC (rev 14808)
+++ django/trunk/tests/regressiontests/generic_views/views.py   2010-12-04 
11:20:52 UTC (rev 14809)
@@ -143,3 +143,7 @@
 
 class BookDetail(BookConfig, generic.DateDetailView):
 pass
+
+class AuthorGetQuerySetFormView(generic.edit.ModelFormMixin):
+def get_queryset(self):
+return Author.objects.all()

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

[Changeset] r14808 - in django/trunk: django/views/generic docs/ref docs/topics tests/regressiontests/generic_views

[noreply]

Author: russellm
Date: 2010-12-04 05:20:30 -0600 (Sat, 04 Dec 2010)
New Revision: 14808

Modified:
   django/trunk/django/views/generic/edit.py
   django/trunk/docs/ref/class-based-views.txt
   django/trunk/docs/topics/generic-views-migration.txt
   django/trunk/tests/regressiontests/generic_views/edit.py
   django/trunk/tests/regressiontests/generic_views/urls.py
Log:
Fixed #14803 -- Corrected an inconsistency in redirection handling between 
old-style generic views and class-based views. Thanks to gg for the report and 
patch.

Modified: django/trunk/django/views/generic/edit.py
===
--- django/trunk/django/views/generic/edit.py   2010-12-04 08:04:16 UTC (rev 
14807)
+++ django/trunk/django/views/generic/edit.py   2010-12-04 11:20:30 UTC (rev 
14808)
@@ -97,7 +97,7 @@
 
 def get_success_url(self):
 if self.success_url:
-url = self.success_url
+url = self.success_url % self.object.__dict__
 else:
 try:
 url = self.object.get_absolute_url()

Modified: django/trunk/docs/ref/class-based-views.txt
===
--- django/trunk/docs/ref/class-based-views.txt 2010-12-04 08:04:16 UTC (rev 
14807)
+++ django/trunk/docs/ref/class-based-views.txt 2010-12-04 11:20:30 UTC (rev 
14808)
@@ -481,6 +481,11 @@
 
 The URL to redirect to when the form is successfully processed.
 
+``success_url`` may contain dictionary string formatting, which
+will be interpolated against the object's field attributes. For
+example, you could use ``success_url="/polls/%(slug)s/"`` to
+redirect to a URL composed out of the ``slug`` field on a model.
+
 .. method:: get_form_class()
 
 Retrieve the form class to instantiate. If

Modified: django/trunk/docs/topics/generic-views-migration.txt
===
--- django/trunk/docs/topics/generic-views-migration.txt2010-12-04 
08:04:16 UTC (rev 14807)
+++ django/trunk/docs/topics/generic-views-migration.txt2010-12-04 
11:20:30 UTC (rev 14808)
@@ -113,6 +113,13 @@
 })
 return context
 
+``post_save_redirect`` argument to create and update views
+--
+
+The ``post_save_redirect`` argument to the create and update views
+has been renamed ``success_url`` on the
+:class:`~django.views.generic.edit.ModelFormMixin`.
+
 ``mimetype``
 
 

Modified: django/trunk/tests/regressiontests/generic_views/edit.py
===
--- django/trunk/tests/regressiontests/generic_views/edit.py2010-12-04 
08:04:16 UTC (rev 14807)
+++ django/trunk/tests/regressiontests/generic_views/edit.py2010-12-04 
11:20:30 UTC (rev 14808)
@@ -47,6 +47,14 @@
 self.assertRedirects(res, 'http://testserver/edit/authors/create/')
 self.assertQuerysetEqual(Author.objects.all(), [''])
 
+def test_create_with_interpolated_redirect(self):
+res = self.client.post('/edit/authors/create/interpolate_redirect/',
+{'name': 'Randall Munroe', 'slug': 
'randall-munroe'})
+self.assertQuerysetEqual(Author.objects.all(), [''])
+self.assertEqual(res.status_code, 302)
+pk = Author.objects.all()[0].pk
+self.assertRedirects(res, 'http://testserver/edit/author/%d/update/' % 
pk)
+
 def test_create_with_special_properties(self):
 res = self.client.get('/edit/authors/create/special/')
 self.assertEqual(res.status_code, 200)
@@ -145,6 +153,18 @@
 self.assertRedirects(res, 'http://testserver/edit/authors/create/')
 self.assertQuerysetEqual(Author.objects.all(), [''])
 
+def test_update_with_interpolated_redirect(self):
+a = Author.objects.create(
+name='Randall Munroe',
+slug='randall-munroe',
+)
+res = self.client.post('/edit/author/%d/update/interpolate_redirect/' 
% a.pk,
+{'name': 'Randall Munroe (author of xkcd)', 'slug': 
'randall-munroe'})
+self.assertQuerysetEqual(Author.objects.all(), [''])
+self.assertEqual(res.status_code, 302)
+pk = Author.objects.all()[0].pk
+self.assertRedirects(res, 'http://testserver/edit/author/%d/update/' % 
pk)
+
 def test_update_with_special_properties(self):
 a = Author.objects.create(
 name='Randall Munroe',

Modified: django/trunk/tests/regressiontests/generic_views/urls.py
===
--- django/trunk/tests/regressiontests/generic_views/urls.py2010-12-04 
08:04:16 UTC (rev 14807)
+++ django/trunk/tests/regressiontests/generic_views/urls.py2010-12-04 
11:20:30 UTC (rev 14808)
@@ -51,6 +51,8 @@
 views.NaiveAuthorCreate.as_view()),
 

Re: [Django] #14007: Automatically discover models within a package without using the app_label Meta attribute

[Django]

#14007: Automatically discover models within a package without using the 
app_label
Meta attribute
---+
  Reporter:  m...@deliciouslynerdy.com | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  
sprintdec2010 package models model
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by Aramgutang):

  * needs_docs:  1 => 0

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

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

[Django] #14832: Impossible to create inline objects if form validates but is unchanged

[Django]

#14832: Impossible to create inline objects if form validates but is unchanged
--+-
 Reporter:  julien|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:  sprintdec2010 |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Here's a simple test case:

 Models:
 {{{
 #!python

 from django.db import models

 class Account(models.Model):
 name = models.CharField(max_length=100)

 class Expense(models.Model):
 account = models.ForeignKey(Account)
 amount = models. IntegerField(default=100, blank=True, null=True)
 memo = models.CharField(max_length=100, blank=True)
 }}}

 Admin:
 {{{
 #!python

 from django.contrib import admin

 from .models import Account, Expense

 class ExpenseInlineAdmin(admin.TabularInline):
 model = Expense

 class AccountAdmin(admin.ModelAdmin):
 inlines = [ExpenseInlineAdmin]

 admin.site.register(Account, AccountAdmin)
 }}}

 Here there is no way to create an expense object with the amount 100 and
 no memo. This is because Django compares the submitted values with the
 initial ones, and takes a (big) guess that the user wants to create an
 object only because she has *modified* one of the values. If the user is
 happy with the default values and presses 'save', then the expense object
 won't get created.

 I've discussed this at length with DrMeers and russellm during the Dec2010
 sprint. I am conscious that there is no straight forward solution to this,
 and that this approach was designed prior the inclusion of jquery and also
 to allow people without javascript to use inlines. However it seems that
 this system is either flawed by design, or confusing to say the least (as
 people rely on this behaviour and expect things to work the way they
 really shouldn't, i.e. #14095).

 It feels that some user interface design work needs to be done to make
 things more explicit and intuitive. Opening this ticket to keep track of
 this request, as I expect some design discussions need to happen on the
 mailing list in parallel.

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

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

Re: [Django] #14684: RESTful Model View

[Django]

#14684: RESTful Model View
-+--
  Reporter:  gdoermann   | Owner:  lrekucki 
   
Status:  new | Milestone:   
   
 Component:  Generic views   |   Version:  1.3-alpha
   
Resolution:  |  Keywords:  models, views, 
sprintdec2010
 Stage:  Design decision needed  | Has_patch:  1
   
Needs_docs:  1   |   Needs_tests:  1
   
Needs_better_patch:  1   |  
-+--
Changes (by lrekucki):

  * owner:  nobody => lrekucki
  * needs_better_patch:  0 => 1
  * needs_tests:  0 => 1
  * needs_docs:  0 => 1

Comment:

 I'm intrested in working on this for 1.4 :)

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

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

Re: [Django] #14770: Should be able to set cookies from the request as well as the response.

[Django]

#14770: Should be able to set cookies from the request as well as the response.
-+--
  Reporter:  pmclanahan  | Owner:  pmclanahan
Status:  closed  | Milestone:  1.3   
 Component:  Core framework  |   Version:  SVN   
Resolution:  wontfix |  Keywords:  cookies   
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by lrekucki):

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

Comment:

 Marking won't fix on the base of: http://groups.google.com/group/django-
 developers/browse_frm/thread/e8aaa5565fb7a555/ca216a753f1e0c75

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

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

Re: [Django] #14803: ModelFormMixing's handling of "success_url" is inconsistent with old generic view behaviour

[Django]

#14803: ModelFormMixing's handling of "success_url" is inconsistent with old
generic view behaviour
+---
  Reporter:  gg | Owner:  gg 
Status:  new| Milestone:  1.3
 Component:  Generic views  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Ready for checkin  | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Ready for checkin

Comment:

 Patch looks good, mod some minor PEP8 stuff that can easily get cleaned up
 prior to commit.

 As for the aside -- sounds like a good idea to me, but it needs a separate
 ticket, and a patch that implements a get_absolute_url() solution that
 defers to success_url if it is provided.

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

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

Re: [Django] #14301: django crashes on email address that passed validate_email() (utf8-tld)

[Django]

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

 Replying to [comment:16 jezdez]:
 > the encoding with idna needs to happen earlier in the life of an
 !EmailMessage, say in the `__init__` when the different recipient
 attributes are handled anyway (see 2).

 I think encoding during `__init__` is a bad idea since you might want to
 change those object variables at a later time. Maybe set private object
 vars during `__init__` and make `to, cc, bcc` properties delivering
 encoded values?

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

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

Re: [Django] #14820: Use `TextField` instead of `PositiveIntegerField` in docs and examples for generic relations.

[Django]

#14820: Use `TextField` instead of `PositiveIntegerField` in docs and examples 
for
generic relations.
+---
  Reporter:  mrmachine  | Owner:
 
Status:  new| Milestone:
 
 Component:  Documentation  |   Version:  SVN   
 
Resolution: |  Keywords:  generic relation 
genericforeignkey object_id type textfield
 Stage:  Unreviewed | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Comment (by lrekucki):

 How about adding a section on GFKs in reusable apps at the bottom,
 instead?  Also, while the statement about values coercible values is
 certainly accurate, it's not very helpful to the reader. Docs on
 {{{get_db_prep_value}}} won't help much either, so some example would be
 good.

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

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

Re: [Django] #6106: make-messages.py should not touch POT-Creation-Date

[Django]

#6106: make-messages.py should not touch POT-Creation-Date
---+
  Reporter:  telenieko | Owner:  ramiro
Status:  closed| Milestone:
 Component:  Internationalization  |   Version:  SVN   
Resolution:  wontfix   |  Keywords:
 Stage:  Someday/Maybe | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by claudep):

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

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

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

Re: [Django] #12812: Inheriting from comments breaks comment moderation

[Django]

#12812: Inheriting from comments breaks comment moderation
--+-
  Reporter:  Beetle_B | Owner:  nobody  
 
Status:  reopened | Milestone:  
 
 Component:  django.contrib.comments  |   Version:  1.1 
 
Resolution:   |  Keywords:  comments 
inheritance moderation sprintdec2010
 Stage:  Accepted | Has_patch:  0   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Changes (by DrMeers):

  * keywords:  comments inheritance moderation => comments inheritance
   moderation sprintdec2010
  * stage:  Unreviewed => Accepted

Comment:

 Thank you for the example project philgyford. I have confirmed your
 reported (mis)behaviour.

 When `contrib.comments` attempts to import your custom comments app and
 check for its `get_model` attribute, for example, your custom
 `__init__.py` imports the custom `models.py`/`forms.py` -- if either of
 those import something from weblog.models, you're then back to importing
 moderation, so the custom comments app imports with only `['__builtins__',
 '__doc__', '__file__', '__name__', '__package__', '__path__']` -- no
 `get_model` or `get_form`. Which means the moderator defaults to the
 standard `Comment` model, etc.

 For now I'll fix this by adding documentation warning developers to avoid
 cyclic imports involving moderation when developing custom comment apps.
 When smarter registration mechanisms (e.g. `startup.py`) land, cyclic
 moderation-registration imports should be quite easily avoided.

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

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

Re: [Django] #5672: i18n minor problem (comma list items separator can't be translated) in django.utils.text.get_text_list()

[Django]

#5672: i18n minor problem (comma list items separator can't be translated) in
django.utils.text.get_text_list()
---+
  Reporter:  remohammadi   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Internationalization  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by claudep):

  * keywords:  i18n-nofix =>
  * has_patch:  0 => 1

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

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

Re: [Django] #14484: database router ignored on Manager.get()

[Django]

#14484: database router ignored on Manager.get()
---+
  Reporter:  qMax | Owner:  nobody 
   
Status:  closed| Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:  worksforme|  Keywords:  
sprintdec2010, multiple databases, router, manager
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by aweakley):

  * keywords:  multiple databases, router, manager => sprintdec2010,
   multiple databases, router, manager
  * status:  new => closed
  * resolution:  => worksforme

Comment:

 I can't repeat the behaviour described using a router as described above,
 and the following model code:

 models.py
 {{{
 class Category(models.Model):
 title = models.CharField(max_length=127)
 db_name = 'other'

 def __unicode__(self):
 return self.title
 }}}

 settings.py

 {{{
 DATABASE_ROUTERS = ['example.routers.DBRouter',]
 }}}

 session:
 {{{
 In [1]: from example.models import Category

 In [2]: Category.objects.get(id=1)

 Out[2]: 

 In [3]: Category.objects.all().get(id=1)

 Out[3]: 

 In [4]: Category.objects.all().db

 Out[4]: 'other'

 }}}

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

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

Re: [Django] #13662: Documentation for running tests difficult to find

[Django]

#13662: Documentation for running tests difficult to find
+---
  Reporter:  mir| Owner:  cogat
Status:  new| Milestone:  1.3  
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:  sprintdec2010
 Stage:  Ready for checkin  | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gg):

  * owner:  => cogat

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

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

Re: [Django] #13662: Documentation for running tests difficult to find

[Django]

#13662: Documentation for running tests difficult to find
+---
  Reporter:  mir| Owner:   
Status:  new| Milestone:  1.3  
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:  sprintdec2010
 Stage:  Ready for checkin  | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gg):

  * owner:  cogat =>
  * status:  assigned => new

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

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

Re: [Django] #12321: CharField default is a str and not unicode

[Django]

#12321: CharField default is a str and not unicode
---+
  Reporter:  bjourne   | Owner:  kgrandis
Status:  assigned  | Milestone:  1.3 
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Changes (by claudep):

  * needs_better_patch:  0 => 1

Comment:

 The fact that CharField to_python doesn't force a bytestring to unicode is
 explained by some edge cases with MySQL where the collation for the field
 is set to utf8_bin. I wouldn't touch this part of the code.

 See http://docs.djangoproject.com/en/1.2/ref/databases/#collation-settings

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

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

Re: [Django] #14831: Django Template Style Guide

[Django]

#14831: Django Template Style Guide
+---
  Reporter:  DrMeers| Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  1.2
Resolution: |  Keywords:  template, style, format
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

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

Comment:

 I'm in favor of standards in general. What will probably bring this issue
 to a consensus most quickly would be the following:

   1. An overview of the various styles found in the current templates,
   2. A draft patch based on whatever the most common/best practice seems
 to be,
   3. A thread on Django Developers to let folks debate the options.

 A few points that should be specified in a style guide for templates:

   * Indentation: how many spaces?
   * Placement of `extends` and `load` tags (at the top seems pretty
 standard).
   * Whether HTML inside a `block` should always be on its own line or if
 short blocks should be kept on one line. See
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/templates/admin/base_site.html
 the admin base_site template] for examples of both.
   * Whether all code inside a `block` should be indented. (commonly the
 answer seems to be "no")

 There are probably others, but this is what springs to mind so far.

 Just to toss my two cents into the ring (how's that for a mixed
 metaphor?), here's what I think:

 Even though there's no guiding document like PEP 8 for HTML, I think
 applying as much of PEP 8 as makes sense is going to be the simplest
 answer. It's an established and understood document that Python developers
 are accustomed to. A couple of items that would tend to apply:

   * Where whitespace will not affect rendered output, break up nested tags
 onto their own lines to keep from running over 80 characters.

   * Separate blocks (or other discrete groups of tags or logical sections)
 by blank lines.

   * Imports (i.e. `load` and `extends`) should be at the top of the file,
 on separate lines.

   * Proper whitespace within HTML tags. (``
 not ``)

 I think overall readability and proper indentation of each individual
 template file is more important than what the HTML output looks like. I
 wrap my base templates with the `spaceless` tag though, so it matters less
 to me.

 Use 4 spaces for indentation. (I know 2 spaces is popular for HTML among
 many developers, but PEP 8 recommends 4 and changing to 2 for templates
 doesn't offer any substantive improvement while it decreases the visual
 separation).

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

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