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

2010-11-21 Thread noreply
Author: gabrielhurley
Date: 2010-11-22 00:44:59 -0600 (Mon, 22 Nov 2010)
New Revision: 14678

Modified:
   django/branches/releases/1.2.X/docs/ref/templates/builtins.txt
Log:
[1.2.X] Fixed #14736 -- corrected an ungrammatical sentence in the template 
tags docs. Thanks to DD for the report and adamv for the draft patch.

Backport of [14677] from trunk.

Modified: django/branches/releases/1.2.X/docs/ref/templates/builtins.txt
===
--- django/branches/releases/1.2.X/docs/ref/templates/builtins.txt  
2010-11-22 06:44:19 UTC (rev 14677)
+++ django/branches/releases/1.2.X/docs/ref/templates/builtins.txt  
2010-11-22 06:44:59 UTC (rev 14678)
@@ -1009,9 +1009,8 @@
 
 .. warning::
 
-Keep in mind that strings that can both be coerced to integers will be,
-and thus will be will be *summed*, not concatenated, as in the first
-example above.
+Strings that can be coerced to integers will be **summed**, not
+concatenated, as in the first example above.
 
 .. templatefilter:: addslashes
 

-- 
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] r14677 - django/trunk/docs/ref/templates

2010-11-21 Thread noreply
Author: gabrielhurley
Date: 2010-11-22 00:44:19 -0600 (Mon, 22 Nov 2010)
New Revision: 14677

Modified:
   django/trunk/docs/ref/templates/builtins.txt
Log:
Fixed #14736 -- corrected an ungrammatical sentence in the template tags docs. 
Thanks to DD for the report and adamv for the draft patch.

Modified: django/trunk/docs/ref/templates/builtins.txt
===
--- django/trunk/docs/ref/templates/builtins.txt2010-11-22 06:15:02 UTC 
(rev 14676)
+++ django/trunk/docs/ref/templates/builtins.txt2010-11-22 06:44:19 UTC 
(rev 14677)
@@ -1091,9 +1091,8 @@
 
 .. warning::
 
-Keep in mind that strings that can both be coerced to integers will be,
-and thus will be will be *summed*, not concatenated, as in the first
-example above.
+Strings that can be coerced to integers will be **summed**, not
+concatenated, as in the first example above.
 
 .. templatefilter:: addslashes
 

-- 
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] #14736: Typo in documentation

2010-11-21 Thread Django
#14736: Typo in documentation
+---
  Reporter:  DD | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:  typo easy-pickings
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by adamv):

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



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

2010-11-21 Thread noreply
Author: gabrielhurley
Date: 2010-11-22 00:15:02 -0600 (Mon, 22 Nov 2010)
New Revision: 14676

Modified:
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/topics/cache.txt
Log:
Fixed #14738 -- Improved crossref linking for cache settings, and fixed a few 
minor typos.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2010-11-22 06:08:38 UTC (rev 14675)
+++ django/trunk/docs/ref/settings.txt  2010-11-22 06:15:02 UTC (rev 14676)
@@ -169,7 +169,7 @@
 If you set the value of this setting to ``True``, you should make sure you've
 activated ``AuthenticationMiddleware``.
 
-See the :doc:`cache documentation ` for more information.
+See :doc:`/topics/cache`.
 
 .. setting:: CACHE_MIDDLEWARE_KEY_PREFIX
 
@@ -178,9 +178,10 @@
 
 Default: ``''`` (Empty string)
 
-The cache key prefix that the cache middleware should use. See
-:doc:`/topics/cache`.
+The cache key prefix that the cache middleware should use.
 
+See :doc:`/topics/cache`.
+
 .. setting:: CACHE_MIDDLEWARE_SECONDS
 
 CACHE_MIDDLEWARE_SECONDS
@@ -191,6 +192,8 @@
 The default number of seconds to cache a page when the caching middleware or
 ``cache_page()`` decorator is used.
 
+See :doc:`/topics/cache`.
+
 .. setting:: CACHE_PREFIX
 
 CACHE_PREFIX

Modified: django/trunk/docs/topics/cache.txt
===
--- django/trunk/docs/topics/cache.txt  2010-11-22 06:08:38 UTC (rev 14675)
+++ django/trunk/docs/topics/cache.txt  2010-11-22 06:15:02 UTC (rev 14676)
@@ -31,8 +31,8 @@
 Django comes with a robust cache system that lets you save dynamic pages so
 they don't have to be calculated for each request. For convenience, Django
 offers different levels of cache granularity: You can cache the output of
-specific views, you can cache only the pieces that are difficult to produce, or
-you can cache your entire site.
+specific views, you can cache only the pieces that are difficult to produce,
+or you can cache your entire site.
 
 Django also works well with "upstream" caches, such as Squid
 (http://www.squid-cache.org/) and browser-based caches. These are the types of
@@ -47,8 +47,9 @@
 or directly in memory. This is an important decision that affects your cache's
 performance; yes, some cache types are faster than others.
 
-Your cache preference goes in the ``CACHE_BACKEND`` setting in your settings
-file. Here's an explanation of all available values for ``CACHE_BACKEND``.
+Your cache preference goes in the :setting:`CACHE_BACKEND` setting in your
+settings file. Here's an explanation of all available values for
+:setting:`CACHE_BACKEND`.
 
 Memcached
 -
@@ -75,7 +76,7 @@
 a lack of maintenance on the ``cmemcache`` library itself. Support for
 ``cmemcache`` will be removed completely in Django 1.4.
 
-To use Memcached with Django, set ``CACHE_BACKEND`` to
+To use Memcached with Django, set :setting:`CACHE_BACKEND` to
 ``memcached://ip:port/``, where ``ip`` is the IP address of the Memcached
 daemon and ``port`` is the port on which Memcached is running.
 
@@ -87,7 +88,8 @@
 servers. This means you can run Memcached daemons on multiple machines, and the
 program will treat the group of machines as a *single* cache, without the need
 to duplicate cache values on each machine. To take advantage of this feature,
-include all server addresses in ``CACHE_BACKEND``, separated by semicolons.
+include all server addresses in :setting:`CACHE_BACKEND`, separated by
+semicolons.
 
 In this example, the cache is shared over Memcached instances running on IP
 address 172.19.26.240 and 172.19.26.242, both on port 11211::
@@ -123,9 +125,10 @@
 in your database that is in the proper format that Django's database-cache
 system expects.
 
-Once you've created that database table, set your ``CACHE_BACKEND`` setting to
-``"db://tablename"``, where ``tablename`` is the name of the database table.
-In this example, the cache table's name is ``my_cache_table``::
+Once you've created that database table, set your :setting:`CACHE_BACKEND`
+setting to ``"db://tablename"``, where ``tablename`` is the name of the
+database table. In this example, the cache table's name is
+``my_cache_table``::
 
 CACHE_BACKEND = 'db://my_cache_table'
 
@@ -181,8 +184,8 @@
 --
 
 To store cached items on a filesystem, use the ``"file://"`` cache type for
-``CACHE_BACKEND``. For example, to store cached data in 
``/var/tmp/django_cache``,
-use this setting::
+:setting:`CACHE_BACKEND`. For example, to store cached data in
+``/var/tmp/django_cache``, use this setting::
 
 CACHE_BACKEND = 'file:///var/tmp/django_cache'
 
@@ -212,8 +215,8 @@
 
 If you want the speed advantages of in-memory caching but don't have the
 capability of running Memcached, consider the local-memory cache backend. This
-cache is multi-process and thread-safe. To use it, set ``CACHE_BACKEND`` to
-``"locmem://"``. For example::
+cache i

[Changeset] r14675 - django/trunk/docs/releases

2010-11-21 Thread noreply
Author: gabrielhurley
Date: 2010-11-22 00:08:38 -0600 (Mon, 22 Nov 2010)
New Revision: 14675

Modified:
   django/trunk/docs/releases/1.3-alpha-2.txt
Log:
Various nominal corrections for grammatical consistency, typos, and crossref 
targets.

Modified: django/trunk/docs/releases/1.3-alpha-2.txt
===
--- django/trunk/docs/releases/1.3-alpha-2.txt  2010-11-21 19:29:15 UTC (rev 
14674)
+++ django/trunk/docs/releases/1.3-alpha-2.txt  2010-11-22 06:08:38 UTC (rev 
14675)
@@ -19,24 +19,24 @@
 Further tweaks to the staticfiles app
 ~
 
-Django 1.3 ships with a new contrib app ``'django.contrib.staticfiles'``
-to help developers handle the static media files (images, CSS, Javascript,
+Django 1.3 ships with a new contrib app :mod:`django.contrib.staticfiles`
+to help developers handle the static media files (images, CSS, JavaScript,
 etc.) that are needed to render a complete web page.
 
-``staticfiles`` ships with the ability to automatically serve static files
-during development (if the :setting:`DEBUG` is ``True``) when using the
-:djadmin:`runserver` management command. Based on feedback from the
-community this release adds two new options to the ``runserver`` command
-to modify this behaviour:
+The :mod:`~django.contrib.staticfiles` app ships with the ability to
+automatically serve static files during development (if the :setting:`DEBUG`
+setting is ``True``) when using the :djadmin:`runserver` management command.
+Based on feedback from the community this release adds two new options to the
+:djadmin:`runserver` command to modify this behaviour:
 
-* ``--nostatic``: prevents the ``runserver`` command from serving files
-  completely
+* ``--nostatic``: prevents the :djadmin:`runserver` command from serving
+  files completely.
 
-* ``--insecure``: enables serving of static files even if stupidly
-  running in with :setting:`DEBUG` set to False
+* ``--insecure``: enables serving of static files even if running with
+  :setting:`DEBUG` set to False. (This is **not** recommended!)
 
-See the :doc:`reference documentation of the app `
-for more details or learn how to :doc:`manage static files
+See the :doc:`staticfiles reference documentation `
+for more details, or learn :doc:`how to manage static files
 `.
 
 Translation comments
@@ -61,40 +61,39 @@
 Introduction of STATIC_URL and STATIC_ROOT settings
 ~~~
 
-The newly introduced :doc:`/ref/contrib/staticfiles` app extends Django's
-abilities to handle static app and project files, required the additon of
-settings to refer to those files in templates and code, especially in
-contrast to the :setting:`MEDIA_URL` and :setting:`MEDIA_ROOT` settings that
-refer to user-uploaded files.
+The newly introduced :mod:`~django.contrib.staticfiles` app -- which extends
+Django's abilities to handle static files for apps and projects -- required the
+additon of two new settings to refer to those files in templates and code,
+especially in contrast to the :setting:`MEDIA_URL` and :setting:`MEDIA_ROOT`
+settings that refer to user-uploaded files.
 
 Prior to 1.3 alpha 2 these settings were called ``STATICFILES_URL`` and
-``STATICFILES_ROOT`` to follow the naming scheme for app centric settings.
+``STATICFILES_ROOT`` to follow the naming scheme for app-centric settings.
 Based on feedback from the community it became apparent that those settings
-created confusion, especially given the fact handling static files is also
-desired outside the use of the optional ``staticfiles`` app.
+created confusion, especially given the fact that handling static files is also
+desired outside the use of the optional :mod:`~django.contrib.staticfiles` app.
 
-As a result, we take the followig steps to rectify the issue:
+As a result, we took the following steps to rectify the issue:
 
-  * Two new global settings that will be used by -- **but are not limited
-to** -- the :doc:`staticfiles` app:
+  * Two new global settings were added that will be used by, **but are not
+limited to**, the :doc:`staticfiles` app:
 
 * :setting:`STATIC_ROOT` (formally ``STATICFILES_ROOT``)
 
 * :setting:`STATIC_URL` (formally ``STATICFILES_URL``)
 
-  * Moving the
-
``django.contrib.staticfiles.templatetags.staticfiles.get_staticfiles_prefix``
-template tag to the core (``django.templatetags.static``) and renaming
-it to :ttag:`get_static_prefix`.
+  * The 
``django.contrib.staticfiles.templatetags.staticfiles.get_staticfiles_prefix``
+template tag was moved to Django's core (``django.templatetags.static``) 
and
+renamed to :ttag:`get_static_prefix`.
 
-  * Moving the context processor
-``django.contrib.staticfiles.context_processors.staticfiles`` to the
-core (``django.core.context_processors.static``) and renaming it to
+  * The ``django.contrib.staticfiles.context_processors.staticfiles`

Re: [Django] #14748: Missing docummentation for FormPreview methods

2010-11-21 Thread Django
#14748: Missing docummentation for FormPreview methods
+---
  Reporter:  Honza_Kral | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

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

Comment:

 There are a number of problems with the docs for `FormPreview`...

  1. They're badly organized. All the attribute and method reference
 documentation for `FormPreview` should live together under
 [http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-
 preview/#django.contrib.formtools.FormPreview] rather than being spread
 across that section and "advanced methods".

  2. Important methods which explicitly (in the code) are marked as
 "METHODS SUBCLASSES MIGHT OVERRIDE IF APPROPRIATE" are not documented at
 all.

  3. The crossref targets for the `FormPreview` class are all wrong. They
 are currently pointed at `django.contrib.formtools.FormPreview` when they
 should be pointed at `django.contrib.formtools.preview.FormPreview`. I
 assume this is either a lack of indentation or a lack of a `currentmodule`
 directive.

-- 
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] #14736: Typo in documentation

2010-11-21 Thread Django
#14736: Typo in documentation
+---
  Reporter:  DD | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:  typo easy-pickings
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * milestone:  => 1.3
  * keywords:  typo => typo easy-pickings
  * needs_docs:  => 0
  * 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.



[Changeset] r14667 - in django/trunk: django/forms docs/releases docs/topics/forms tests/regressiontests/forms/tests

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 11:27:01 -0600 (Sun, 21 Nov 2010)
New Revision: 14667

Modified:
   django/trunk/django/forms/formsets.py
   django/trunk/docs/releases/1.3.txt
   django/trunk/docs/topics/forms/formsets.txt
   django/trunk/tests/regressiontests/forms/tests/formsets.py
Log:
Fixed #11418 -- formset.cleaned_data no longer raises AttributeError when 
is_valid is True. Thanks mlavin!

This also introduces a slightly backwards-incompatible change in
FormSet's behavior, see the release docs for details.

Modified: django/trunk/django/forms/formsets.py
===
--- django/trunk/django/forms/formsets.py   2010-11-21 17:18:26 UTC (rev 
14666)
+++ django/trunk/django/forms/formsets.py   2010-11-21 17:27:01 UTC (rev 
14667)
@@ -37,8 +37,8 @@
 self.is_bound = data is not None or files is not None
 self.prefix = prefix or self.get_default_prefix()
 self.auto_id = auto_id
-self.data = data
-self.files = files
+self.data = data or {}
+self.files = files or {}
 self.initial = initial
 self.error_class = error_class
 self._errors = None
@@ -51,7 +51,7 @@
 
 def _management_form(self):
 """Returns the ManagementForm instance for this FormSet."""
-if self.data or self.files:
+if self.is_bound:
 form = ManagementForm(self.data, auto_id=self.auto_id, 
prefix=self.prefix)
 if not form.is_valid():
 raise ValidationError('ManagementForm data is missing or has 
been tampered with')
@@ -66,7 +66,7 @@
 
 def total_form_count(self):
 """Returns the total number of forms in this FormSet."""
-if self.data or self.files:
+if self.is_bound:
 return self.management_form.cleaned_data[TOTAL_FORM_COUNT]
 else:
 initial_forms = self.initial_form_count()
@@ -81,7 +81,7 @@
 
 def initial_form_count(self):
 """Returns the number of forms that are required in this FormSet."""
-if self.data or self.files:
+if self.is_bound:
 return self.management_form.cleaned_data[INITIAL_FORM_COUNT]
 else:
 # Use the length of the inital data if it's there, 0 otherwise.
@@ -101,7 +101,7 @@
 Instantiates and returns the i-th form instance in a formset.
 """
 defaults = {'auto_id': self.auto_id, 'prefix': self.add_prefix(i)}
-if self.data or self.files:
+if self.is_bound:
 defaults['data'] = self.data
 defaults['files'] = self.files
 if self.initial:
@@ -133,7 +133,7 @@
 'prefix': self.add_prefix('__prefix__'),
 'empty_permitted': True,
 }
-if self.data or self.files:
+if self.is_bound:
 defaults['data'] = self.data
 defaults['files'] = self.files
 defaults.update(kwargs)

Modified: django/trunk/docs/releases/1.3.txt
===
--- django/trunk/docs/releases/1.3.txt  2010-11-21 17:18:26 UTC (rev 14666)
+++ django/trunk/docs/releases/1.3.txt  2010-11-21 17:27:01 UTC (rev 14667)
@@ -266,7 +266,37 @@
   has been removed from the province list in favor of the new
   official designation "Aceh (ACE)".
 
+FormSet updates
+~~~
 
+In Django 1.3 ``FormSet`` creation behavior is modified slightly. Historically
+the class didn't make a distinction between not being passed data and being
+passed empty dictionary. This was inconsistent with behavior in other parts of
+the framework. Starting with 1.3 if you pass in empty dictionary the
+``FormSet`` will raise a ``ValidationError``.
+
+For example with a ``FormSet``::
+
+>>> class ArticleForm(Form):
+... title = CharField()
+... pub_date = DateField()
+>>> ArticleFormSet = formset_factory(ArticleForm)
+
+the following code will raise a ``ValidationError``::
+
+>>> ArticleFormSet({})
+Traceback (most recent call last):
+...
+ValidationError: [u'ManagementForm data is missing or has been tampered 
with']
+
+if you need to instantiate an empty ``FormSet``, don't pass in the data or use
+``None``::
+
+>>> formset = ArticleFormSet()
+>>> formset = ArticleFormSet(data=None)
+
+
+
 .. _deprecated-features-1.3:
 
 Features deprecated in 1.3

Modified: django/trunk/docs/topics/forms/formsets.txt
===
--- django/trunk/docs/topics/forms/formsets.txt 2010-11-21 17:18:26 UTC (rev 
14666)
+++ django/trunk/docs/topics/forms/formsets.txt 2010-11-21 17:27:01 UTC (rev 
14667)
@@ -100,7 +100,12 @@
 all forms in the formset::
 
 >>> ArticleFormSet = formset_factory(ArticleForm)
->>> formset = ArticleFormSet({})
+>>> data = {
+... 'form-TOTAL_FORMS': u'1',
+... 'form-INITIAL_FORMS': u'0',
+... 'form-MAX_NUM_FORMS': u'',
+... }
+

[Django] #14749: add __enter__ and __exit__ to django.core.files.File

2010-11-21 Thread Django
#14749: add __enter__ and __exit__ to django.core.files.File
--+-
 Reporter:  apollo13  |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  File uploads/storage  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 The summary pretty much says it; I'll attach 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] #14731: [Patch] Change 14413 breaks old fixtures with permissions

2010-11-21 Thread Django
#14731: [Patch] Change 14413 breaks old fixtures with permissions
-+--
  Reporter:  chipx86 | Owner:  nobody   
Status:  new | Milestone:  1.3  
 Component:  Authentication  |   Version:  1.3-alpha
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  1
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

Comment:

 Changing that to a list shouldn't affect anything, from a performance
 perspective (might even speed stuff up by a miniscule margin).  I'd
 like a test though, its subtly enough that it wouldn't surprise me if it
 was reintroduced ;)

-- 
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] #14284: Support for Google Maps version 3

2010-11-21 Thread Django
#14284: Support for Google Maps version 3
+---
  Reporter:  DaveWP196  | Owner:  ericpalakovichcarr
Status:  assigned   | Milestone:
 Component:  GIS|   Version:  1.2   
Resolution: |  Keywords:  Google Maps   
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  1  |   Needs_tests:  1 
Needs_better_patch:  1  |  
+---
Changes (by ericpalakovichcarr):

  * needs_better_patch:  0 => 1
  * has_patch:  0 => 1
  * needs_tests:  0 => 1
  * needs_docs:  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] #5833: Custom FilterSpecs

2010-11-21 Thread Django
#5833: Custom FilterSpecs
---+
  Reporter:  Honza_Kral| Owner:  jkocherhans
 
Status:  assigned  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  nfa-someday 
list_filter filterspec nfa-changelist ep2008
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Changes (by brentp):

 * cc: bpede...@gmail.com (removed)

-- 
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] #13950: Add "post save" hook to ModelAdmin class

2010-11-21 Thread Django
#13950: Add "post save" hook to ModelAdmin class
---+
  Reporter:  3point2   | Owner:  pandres
Status:  closed| Milestone: 
 Component:  django.contrib.admin  |   Version:  1.2
Resolution:  wontfix   |  Keywords: 
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  1  
Needs_better_patch:  1 |  
---+
Changes (by kmtracey):

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

Comment:

 Replying to [comment:3 3point2]:
 > * The inline invoice entries are now saved. At this point, it's no
 longer possible to hook into the save process to calculate the invoice's
 total. The only workaround would be to have each invoice entry update its
 parent invoice's total when it is saved, which will cause a lot of
 unnecessary save() calls on the invoice (one for each entry).

 No, you can override the !ModelAdmin's save_formset (see:
 
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.save_formset)
 and add whatever code you like after all the inline models have been
 saved.

 >
 > My post_save hook allows the user to call a function *after* the inlines
 have been saved. This allows the total to be calculated using
 invoice.invoiceentry_set.all()

 So does the existing capability of overriding save_formset. I don't see
 why another way is needed.

-- 
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] #14731: [Patch] Change 14413 breaks old fixtures with permissions

2010-11-21 Thread Django
#14731: [Patch] Change 14413 breaks old fixtures with permissions
-+--
  Reporter:  chipx86 | Owner:  nobody   
Status:  new | Milestone:  1.3  
 Component:  Authentication  |   Version:  1.3-alpha
Resolution:  |  Keywords:   
 Stage:  Unreviewed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by kmtracey):

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

Comment:

 Since this is a reported regression, it must be resolved before 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] #14703: memcached.set_many() should not special case unicode data

2010-11-21 Thread Django
#14703: memcached.set_many() should not special case unicode data
---+
  Reporter:  gsakkis   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Cache system  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 This is much like #13686. All get/set-type functions should be consistent
 here.

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

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



Re: [Django] #14506: Crash on HEAD request

2010-11-21 Thread Django
#14506: Crash on HEAD request
+---
  Reporter:  azurit | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by kmtracey):

 Replying to [comment:4 azurit]:
 > Replying to [comment:3 jezdez]:
 > > Looks like request.user is not set. Which means the Auth middleware
 was not successfully run.
 > [[BR]]
 > Yes, Auth middleware is NOT loaded.

 If you don't have the auth middleware loaded, why do you have the XView
 middleware loaded (that's the code that is generating the exception)? That
 middleware is documented
 
(http://docs.djangoproject.com/en/dev/ref/middleware/#django.middleware.doc.django.middleware.doc.XViewMiddleware)
 as providing some function for the admindocs feature, which is only
 accessible from admin, which requires the auth middleware to be in place.
 So XView assumes auth middleware is loaded.

 Leaving open since I guess the XView code could handle this more
 gracefully, but the easiest fix would seem to be for you to remove it from
 your middleware setting.

-- 
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] #8997: Misleading error message when calling get_absolute_url

2010-11-21 Thread Django
#8997: Misleading error message when calling get_absolute_url
-+--
  Reporter:  Rob   | Owner:  
joshlory
Status:  assigned| 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 joshlory):

 * cc: lor...@missouri.edu (added)
  * status:  new => assigned

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

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



Re: [Django] #14717: Connection error not handled

2010-11-21 Thread Django
#14717: Connection error not handled
+---
  Reporter:  nijel  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

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

Comment:

 Handled how? The database being unreachable is a catastrophic error -- in
 general there is no reasonable way to recover from that. The effect of
 allowing the exception to propagate will be for a server error page to be
 returned to whatever browser generated the current request, and an error
 email to be sent to the admins containing the traceback (assuming DEBUG is
 off, with DEBUG on a debug error page will get returned to the the
 browser). That seems to me to be about the best that can be done when
 current circumstances make it impossible to correctly serve a request --
 the end user gets told that something is currently wrong with the site,
 and the admins get the details of what it is.

 (Also as a side note: why would MySQL alone be handled any differently
 from the other database backends here? If we were to change how "database
 unreachable" is handled, I would think we would want to maintain
 consistency among them and not make any one behave differently for this
 case.)

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

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



[Changeset] r14674 - in django/trunk: django/contrib/admin django/contrib/admin/views django/db/models docs/ref/contrib/admin docs/releases tests/regressiontests/admin_views tests/regressiontests/admi

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 13:29:15 -0600 (Sun, 21 Nov 2010)
New Revision: 14674

Added:
   django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-books.xml
Modified:
   django/trunk/django/contrib/admin/filterspecs.py
   django/trunk/django/contrib/admin/util.py
   django/trunk/django/contrib/admin/validation.py
   django/trunk/django/contrib/admin/views/main.py
   django/trunk/django/db/models/related.py
   django/trunk/docs/ref/contrib/admin/index.txt
   django/trunk/docs/releases/1.3.txt
   django/trunk/tests/regressiontests/admin_views/customadmin.py
   django/trunk/tests/regressiontests/admin_views/models.py
   django/trunk/tests/regressiontests/admin_views/tests.py
   django/trunk/tests/regressiontests/modeladmin/tests.py
Log:
Fixed #3400 -- Support for lookup separator with list_filter admin option. 
Thanks to DrMeers and vitek_pliska for the patch!

Modified: django/trunk/django/contrib/admin/filterspecs.py
===
--- django/trunk/django/contrib/admin/filterspecs.py2010-11-21 19:00:40 UTC 
(rev 14673)
+++ django/trunk/django/contrib/admin/filterspecs.py2010-11-21 19:29:15 UTC 
(rev 14674)
@@ -11,22 +11,32 @@
 from django.utils.translation import ugettext as _
 from django.utils.html import escape
 from django.utils.safestring import mark_safe
+from django.contrib.admin.util import get_model_from_relation, \
+reverse_field_path, get_limit_choices_to_from_path
 import datetime
 
 class FilterSpec(object):
 filter_specs = []
-def __init__(self, f, request, params, model, model_admin):
+def __init__(self, f, request, params, model, model_admin,
+ field_path=None):
 self.field = f
 self.params = params
+self.field_path = field_path
+if field_path is None:
+if isinstance(f, models.related.RelatedObject):
+self.field_path = f.var_name
+else:
+self.field_path = f.name
 
 def register(cls, test, factory):
 cls.filter_specs.append((test, factory))
 register = classmethod(register)
 
-def create(cls, f, request, params, model, model_admin):
+def create(cls, f, request, params, model, model_admin, field_path=None):
 for test, factory in cls.filter_specs:
 if test(f):
-return factory(f, request, params, model, model_admin)
+return factory(f, request, params, model, model_admin,
+   field_path=field_path)
 create = classmethod(create)
 
 def has_output(self):
@@ -52,14 +62,20 @@
 return mark_safe("".join(t))
 
 class RelatedFilterSpec(FilterSpec):
-def __init__(self, f, request, params, model, model_admin):
-super(RelatedFilterSpec, self).__init__(f, request, params, model, 
model_admin)
-if isinstance(f, models.ManyToManyField):
-self.lookup_title = f.rel.to._meta.verbose_name
+def __init__(self, f, request, params, model, model_admin,
+ field_path=None):
+super(RelatedFilterSpec, self).__init__(
+f, request, params, model, model_admin, field_path=field_path)
+
+other_model = get_model_from_relation(f)
+if isinstance(f, (models.ManyToManyField,
+  models.related.RelatedObject)):
+# no direct field on this model, get name from other model
+self.lookup_title = other_model._meta.verbose_name
 else:
-self.lookup_title = f.verbose_name
-rel_name = f.rel.get_related_field().name
-self.lookup_kwarg = '%s__%s__exact' % (f.name, rel_name)
+self.lookup_title = f.verbose_name # use field name
+rel_name = other_model._meta.pk.name
+self.lookup_kwarg = '%s__%s__exact' % (self.field_path, rel_name)
 self.lookup_val = request.GET.get(self.lookup_kwarg, None)
 self.lookup_choices = f.get_choices(include_blank=False)
 
@@ -78,12 +94,17 @@
'query_string': cl.get_query_string({self.lookup_kwarg: 
pk_val}),
'display': val}
 
-FilterSpec.register(lambda f: bool(f.rel), RelatedFilterSpec)
+FilterSpec.register(lambda f: (
+hasattr(f, 'rel') and bool(f.rel) or
+isinstance(f, models.related.RelatedObject)), RelatedFilterSpec)
 
 class ChoicesFilterSpec(FilterSpec):
-def __init__(self, f, request, params, model, model_admin):
-super(ChoicesFilterSpec, self).__init__(f, request, params, model, 
model_admin)
-self.lookup_kwarg = '%s__exact' % f.name
+def __init__(self, f, request, params, model, model_admin,
+ field_path=None):
+super(ChoicesFilterSpec, self).__init__(f, request, params, model,
+model_admin,
+field_path=field_path)
+self.lookup_kwarg = '%s__exact' % self.field_path
 self.l

Re: [Django] #5833: Custom FilterSpecs

2010-11-21 Thread Django
#5833: Custom FilterSpecs
---+
  Reporter:  Honza_Kral| Owner:  jkocherhans
 
Status:  assigned  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  nfa-someday 
list_filter filterspec nfa-changelist ep2008
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Changes (by vitek_pliska):

 * cc: vitek_pliska (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.



[Changeset] r14671 - in django/trunk: django/core/files tests/modeltests/files tests/regressiontests/file_storage tests/regressiontests/test_utils

2010-11-21 Thread noreply
Author: Alex
Date: 2010-11-21 11:51:41 -0600 (Sun, 21 Nov 2010)
New Revision: 14671

Added:
   django/trunk/tests/modeltests/files/tests_25.py
   django/trunk/tests/regressiontests/test_utils/tests_25.py
Removed:
   django/trunk/tests/regressiontests/test_utils/python_25.py
Modified:
   django/trunk/django/core/files/base.py
   django/trunk/tests/modeltests/files/tests.py
   django/trunk/tests/regressiontests/file_storage/tests.py
   django/trunk/tests/regressiontests/test_utils/tests.py
Log:
Fixed #14749 -- added support for using Django's file object as context 
managers.  Thanks to Florian Apolloner for the patch.

Modified: django/trunk/django/core/files/base.py
===
--- django/trunk/django/core/files/base.py  2010-11-21 17:48:52 UTC (rev 
14670)
+++ django/trunk/django/core/files/base.py  2010-11-21 17:51:41 UTC (rev 
14671)
@@ -101,6 +101,12 @@
 if buffer_ is not None:
 yield buffer_
 
+def __enter__(self):
+return self
+
+def __exit__(self, exc_type, exc_value, tb):
+self.close()
+
 def open(self, mode=None):
 if not self.closed:
 self.seek(0)

Modified: django/trunk/tests/modeltests/files/tests.py
===
--- django/trunk/tests/modeltests/files/tests.py2010-11-21 17:48:52 UTC 
(rev 14670)
+++ django/trunk/tests/modeltests/files/tests.py2010-11-21 17:51:41 UTC 
(rev 14671)
@@ -1,4 +1,5 @@
 import shutil
+import sys
 
 from django.core.cache import cache
 from django.core.files.base import ContentFile
@@ -6,6 +7,8 @@
 from django.test import TestCase
 
 from models import Storage, temp_storage, temp_storage_location
+if sys.version_info >= (2, 5):
+from tests_25 import FileObjTests
 
 
 class FileTests(TestCase):
@@ -97,4 +100,3 @@
 obj2.normal.delete()
 obj3.default.delete()
 obj4.random.delete()
-

Added: django/trunk/tests/modeltests/files/tests_25.py
===
--- django/trunk/tests/modeltests/files/tests_25.py 
(rev 0)
+++ django/trunk/tests/modeltests/files/tests_25.py 2010-11-21 17:51:41 UTC 
(rev 14671)
@@ -0,0 +1,17 @@
+from __future__ import with_statement
+
+import tempfile
+
+from django.core.files import File
+from django.utils.unittest import TestCase
+
+
+class FileObjTests(TestCase):
+def test_context_manager(self):
+orig_file = tempfile.TemporaryFile()
+base_file = File(orig_file)
+with base_file as f:
+self.assertIs(base_file, f)
+self.assertFalse(f.closed)
+self.assertTrue(f.closed)
+self.assertTrue(orig_file.closed)

Modified: django/trunk/tests/regressiontests/file_storage/tests.py
===
--- django/trunk/tests/regressiontests/file_storage/tests.py2010-11-21 
17:48:52 UTC (rev 14670)
+++ django/trunk/tests/regressiontests/file_storage/tests.py2010-11-21 
17:51:41 UTC (rev 14671)
@@ -4,8 +4,17 @@
 import sys
 import tempfile
 import time
-from cStringIO import StringIO
 from datetime import datetime, timedelta
+try:
+from cStringIO import StringIO
+except ImportError:
+from StringIO import StringIO
+
+try:
+import threading
+except ImportError:
+import dummy_threading as threading
+
 from django.conf import settings
 from django.core.exceptions import SuspiciousOperation
 from django.core.files.base import ContentFile, File
@@ -15,11 +24,6 @@
 from django.core.exceptions import ImproperlyConfigured
 from django.utils import unittest
 
-try:
-import threading
-except ImportError:
-import dummy_threading as threading
-
 # Try to import PIL in either of the two ways it can end up installed.
 # Checking for the existence of Image is enough for CPython, but
 # for PyPy, you need to check for the underlying modules
@@ -31,6 +35,7 @@
 except ImportError:
 Image = None
 
+
 class GetStorageClassTests(unittest.TestCase):
 def assertRaisesErrorWithMessage(self, error, message, callable,
 *args, **kwargs):
@@ -430,6 +435,7 @@
 Multiple calls of get_image_dimensions() should return the same size.
 """
 from django.core.files.images import ImageFile
+
 img_path = os.path.join(os.path.dirname(__file__), "test.png")
 image = ImageFile(open(img_path, 'rb'))
 image_pil = Image.open(img_path)

Deleted: django/trunk/tests/regressiontests/test_utils/python_25.py
===
--- django/trunk/tests/regressiontests/test_utils/python_25.py  2010-11-21 
17:48:52 UTC (rev 14670)
+++ django/trunk/tests/regressiontests/test_utils/python_25.py  2010-11-21 
17:51:41 UTC (rev 14671)
@@ -1,28 +0,0 @@
-from __future__ import with_statement
-
-from django.test import TestCase
-
-from models import Person

Re: [Django] #11108: add a ModelAdmin.delete_model method, similar to ModelAdmin.save_model (+patch)

2010-11-21 Thread Django
#11108: add a ModelAdmin.delete_model method, similar to ModelAdmin.save_model
(+patch)
---+
  Reporter:  thomas| Owner:  nobody 
Status:  new   | Milestone:  1.3
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords:  sprintnov13
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Comment (by apollo13):

 New patch with tests for 'save_model' and 'delete_model'

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

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



[Changeset] r14673 - in django/trunk: django/contrib/admin docs/ref/contrib/admin docs/topics/db tests/regressiontests/admin_views

2010-11-21 Thread noreply
Author: Alex
Date: 2010-11-21 13:00:40 -0600 (Sun, 21 Nov 2010)
New Revision: 14673

Modified:
   django/trunk/django/contrib/admin/options.py
   django/trunk/docs/ref/contrib/admin/index.txt
   django/trunk/docs/topics/db/multi-db.txt
   django/trunk/tests/regressiontests/admin_views/models.py
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Fixed #11108 -- added ModelAdmin.delete_model, a hook with which to perform 
custom pre-post delete behavior.  Thanks to Florian Apolloner for the patch.

Modified: django/trunk/django/contrib/admin/options.py
===
--- django/trunk/django/contrib/admin/options.py2010-11-21 18:08:00 UTC 
(rev 14672)
+++ django/trunk/django/contrib/admin/options.py2010-11-21 19:00:40 UTC 
(rev 14673)
@@ -601,6 +601,12 @@
 """
 obj.save()
 
+def delete_model(self, requet, obj):
+"""
+Given a model instance delete it from the database.
+"""
+obj.delete()
+
 def save_formset(self, request, form, formset, change):
 """
 Given an inline formset save it to the database.
@@ -1122,7 +1128,7 @@
 raise PermissionDenied
 obj_display = force_unicode(obj)
 self.log_deletion(request, obj, obj_display)
-obj.delete()
+self.delete_model(request, obj)
 
 self.message_user(request, _('The %(name)s "%(obj)s" was deleted 
successfully.') % {'name': force_unicode(opts.verbose_name), 'obj': 
force_unicode(obj_display)})
 

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2010-11-21 18:08:00 UTC 
(rev 14672)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2010-11-21 19:00:40 UTC 
(rev 14673)
@@ -757,6 +757,12 @@
 ``ModelAdmin`` methods
 --
 
+.. warning::
+
+:meth:`ModelAdmin.save_model` and :meth:`ModelAdmin.delete_model` must
+save/delete the object, they are not for veto purposes, rather they allow
+you to perform extra operations.
+
 .. method:: ModelAdmin.save_model(self, request, obj, form, change)
 
 The ``save_model`` method is given the ``HttpRequest``, a model instance,
@@ -770,6 +776,13 @@
 obj.user = request.user
 obj.save()
 
+.. method:: ModelAdmin.delete_model(self, request, obj)
+
+.. versionadded:: 1.3
+
+The ``delete_model`` method is given the ``HttpRequest`` and a model instance.
+Use this method to do pre- or post-delete operations.
+
 .. method:: ModelAdmin.save_formset(self, request, form, formset, change)
 
 The ``save_formset`` method is given the ``HttpRequest``, the parent

Modified: django/trunk/docs/topics/db/multi-db.txt
===
--- django/trunk/docs/topics/db/multi-db.txt2010-11-21 18:08:00 UTC (rev 
14672)
+++ django/trunk/docs/topics/db/multi-db.txt2010-11-21 19:00:40 UTC (rev 
14673)
@@ -458,7 +458,7 @@
 need to write custom :class:`~django.contrib.admin.ModelAdmin` classes
 that will direct the admin to use a specific database for content.
 
-``ModelAdmin`` objects have four methods that require customization for
+``ModelAdmin`` objects have five methods that require customization for
 multiple-database support::
 
 class MultiDBModelAdmin(admin.ModelAdmin):
@@ -469,6 +469,10 @@
 # Tell Django to save objects to the 'other' database.
 obj.save(using=self.using)
 
+def delete_model(self, requqest, obj):
+# Tell Django to delete objects from the 'other' database
+obj.delete(using=self.using)
+
 def queryset(self, request):
 # Tell Django to look for objects on the 'other' database.
 return super(MultiDBModelAdmin, 
self).queryset(request).using(self.using)

Modified: django/trunk/tests/regressiontests/admin_views/models.py
===
--- django/trunk/tests/regressiontests/admin_views/models.py2010-11-21 
18:08:00 UTC (rev 14672)
+++ django/trunk/tests/regressiontests/admin_views/models.py2010-11-21 
19:00:40 UTC (rev 14673)
@@ -107,6 +107,25 @@
 modeladmin_year.admin_order_field = 'date'
 modeladmin_year.short_description = None
 
+def delete_model(self, request, obj):
+EmailMessage(
+'Greetings from a deleted object',
+'I hereby inform you that some user deleted me',
+'f...@example.com',
+['t...@example.com']
+).send()
+return super(ArticleAdmin, self).delete_model(request, obj)
+
+def save_model(self, request, obj, form, change=True):
+EmailMessage(
+'Greetings from a created object',
+'I hereby inform you that some user created me',
+'f...@example.com',
+['t...@example.com']
+

[Changeset] r14669 - django/branches/releases/1.2.X/django/dispatch

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 11:35:48 -0600 (Sun, 21 Nov 2010)
New Revision: 14669

Modified:
   django/branches/releases/1.2.X/django/dispatch/dispatcher.py
Log:
[1.2.X] Preventing problems possibly introduced by r14662

acquire a lock before entering a try block that ends with the lock's
release. Thanks for the catch Alex.

Backport of r14668 from trunk.

Modified: django/branches/releases/1.2.X/django/dispatch/dispatcher.py
===
--- django/branches/releases/1.2.X/django/dispatch/dispatcher.py
2010-11-21 17:34:21 UTC (rev 14668)
+++ django/branches/releases/1.2.X/django/dispatch/dispatcher.py
2010-11-21 17:35:48 UTC (rev 14669)
@@ -99,8 +99,8 @@
 if weak:
 receiver = saferef.safeRef(receiver, 
onDelete=self._remove_receiver)
 
+self.lock.acquire()
 try:
-self.lock.acquire()
 for r_key, _ in self.receivers:
 if r_key == lookup_key:
 break
@@ -136,8 +136,8 @@
 else:
 lookup_key = (_make_id(receiver), _make_id(sender))
 
+self.lock.acquire()
 try:
-self.lock.acquire()
 for index in xrange(len(self.receivers)):
 (r_key, _) = self.receivers[index]
 if r_key == lookup_key:
@@ -237,8 +237,8 @@
 Remove dead receivers from connections.
 """
 
+self.lock.acquire()
 try:
-self.lock.acquire()
 to_remove = []
 for key, connected_receiver in self.receivers:
 if connected_receiver == receiver:

-- 
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] r14672 - django/trunk/django/contrib/admin

2010-11-21 Thread noreply
Author: Alex
Date: 2010-11-21 12:08:00 -0600 (Sun, 21 Nov 2010)
New Revision: 14672

Modified:
   django/trunk/django/contrib/admin/options.py
Log:
Removed some deprecated code that survived [14138].

Modified: django/trunk/django/contrib/admin/options.py
===
--- django/trunk/django/contrib/admin/options.py2010-11-21 17:51:41 UTC 
(rev 14671)
+++ django/trunk/django/contrib/admin/options.py2010-11-21 18:08:00 UTC 
(rev 14672)
@@ -1176,34 +1176,6 @@
 "admin/object_history.html"
 ], context, context_instance=context_instance)
 
-#
-# DEPRECATED methods.
-#
-def __call__(self, request, url):
-"""
-DEPRECATED: this is the old way of URL resolution, replaced by
-``get_urls()``. This only called by AdminSite.root(), which is also
-deprecated.
-
-Again, remember that the following code only exists for
-backwards-compatibility. Any new URLs, changes to existing URLs, or
-whatever need to be done up in get_urls(), above!
-
-This function still exists for backwards-compatibility; it will be
-removed in Django 1.3.
-"""
-# Delegate to the appropriate method, based on the URL.
-if url is None:
-return self.changelist_view(request)
-elif url == "add":
-return self.add_view(request)
-elif url.endswith('/history'):
-return self.history_view(request, unquote(url[:-8]))
-elif url.endswith('/delete'):
-return self.delete_view(request, unquote(url[:-7]))
-else:
-return self.change_view(request, unquote(url))
-
 class InlineModelAdmin(BaseModelAdmin):
 """
 Options for inline editing of ``model`` instances.

-- 
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] r14670 - django/trunk/tests/regressiontests/model_formsets_regress

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 11:48:52 -0600 (Sun, 21 Nov 2010)
New Revision: 14670

Modified:
   django/trunk/tests/regressiontests/model_formsets_regress/tests.py
Log:
Fixed failing tests caused by r14667

Modified: django/trunk/tests/regressiontests/model_formsets_regress/tests.py
===
--- django/trunk/tests/regressiontests/model_formsets_regress/tests.py  
2010-11-21 17:35:48 UTC (rev 14669)
+++ django/trunk/tests/regressiontests/model_formsets_regress/tests.py  
2010-11-21 17:48:52 UTC (rev 14670)
@@ -196,12 +196,12 @@
 
 def test_inlineformset_factory_default(self):
 Formset = inlineformset_factory(User, UserSite, form=UserSiteForm)
-form = Formset({}).forms[0]
+form = Formset().forms[0]
 self.assertTrue(isinstance(form['data'].field.widget, CustomWidget))
 
 def test_modelformset_factory_default(self):
 Formset = modelformset_factory(UserSite, form=UserSiteForm)
-form = Formset({}).forms[0]
+form = Formset().forms[0]
 self.assertTrue(isinstance(form['data'].field.widget, CustomWidget))
 
 def assertCallbackCalled(self, callback):

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

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 11:34:21 -0600 (Sun, 21 Nov 2010)
New Revision: 14668

Modified:
   django/trunk/django/dispatch/dispatcher.py
Log:
Preventing problems possibly introduced by r14662

acquire a lock before entering a try block that ends with the lock's
release. Thanks for the catch Alex.

Modified: django/trunk/django/dispatch/dispatcher.py
===
--- django/trunk/django/dispatch/dispatcher.py  2010-11-21 17:27:01 UTC (rev 
14667)
+++ django/trunk/django/dispatch/dispatcher.py  2010-11-21 17:34:21 UTC (rev 
14668)
@@ -99,8 +99,8 @@
 if weak:
 receiver = saferef.safeRef(receiver, 
onDelete=self._remove_receiver)
 
+self.lock.acquire()
 try:
-self.lock.acquire()
 for r_key, _ in self.receivers:
 if r_key == lookup_key:
 break
@@ -136,8 +136,8 @@
 else:
 lookup_key = (_make_id(receiver), _make_id(sender))
 
+self.lock.acquire()
 try:
-self.lock.acquire()
 for index in xrange(len(self.receivers)):
 (r_key, _) = self.receivers[index]
 if r_key == lookup_key:
@@ -237,8 +237,8 @@
 Remove dead receivers from connections.
 """
 
+self.lock.acquire()
 try:
-self.lock.acquire()
 to_remove = []
 for key, connected_receiver in self.receivers:
 if connected_receiver == receiver:

-- 
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] r14666 - django/trunk/django/db/backends

2010-11-21 Thread noreply
Author: ramiro
Date: 2010-11-21 11:18:26 -0600 (Sun, 21 Nov 2010)
New Revision: 14666

Modified:
   django/trunk/django/db/backends/creation.py
Log:
Added printing of the name of test database being created/destroyed, at 
verbosity level 2. Refs #14415.

Modified: django/trunk/django/db/backends/creation.py
===
--- django/trunk/django/db/backends/creation.py 2010-11-21 15:19:46 UTC (rev 
14665)
+++ django/trunk/django/db/backends/creation.py 2010-11-21 17:18:26 UTC (rev 
14666)
@@ -340,11 +340,14 @@
 Creates a test database, prompting the user for confirmation if the
 database already exists. Returns the name of the test database created.
 """
+test_database_name = self._create_test_db(verbosity, autoclobber)
+
 if verbosity >= 1:
-print "Creating test database '%s'..." % self.connection.alias
+test_db_repr = ''
+if verbosity >= 2:
+test_db_repr = " ('%s')" % test_database_name
+print "Creating test database for alias '%s'%s..." % 
(self.connection.alias, test_db_repr)
 
-test_database_name = self._create_test_db(verbosity, autoclobber)
-
 self.connection.close()
 self.connection.settings_dict["NAME"] = test_database_name
 
@@ -411,10 +414,13 @@
 Destroy a test database, prompting the user for confirmation if the
 database already exists. Returns the name of the test database created.
 """
-if verbosity >= 1:
-print "Destroying test database '%s'..." % self.connection.alias
 self.connection.close()
 test_database_name = self.connection.settings_dict['NAME']
+if verbosity >= 1:
+test_db_repr = ''
+if verbosity >= 2:
+test_db_repr = " ('%s')" % test_database_name
+print "Destroying test database for alias '%s'%s..." % 
(self.connection.alias, test_db_repr)
 self.connection.settings_dict['NAME'] = old_database_name
 
 self._destroy_test_db(test_database_name, verbosity)

-- 
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] #14082: modelform_factory should use the form's metaclass

2010-11-21 Thread Django
#14082: modelform_factory should use the form's metaclass
-+--
  Reporter:  jspiros | Owner:  Honza_Kral   
   
Status:  closed  | Milestone:   
   
 Component:  Forms   |   Version:  SVN  
   
Resolution:  worksforme  |  Keywords:  ModelForm, 
ModelFormMetaclass, modelform_factory
 Stage:  Accepted| Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  1
   
Needs_better_patch:  0   |  
-+--
Changes (by jakub_vysoky):

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

Comment:

 I hope I made myself clear, that it does work for me even without the
 patch. But maybe you need something more specific and you can put some
 more tests for that.

-- 
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] #14082: modelform_factory should use the form's metaclass

2010-11-21 Thread Django
#14082: modelform_factory should use the form's metaclass
---+
  Reporter:  jspiros   | Owner:  Honza_Kral 
 
Status:  assigned  | Milestone: 
 
 Component:  Forms |   Version:  SVN
 
Resolution:|  Keywords:  ModelForm, ModelFormMetaclass, 
modelform_factory
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Comment (by jakub_vysoky):

 I've made some tests for this, but it seems it really works.. Can you look
 at it?

 https://github.com/kvbik/django/commit/c342c3089ac169fbcf285b34f65a73fd834886a7

-- 
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] #14739: Segregate contrib.localflavor translations to their ownPO file/gettext domain?

2010-11-21 Thread Django
#14739: Segregate contrib.localflavor translations to their ownPO file/gettext
domain?
---+
  Reporter:  ramiro| Owner:  nobody
Status:  new   | Milestone:
 Component:  Internationalization  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by claudep):

 * cc: claudep (added)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] r14663 - django/branches/releases/1.2.X/django/dispatch

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 08:58:18 -0600 (Sun, 21 Nov 2010)
New Revision: 14663

Modified:
   django/branches/releases/1.2.X/django/dispatch/dispatcher.py
Log:
[1.2.X] Make django signals more thread-safe. Thanks milosu for the patch!

Backport of r14662 from trunk.

Modified: django/branches/releases/1.2.X/django/dispatch/dispatcher.py
===
--- django/branches/releases/1.2.X/django/dispatch/dispatcher.py
2010-11-21 14:54:23 UTC (rev 14662)
+++ django/branches/releases/1.2.X/django/dispatch/dispatcher.py
2010-11-21 14:58:18 UTC (rev 14663)
@@ -1,4 +1,5 @@
 import weakref
+import threading
 
 from django.dispatch import saferef
 
@@ -30,6 +31,7 @@
 if providing_args is None:
 providing_args = []
 self.providing_args = set(providing_args)
+self.lock = threading.Lock()
 
 def connect(self, receiver, sender=None, weak=True, dispatch_uid=None):
 """
@@ -97,11 +99,15 @@
 if weak:
 receiver = saferef.safeRef(receiver, 
onDelete=self._remove_receiver)
 
-for r_key, _ in self.receivers:
-if r_key == lookup_key:
-break
-else:
-self.receivers.append((lookup_key, receiver))
+try:
+self.lock.acquire()
+for r_key, _ in self.receivers:
+if r_key == lookup_key:
+break
+else:
+self.receivers.append((lookup_key, receiver))
+finally:
+self.lock.release()
 
 def disconnect(self, receiver=None, sender=None, weak=True, 
dispatch_uid=None):
 """
@@ -130,11 +136,15 @@
 else:
 lookup_key = (_make_id(receiver), _make_id(sender))
 
-for index in xrange(len(self.receivers)):
-(r_key, _) = self.receivers[index]
-if r_key == lookup_key:
-del self.receivers[index]
-break
+try:
+self.lock.acquire()
+for index in xrange(len(self.receivers)):
+(r_key, _) = self.receivers[index]
+if r_key == lookup_key:
+del self.receivers[index]
+break
+finally:
+self.lock.release()
 
 def send(self, sender, **named):
 """
@@ -227,11 +237,20 @@
 Remove dead receivers from connections.
 """
 
-to_remove = []
-for key, connected_receiver in self.receivers:
-if connected_receiver == receiver:
-to_remove.append(key)
-for key in to_remove:
-for idx, (r_key, _) in enumerate(self.receivers):
-if r_key == key:
-del self.receivers[idx]
+try:
+self.lock.acquire()
+to_remove = []
+for key, connected_receiver in self.receivers:
+if connected_receiver == receiver:
+to_remove.append(key)
+for key in to_remove:
+last_idx = len(self.receivers) - 1
+# enumerate in reverse order so that indexes are valid even
+# after we delete some items
+for idx, (r_key, _) in enumerate(reversed(self.receivers)):
+if r_key == key:
+del self.receivers[last_idx-idx]
+finally:
+self.lock.release()
+
+

-- 
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] #14748: Missing docummentation for FormPreview methods

2010-11-21 Thread Django
#14748: Missing docummentation for FormPreview methods
---+
 Reporter:  Honza_Kral |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The FormPreview class has a lot of methods that enable user's to modify
 it's default behavior. Most of these methods are not documented.

 http://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-preview
 /#advanced-formpreview-methods

-- 
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] r14665 - in django/branches/releases/1.2.X: django/db/backends tests/regressiontests/db_typecasts

2010-11-21 Thread noreply
Author: ramiro
Date: 2010-11-21 09:19:46 -0600 (Sun, 21 Nov 2010)
New Revision: 14665

Modified:
   django/branches/releases/1.2.X/django/db/backends/util.py
   django/branches/releases/1.2.X/tests/regressiontests/db_typecasts/tests.py
Log:
[1.2.X] Fixed #14453 -- Changed handling of microseconds part in 
typecast_timestamp() DB backend helper function to be more correct. Thanks 
philipn for the report and fix.

Backport of [14664] from trunk

Modified: django/branches/releases/1.2.X/django/db/backends/util.py
===
--- django/branches/releases/1.2.X/django/db/backends/util.py   2010-11-21 
15:08:53 UTC (rev 14664)
+++ django/branches/releases/1.2.X/django/db/backends/util.py   2010-11-21 
15:19:46 UTC (rev 14665)
@@ -81,7 +81,7 @@
 else:
 microseconds = '0'
 return datetime.datetime(int(dates[0]), int(dates[1]), int(dates[2]),
-int(times[0]), int(times[1]), int(seconds), 
int(float('.'+microseconds) * 100))
+int(times[0]), int(times[1]), int(seconds), int((microseconds + 
'00')[:6]))
 
 def typecast_boolean(s):
 if s is None: return None

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/db_typecasts/tests.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/db_typecasts/tests.py  
2010-11-21 15:08:53 UTC (rev 14664)
+++ django/branches/releases/1.2.X/tests/regressiontests/db_typecasts/tests.py  
2010-11-21 15:19:46 UTC (rev 14665)
@@ -35,6 +35,12 @@
 ('2005-08-11 8:50:30.9', datetime.datetime(2005, 8, 11, 8, 50, 30, 
90)),
 ('2005-08-11 8:50:30.312-05', datetime.datetime(2005, 8, 11, 8, 50, 
30, 312000)),
 ('2005-08-11 8:50:30.312+02', datetime.datetime(2005, 8, 11, 8, 50, 
30, 312000)),
+# ticket 14453
+('2010-10-12 15:29:22.063202', datetime.datetime(2010, 10, 12, 15, 29, 
22, 63202)),
+('2010-10-12 15:29:22.063202-03', datetime.datetime(2010, 10, 12, 15, 
29, 22, 63202)),
+('2010-10-12 15:29:22.063202+04', datetime.datetime(2010, 10, 12, 15, 
29, 22, 63202)),
+('2010-10-12 15:29:22.0632021', datetime.datetime(2010, 10, 12, 15, 
29, 22, 63202)),
+('2010-10-12 15:29:22.0632029', datetime.datetime(2010, 10, 12, 15, 
29, 22, 63202)),
 ),
 'typecast_boolean': (
 (None, None),
@@ -53,4 +59,4 @@
 assert got == expected, "In %s: %r doesn't match %r. Got %r 
instead." % (k, inpt, expected, got)
 
 if __name__ == '__main__':
-unittest.main()
\ No newline at end of file
+unittest.main()

-- 
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] r14664 - in django/trunk: django/db/backends tests/regressiontests/db_typecasts

2010-11-21 Thread noreply
Author: ramiro
Date: 2010-11-21 09:08:53 -0600 (Sun, 21 Nov 2010)
New Revision: 14664

Modified:
   django/trunk/django/db/backends/util.py
   django/trunk/tests/regressiontests/db_typecasts/tests.py
Log:
Fixed #14453 -- Changed handling of microseconds part in typecast_timestamp() 
DB backend helper function to be more correct. Thanks philipn for the report 
and fix.

Modified: django/trunk/django/db/backends/util.py
===
--- django/trunk/django/db/backends/util.py 2010-11-21 14:58:18 UTC (rev 
14663)
+++ django/trunk/django/db/backends/util.py 2010-11-21 15:08:53 UTC (rev 
14664)
@@ -92,7 +92,7 @@
 else:
 microseconds = '0'
 return datetime.datetime(int(dates[0]), int(dates[1]), int(dates[2]),
-int(times[0]), int(times[1]), int(seconds), 
int(float('.'+microseconds) * 100))
+int(times[0]), int(times[1]), int(seconds), int((microseconds + 
'00')[:6]))
 
 def typecast_boolean(s):
 if s is None: return None

Modified: django/trunk/tests/regressiontests/db_typecasts/tests.py
===
--- django/trunk/tests/regressiontests/db_typecasts/tests.py2010-11-21 
14:58:18 UTC (rev 14663)
+++ django/trunk/tests/regressiontests/db_typecasts/tests.py2010-11-21 
15:08:53 UTC (rev 14664)
@@ -35,6 +35,12 @@
 ('2005-08-11 8:50:30.9', datetime.datetime(2005, 8, 11, 8, 50, 30, 
90)),
 ('2005-08-11 8:50:30.312-05', datetime.datetime(2005, 8, 11, 8, 50, 
30, 312000)),
 ('2005-08-11 8:50:30.312+02', datetime.datetime(2005, 8, 11, 8, 50, 
30, 312000)),
+# ticket 14453
+('2010-10-12 15:29:22.063202', datetime.datetime(2010, 10, 12, 15, 29, 
22, 63202)),
+('2010-10-12 15:29:22.063202-03', datetime.datetime(2010, 10, 12, 15, 
29, 22, 63202)),
+('2010-10-12 15:29:22.063202+04', datetime.datetime(2010, 10, 12, 15, 
29, 22, 63202)),
+('2010-10-12 15:29:22.0632021', datetime.datetime(2010, 10, 12, 15, 
29, 22, 63202)),
+('2010-10-12 15:29:22.0632029', datetime.datetime(2010, 10, 12, 15, 
29, 22, 63202)),
 ),
 'typecast_boolean': (
 (None, None),
@@ -53,4 +59,4 @@
 assert got == expected, "In %s: %r doesn't match %r. Got %r 
instead." % (k, inpt, expected, got)
 
 if __name__ == '__main__':
-unittest.main()
\ No newline at end of file
+unittest.main()

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

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 08:54:23 -0600 (Sun, 21 Nov 2010)
New Revision: 14662

Modified:
   django/trunk/django/dispatch/dispatcher.py
Log:
Fixed #14533 -- Make django signals more thread-safe. Thanks milosu for the 
patch!

Modified: django/trunk/django/dispatch/dispatcher.py
===
--- django/trunk/django/dispatch/dispatcher.py  2010-11-21 14:08:13 UTC (rev 
14661)
+++ django/trunk/django/dispatch/dispatcher.py  2010-11-21 14:54:23 UTC (rev 
14662)
@@ -1,4 +1,5 @@
 import weakref
+import threading
 
 from django.dispatch import saferef
 
@@ -30,6 +31,7 @@
 if providing_args is None:
 providing_args = []
 self.providing_args = set(providing_args)
+self.lock = threading.Lock()
 
 def connect(self, receiver, sender=None, weak=True, dispatch_uid=None):
 """
@@ -97,11 +99,15 @@
 if weak:
 receiver = saferef.safeRef(receiver, 
onDelete=self._remove_receiver)
 
-for r_key, _ in self.receivers:
-if r_key == lookup_key:
-break
-else:
-self.receivers.append((lookup_key, receiver))
+try:
+self.lock.acquire()
+for r_key, _ in self.receivers:
+if r_key == lookup_key:
+break
+else:
+self.receivers.append((lookup_key, receiver))
+finally:
+self.lock.release()
 
 def disconnect(self, receiver=None, sender=None, weak=True, 
dispatch_uid=None):
 """
@@ -130,11 +136,15 @@
 else:
 lookup_key = (_make_id(receiver), _make_id(sender))
 
-for index in xrange(len(self.receivers)):
-(r_key, _) = self.receivers[index]
-if r_key == lookup_key:
-del self.receivers[index]
-break
+try:
+self.lock.acquire()
+for index in xrange(len(self.receivers)):
+(r_key, _) = self.receivers[index]
+if r_key == lookup_key:
+del self.receivers[index]
+break
+finally:
+self.lock.release()
 
 def send(self, sender, **named):
 """
@@ -227,14 +237,21 @@
 Remove dead receivers from connections.
 """
 
-to_remove = []
-for key, connected_receiver in self.receivers:
-if connected_receiver == receiver:
-to_remove.append(key)
-for key in to_remove:
-for idx, (r_key, _) in enumerate(self.receivers):
-if r_key == key:
-del self.receivers[idx]
+try:
+self.lock.acquire()
+to_remove = []
+for key, connected_receiver in self.receivers:
+if connected_receiver == receiver:
+to_remove.append(key)
+for key in to_remove:
+last_idx = len(self.receivers) - 1
+# enumerate in reverse order so that indexes are valid even
+# after we delete some items
+for idx, (r_key, _) in enumerate(reversed(self.receivers)):
+if r_key == key:
+del self.receivers[last_idx-idx]
+finally:
+self.lock.release()
 
 
 def receiver(signal, **kwargs):

-- 
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] #14453: typecast_timestamp in db.backends.util gives incorrect behavior

2010-11-21 Thread Django
#14453: typecast_timestamp in db.backends.util gives incorrect behavior
---+
  Reporter:  philipn   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * stage:  Unreviewed => Accepted

Comment:

 Great work. Some performance comparison, just in case:
 {{{
 $ cat timings.sh
 #!/bin/sh

 echo "float():"
 python -m timeit -n 100 -c "int(float('.'+'063202') * 100)"

 echo "ljust():"
 python -m timeit -n 100 -c "int('063202'.ljust(6, '0')[:6])"

 echo "+ '00':"
 python -m timeit -n 100 -c "int('063202'+'00'[:6])"
 }}}

 {{{
 $ ./timings.sh
 float():
 100 loops, best of 3: 0.85 usec per loop
 ljust():
 100 loops, best of 3: 0.98 usec per loop
 + '00':
 100 loops, best of 3: 0.94 usec per loop
 }}}

 Will commit a fix implementing philipn's approach.

-- 
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] r14661 - django/branches/releases/1.2.X/django/contrib/localflavor/cz

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 08:08:13 -0600 (Sun, 21 Nov 2010)
New Revision: 14661

Modified:
   django/branches/releases/1.2.X/django/contrib/localflavor/cz/forms.py
Log:
[1.2.X] CZ Localflavor clean() incorrectly called super.__init__. Thanks for 
the report and patch idangazit!

Backport of r14660 from trunk.

Modified: django/branches/releases/1.2.X/django/contrib/localflavor/cz/forms.py
===
--- django/branches/releases/1.2.X/django/contrib/localflavor/cz/forms.py   
2010-11-21 14:06:32 UTC (rev 14660)
+++ django/branches/releases/1.2.X/django/contrib/localflavor/cz/forms.py   
2010-11-21 14:08:13 UTC (rev 14661)
@@ -51,7 +51,7 @@
 }
 
 def clean(self, value, gender=None):
-super(CZBirthNumberField, self).__init__(value)
+super(CZBirthNumberField, self).clean(value)
 
 if value in EMPTY_VALUES:
 return u''
@@ -108,7 +108,7 @@
 }
 
 def clean(self, value):
-super(CZICNumberField, self).__init__(value)
+super(CZICNumberField, self).clean(value)
 
 if value in EMPTY_VALUES:
 return u''

-- 
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] r14660 - django/trunk/django/contrib/localflavor/cz

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 08:06:32 -0600 (Sun, 21 Nov 2010)
New Revision: 14660

Modified:
   django/trunk/django/contrib/localflavor/cz/forms.py
Log:
Fixed #14741 -- CZ Localflavor clean() incorrectly called super.__init__. 
Thanks for the report and patch idangazit!

Modified: django/trunk/django/contrib/localflavor/cz/forms.py
===
--- django/trunk/django/contrib/localflavor/cz/forms.py 2010-11-21 13:47:38 UTC 
(rev 14659)
+++ django/trunk/django/contrib/localflavor/cz/forms.py 2010-11-21 14:06:32 UTC 
(rev 14660)
@@ -51,7 +51,7 @@
 }
 
 def clean(self, value, gender=None):
-super(CZBirthNumberField, self).__init__(value)
+super(CZBirthNumberField, self).clean(value)
 
 if value in EMPTY_VALUES:
 return u''
@@ -108,7 +108,7 @@
 }
 
 def clean(self, value):
-super(CZICNumberField, self).__init__(value)
+super(CZICNumberField, self).clean(value)
 
 if value in EMPTY_VALUES:
 return u''

-- 
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] #11841: Allow subclasses of AdminSite to overwrite all admin templates

2010-11-21 Thread Django
#11841: Allow subclasses of AdminSite to overwrite all admin templates
---+
  Reporter:  pjanderson| Owner:  nobody 
Status:  closed| Milestone: 
 Component:  django.contrib.admin  |   Version:  1.1
Resolution:  invalid   |  Keywords:  AdminSite templates
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by Honza_Kral):

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

Comment:

 Hey, you can override any template, the only downside is that some are on
 AdminSite and others on ModelAdmin. Since this is not a main-stream use
 case I would recommend to create your own ModelAdmin subclass defining all
 the template names and derive your individual ModelAdmin classes from
 that.

-- 
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] r14659 - in django/trunk/django/contrib/formtools: . tests

2010-11-21 Thread noreply
Author: Honza_Kral
Date: 2010-11-21 07:47:38 -0600 (Sun, 21 Nov 2010)
New Revision: 14659

Modified:
   django/trunk/django/contrib/formtools/preview.py
   django/trunk/django/contrib/formtools/tests/__init__.py
Log:
Few improvements to FormPreview, thanks Andy!

This commit adds several new hooks in backwards-compatible way:
 * get_initial to specify initial data based on request
 * get_auto_id to enable different AUTO_ID values
 * get_context for overriding and extending default context contents

Modified: django/trunk/django/contrib/formtools/preview.py
===
--- django/trunk/django/contrib/formtools/preview.py2010-11-21 10:16:02 UTC 
(rev 14658)
+++ django/trunk/django/contrib/formtools/preview.py2010-11-21 13:47:38 UTC 
(rev 14659)
@@ -51,17 +51,17 @@
 
 def preview_get(self, request):
 "Displays the form"
-f = self.form(auto_id=AUTO_ID)
+f = self.form(auto_id=self.get_auto_id(), 
initial=self.get_initial(request))
 return render_to_response(self.form_template,
-{'form': f, 'stage_field': self.unused_name('stage'), 'state': 
self.state},
+self.get_context(request, f),
 context_instance=RequestContext(request))
 
 def preview_post(self, request):
 "Validates the POST data. If valid, displays the preview page. Else, 
redisplays form."
-f = self.form(request.POST, auto_id=AUTO_ID)
-context = {'form': f, 'stage_field': self.unused_name('stage'), 
'state': self.state}
+f = self.form(request.POST, auto_id=self.get_auto_id())
+context = self.get_context(request, f)
 if f.is_valid():
-self.process_preview(request, f, context) 
+self.process_preview(request, f, context)
 context['hash_field'] = self.unused_name('hash')
 context['hash_value'] = self.security_hash(request, f)
 return render_to_response(self.preview_template, context, 
context_instance=RequestContext(request))
@@ -91,7 +91,7 @@
 
 def post_post(self, request):
 "Validates the POST data. If valid, calls done(). Else, redisplays 
form."
-f = self.form(request.POST, auto_id=AUTO_ID)
+f = self.form(request.POST, auto_id=self.get_auto_id())
 if f.is_valid():
 if not 
self._check_security_hash(request.POST.get(self.unused_name('hash'), ''),
  request, f):
@@ -99,11 +99,30 @@
 return self.done(request, f.cleaned_data)
 else:
 return render_to_response(self.form_template,
-{'form': f, 'stage_field': self.unused_name('stage'), 'state': 
self.state},
+self.get_context(request, f),
 context_instance=RequestContext(request))
 
 # METHODS SUBCLASSES MIGHT OVERRIDE IF APPROPRIATE 
 
+def get_auto_id(self):
+"""
+Hook to override the ``auto_id`` kwarg for the form. Needed when
+rendering two form previews in the same template.
+"""
+return AUTO_ID
+
+def get_initial(self, request):
+"""
+Takes a request argument and returns a dictionary to pass to the form's
+``initial`` kwarg when the form is being created from an HTTP get.
+"""
+return {}
+
+def get_context(self, request, form):
+"Context for template rendering."
+return {'form': form, 'stage_field': self.unused_name('stage'), 
'state': self.state}
+
+
 def parse_params(self, *args, **kwargs):
 """
 Given captured args and kwargs from the URLconf, saves something in

Modified: django/trunk/django/contrib/formtools/tests/__init__.py
===
--- django/trunk/django/contrib/formtools/tests/__init__.py 2010-11-21 
10:16:02 UTC (rev 14658)
+++ django/trunk/django/contrib/formtools/tests/__init__.py 2010-11-21 
13:47:38 UTC (rev 14659)
@@ -11,7 +11,14 @@
 
 
 class TestFormPreview(preview.FormPreview):
+def get_context(self, request, form):
+context = super(TestFormPreview, self).get_context(request, form)
+context.update({'custom_context': True})
+return context
 
+def get_initial(self, request):
+return {'field1': 'Works!'}
+
 def done(self, request, cleaned_data):
 return http.HttpResponse(success_string)
 
@@ -59,6 +66,8 @@
 response = self.client.get('/test1/')
 stage = self.input % 1
 self.assertContains(response, stage, 1)
+self.assertEquals(response.context['custom_context'], True)
+self.assertEquals(response.context['form'].initial, {'field1': 
'Works!'})
 
 def test_form_preview(self):
 """

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

Re: [Django] #10427: Bound field needs an easy way to get form value

2010-11-21 Thread Django
#10427: Bound field needs an easy way to get form value
---+
  Reporter:  toxik | Owner:  SmileyChris 
Status:  new   | Milestone:  1.3 
 Component:  Forms |   Version:  SVN 
Resolution:|  Keywords:  form field value
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by SmileyChris):

  * owner:  nobody => SmileyChris
  * status:  reopened => new

Comment:

 I'm looking to commit at least an abstraction of the values generation in
 the ``BoundField.as_widget`` method.

 Here's my branch comparison:
 https://github.com/SmileyChris/django/compare/master...10427-BoundField.value

-- 
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] r14658 - in django/branches/releases/1.2.X: django/forms tests/regressiontests/forms/tests

2010-11-21 Thread noreply
Author: SmileyChris
Date: 2010-11-21 04:16:02 -0600 (Sun, 21 Nov 2010)
New Revision: 14658

Modified:
   django/branches/releases/1.2.X/django/forms/fields.py
   django/branches/releases/1.2.X/tests/regressiontests/forms/tests/fields.py
Log:
Fixes #13804 -- URLField validation failure for a url containing '://' on the 
path and no scheme. Backport of r14657

Modified: django/branches/releases/1.2.X/django/forms/fields.py
===
--- django/branches/releases/1.2.X/django/forms/fields.py   2010-11-21 
10:08:28 UTC (rev 14657)
+++ django/branches/releases/1.2.X/django/forms/fields.py   2010-11-21 
10:16:02 UTC (rev 14658)
@@ -546,14 +546,23 @@
 
 def to_python(self, value):
 if value:
-if '://' not in value:
+url_fields = list(urlparse.urlsplit(value))
+if not url_fields[0]:
 # If no URL scheme given, assume http://
-value = u'http://%s' % value
-url_fields = list(urlparse.urlsplit(value))
+url_fields[0] = 'http'
+if not url_fields[1]:
+# Assume that if no domain is provided, that the path segment
+# contains the domain. 
+url_fields[1] = url_fields[2]
+url_fields[2] = ''
+# Rebuild the url_fields list, since the domain segment may now
+# contain the path too.
+value = urlparse.urlunsplit(url_fields)
+url_fields = list(urlparse.urlsplit(value))
 if not url_fields[2]:
 # the path portion may need to be added before query params
 url_fields[2] = '/'
-value = urlparse.urlunsplit(url_fields)
+value = urlparse.urlunsplit(url_fields)
 return super(URLField, self).to_python(value)
 
 class BooleanField(Field):

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/forms/tests/fields.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/forms/tests/fields.py  
2010-11-21 10:08:28 UTC (rev 14657)
+++ django/branches/releases/1.2.X/tests/regressiontests/forms/tests/fields.py  
2010-11-21 10:16:02 UTC (rev 14658)
@@ -492,6 +492,7 @@
 self.assertRaisesErrorWithMessage(ValidationError, "[u'Enter a valid 
URL.']", f.clean, 'http://inv-.-alid.com')
 self.assertEqual(u'http://valid-hyphens.com/', 
f.clean('http://valid-hyphens.com'))
 
self.assertEqual(u'http://some.idn.xyz\xe4\xf6\xfc\xdfabc.domain.com:123/blah', 
f.clean('http://some.idn.xyzäöüßabc.domain.com:123/blah'))
+
self.assertEqual(u'http://www.example.com/s/http://code.djangoproject.com/ticket/13804',
 f.clean('www.example.com/s/http://code.djangoproject.com/ticket/13804'))
 
 def test_url_regex_ticket11198(self):
 f = URLField()

-- 
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] r14657 - in django/trunk: django/forms tests/regressiontests/forms/tests

2010-11-21 Thread noreply
Author: SmileyChris
Date: 2010-11-21 04:08:28 -0600 (Sun, 21 Nov 2010)
New Revision: 14657

Modified:
   django/trunk/django/forms/fields.py
   django/trunk/tests/regressiontests/forms/tests/fields.py
Log:
Fixes #13804 -- URLField validation failure for a url containing '://' on the 
path and no scheme

Modified: django/trunk/django/forms/fields.py
===
--- django/trunk/django/forms/fields.py 2010-11-21 08:03:58 UTC (rev 14656)
+++ django/trunk/django/forms/fields.py 2010-11-21 10:08:28 UTC (rev 14657)
@@ -581,14 +581,23 @@
 
 def to_python(self, value):
 if value:
-if '://' not in value:
+url_fields = list(urlparse.urlsplit(value))
+if not url_fields[0]:
 # If no URL scheme given, assume http://
-value = u'http://%s' % value
-url_fields = list(urlparse.urlsplit(value))
+url_fields[0] = 'http'
+if not url_fields[1]:
+# Assume that if no domain is provided, that the path segment
+# contains the domain. 
+url_fields[1] = url_fields[2]
+url_fields[2] = ''
+# Rebuild the url_fields list, since the domain segment may now
+# contain the path too.
+value = urlparse.urlunsplit(url_fields)
+url_fields = list(urlparse.urlsplit(value))
 if not url_fields[2]:
 # the path portion may need to be added before query params
 url_fields[2] = '/'
-value = urlparse.urlunsplit(url_fields)
+value = urlparse.urlunsplit(url_fields)
 return super(URLField, self).to_python(value)
 
 class BooleanField(Field):

Modified: django/trunk/tests/regressiontests/forms/tests/fields.py
===
--- django/trunk/tests/regressiontests/forms/tests/fields.py2010-11-21 
08:03:58 UTC (rev 14656)
+++ django/trunk/tests/regressiontests/forms/tests/fields.py2010-11-21 
10:08:28 UTC (rev 14657)
@@ -495,6 +495,7 @@
 self.assertRaisesErrorWithMessage(ValidationError, "[u'Enter a valid 
URL.']", f.clean, 'http://inv-.-alid.com')
 self.assertEqual(u'http://valid-hyphens.com/', 
f.clean('http://valid-hyphens.com'))
 
self.assertEqual(u'http://some.idn.xyz\xe4\xf6\xfc\xdfabc.domain.com:123/blah', 
f.clean('http://some.idn.xyzäöüßabc.domain.com:123/blah'))
+
self.assertEqual(u'http://www.example.com/s/http://code.djangoproject.com/ticket/13804',
 f.clean('www.example.com/s/http://code.djangoproject.com/ticket/13804'))
 
 def test_url_regex_ticket11198(self):
 f = URLField()

-- 
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] #14499: Some localflavor fields don't handle EMPTY_VALUES correctly

2010-11-21 Thread Django
#14499: Some localflavor fields don't handle EMPTY_VALUES correctly
-+--
  Reporter:  idangazit   | Owner:  idangazit
Status:  new | Milestone:   
 Component:  django.contrib.localflavor  |   Version:  1.2  
Resolution:  |  Keywords:   
 Stage:  Unreviewed  | Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by idangazit):

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

Comment:

 The field in question, ATSocialSecurityNumberField, simply didn't follow
 the accepted pattern (call super, then check EMPTY_VALUES). 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] #13150: Replace make_safe(media) with media in ModelAdmin context dictionary

2010-11-21 Thread Django
#13150: Replace make_safe(media) with media in ModelAdmin context dictionary
---+
  Reporter:  lsbardel  | Owner:  lsbardel
Status:  assigned  | Milestone:  
 Component:  Forms |   Version:  SVN 
Resolution:|  Keywords:  media   
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  1   
Needs_better_patch:  0 |  
---+
Changes (by SmileyChris):

  * needs_better_patch:  1 => 0
  * needs_tests:  0 => 1

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

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



[Django] #14747: parse error on HTTP_IF_MODIFIED_SINCE header

2010-11-21 Thread Django
#14747: parse error on HTTP_IF_MODIFIED_SINCE header
+---
 Reporter:  shaohua |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Some mobile browsers send localized time in 'HTTP_IF_MODIFIED_SINCE' like:
 '???, 21 ?? 2010 05:55:07 GMT', which can not be correctly parsed and
 cause exceptions:

  File "/usr/local/lib/python2.6/dist-
 packages/django/core/handlers/base.py", line 100, in get_response
response = callback(request, *callback_args, **callback_kwargs)

  File "/usr/local/lib/python2.6/dist-packages/django/views/static.py",
 line 61, in serve
statobj[stat.ST_MTIME], statobj[stat.ST_SIZE]):

  File "/usr/local/lib/python2.6/dist-packages/django/views/static.py",
 line 129, in was_modified_since
header_mtime = mktime_tz(parsedate_tz(matches.group(1)))

  File "/usr/lib/python2.6/email/_parseaddr.py", line 142, in mktime_tz
if data[9] is None:

 TypeError: 'NoneType' object is unsubscriptable

-- 
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] #13733: New Zealand localflavor

2010-11-21 Thread Django
#13733: New Zealand localflavor
-+--
  Reporter:  schinckel   | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.localflavor  |   Version:
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Changes (by SmileyChris):

  * needs_better_patch:  0 => 1
  * version:  1.2 =>

Comment:

 NZ's [http://en.wikipedia.org/wiki/Regions_of_New_Zealand#List_of_regions
 regions] would be more of an appropriate regional 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.



Re: [Django] #6663: UUID as Primary Key (Re. 4682)

2010-11-21 Thread Django
#6663: UUID as Primary Key (Re. 4682)
+---
  Reporter:  Jonathan Harker   | Owner:  
nobody   
Status:  reopened   | Milestone:
   
 Component:  Database layer (models, ORM)   |   Version:  1.2   
   
Resolution: |  Keywords:  
primary key, uuid
 Stage:  Unreviewed | Has_patch:  0 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by quinode):

  * status:  closed => reopened
  * version:  SVN => 1.2
  * resolution:  wontfix =>

Comment:

 Reopening this ticket, because I'm facing issues (#14724, worst being
 #12235) because I *really* need UUID primary keys (and worst heretic of
 all requirements, UUID primary key on the Django User Model!)
 My first big django project is based on multi-sites data syncing (implying
 users and custom models)

 I really don't get the "This doesn't have to be included in django"
 argument.
 It's 2010, UUID is a real datatype now, like datetime. It's used for hard-
 to-guess ID in URL, multi-db syncing issues like mine, etc
 The fact that it made its way to postgresql as a possible column type is a
 sign, no ?

 I'm new to Django, so perhaps making a mistake here, but seems to me that,
 applying the DRY principle to the whole django project and given all the
 UUIDField implementations found everywhere, all of them having/will have
 eventually the same problems to face when integrating to django, an
 official UUIDField for django is needed.
 I imagine that this implies lot of cleaning for int-pk specific code
 everywhere
 I picked the django-extensions UUIDField because it seemed it had the
 better support, but there does not seem to be one implementation without
 issue right 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] #6218: Require trailing slash always on MEDIA_URL

2010-11-21 Thread Django
#6218: Require trailing slash always on MEDIA_URL
+---
  Reporter:  Michael Toomim   | 
Owner:  jezdez   
Status:  new| 
Milestone:   
 Component:  Core framework |   
Version:  SVN  
Resolution: |  
Keywords:  easy-pickings
 Stage:  Accepted   | 
Has_patch:  1
Needs_docs:  0  |   
Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * owner:  cmheisel => jezdez
  * status:  assigned => new

Comment:

 Throwing this jezdez's way for a bit of attention, since he's been knee-
 deep in media-file related stuff at the moment.

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

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



Re: [Django] #12235: MultiValueDictKeyError when editing Inline objects

2010-11-21 Thread Django
#12235: MultiValueDictKeyError when editing Inline objects
---+
  Reporter:  br...@playfirst.com   | Owner:  nobody
Status:  reopened  | 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 quinode):

  * version:  1.1 => 1.2

Comment:

 Having the very same problem using the django-extensions UUIDField()

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

2010-11-21 Thread noreply
Author: SmileyChris
Date: 2010-11-21 02:03:58 -0600 (Sun, 21 Nov 2010)
New Revision: 14656

Modified:
   django/trunk/django/template/defaulttags.py
Log:
Fixed #4552 -- minor tidy up of the {% for %} tag's comma splitting

Modified: django/trunk/django/template/defaulttags.py
===
--- django/trunk/django/template/defaulttags.py 2010-11-21 02:28:25 UTC (rev 
14655)
+++ django/trunk/django/template/defaulttags.py 2010-11-21 08:03:58 UTC (rev 
14656)
@@ -725,7 +725,7 @@
 raise TemplateSyntaxError("'for' statements should use the format"
   " 'for x in y': %s" % token.contents)
 
-loopvars = re.sub(r' *, *', ',', ' '.join(bits[1:in_index])).split(',')
+loopvars = re.split(r' *, *', ' '.join(bits[1:in_index]))
 for var in loopvars:
 if not var or ' ' in var:
 raise TemplateSyntaxError("'for' tag received an invalid argument:"

-- 
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] #8997: Misleading error message when calling get_absolute_url

2010-11-21 Thread Django
#8997: Misleading error message when calling get_absolute_url
-+--
  Reporter:  Rob   | Owner:  
joshlory
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 joshlory):

  * owner:  nobody => joshlory
  * has_patch:  0 => 1

Comment:

 Added a patch with tests -- not sure if I put the tests in the correct
 location.  By not catching the {{{AttributeError}}} in shortcut() the
 error is allowed to propagate normally.

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