[Django] #14321: IPAddressField inserted as empty string although null=True

[Django]

#14321: IPAddressField inserted as empty string although null=True
--+-
 Reporter:  ri...@mail.ru |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I have these fields in a model:
 {{{
 #!python
 ipaddr1 = models.IPAddressField()
 ipaddr2 = models.IPAddressField(blank=True, null=True)
 }}}

 When I "wrap" this model in a ModelForm, fill the form, and call
 form.save(), empty ipaddr2 gets inserted as an empty string, causing
 database
 errors for Postgres' inet type.

 I believe Django shouldn't be disregarding null=true for an IPAddressField
 when dealing with Postgres.

-- 
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] #14320: MySQL documentation needs to note lack of support for timezone info...

[Django]

#14320: MySQL documentation needs to note lack of support for timezone info...
--+-
 Reporter:  RantyDave |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Documentation | Version:  1.2   
 Keywords:  MySQL datetime DateTimeField  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The current (5.1.50) version of MySQL has no support for timezone
 information in date fields. Python does and an attempt to write a
 models.DateTimeField that contains timezone information fails and throws a
 ValueError('MySQL backend does not support timezone-aware datetimes.',).

 All I'm suggesting is that the documentation at
 http://docs.djangoproject.com/en/1.2/ref/databases/#notes-on-specific-
 fields makes note of this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14319: Add signals test_setup and test_teardown to Django test suite runner Options

[Django]

#14319: Add signals test_setup and test_teardown to Django test suite runner
Options
---+
 Reporter:  jsdalton   |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Testing framework  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 I would like to submit a proposal (with patch) for two new signals to add
 to the testing framework: a test_setup signal, to be emitted during global
 test setup, and a test_teardown signal, to be emitted during global test
 teardown.

 Presently, there is no way to modify or add to the global setup or
 teardown behavior that runs with the built-in test suite runner. This
 patch provides a hook that applications can use to do that. Each signal is
 emitted once during a test run.

 The proposal was discussed briefly on the Django developer's list here:
 http://groups.google.com/group/django-
 developers/browse_thread/thread/f45c7302634ed82d

 Here are a few notes about the proposed changes to source code:

   * There are really only a handful of lines of code required to make this
 change.
   * The most significant change is that the ordering of actions in the
 `run_tests()` method of `DjangoTestSuiteRunner` has been adjusted. In
 order for applications to be able to setup connect() calls to the signals,
 the application code itself has to be imported. This happens for the first
 time in `build_suite()`, so I swapped the order of the call to
 `build_suite()` and the call to `setup_test_environment()`. This appears
 to have no impact, but it's conceivable that some issues could arise if
 e.g. an application developer did something during import that they
 expected to be disabled first during testing. At present, the main thing
 Django does in the `setup_test_enivronment()` call is to disable the email
 backend, so unless a developer is sending emails in the body of a module
 or something it shouldn't present a problem.
   * The second most significant change is that the `django.test.utils`
 functions `setup_test_environment()` and `tear_down_environment()` calls
 are executed by connecting to the signal rather than being called directly
 from the methods of the test runner. This serves as a way to test that the
 signals are being fired, as Django tests will fail if those two functions
 do not execute. (Thanks to Russell Keith-Magee for this suggestion).
   * I have included documentation for these two new signals on the Django
 signals documentation page.

 Here are a few arguments in favor of this proposal that I posted to the
 Django developers discussions:

   * Requiring a custom test runner to implement this behavior makes it
 (nearly) impossible for reusable applications to modify global setup  and
 teardown behavior, since it would become the responsibility of the
 project itself to specify the custom test runner.
   * The current setup gives the Django core "privileged" access to
 disable certain features during testing, it would seem that  application
 should be given the capability as well.
   * Signals are non obtrusive...if they are not used they don't really
 harm anything.
   * None of the proposed changes would impact production code, since  they
 are all restricted to the test suite. In fact the patch is really  only
 about a few lines of additional code.

 There maybe other arguments in favor of or against as well, please feel
 free to share them if so.

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

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

Re: [Django] #8960: "View on site" does not work if contrib.sites is not installed

[Django]

#8960: "View on site" does not work if contrib.sites is not installed
---+
  Reporter:  bmihelac  | Owner:  adrian
Status:  assigned  | Milestone:  1.3   
 Component:  Contrib apps  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by CarlFK):

 Until the code is fixed, how about fixing the docs:

 
http://docs.djangoproject.com/en/dev/ref/models/instances/#django.db.models.Model.get_absolute_url
 should say "You will need the sites framework installed."

 http://code.djangoproject.com/ticket/2319 patched the sites docs, but I
 think that's an odd place for that bit of info. If I discover
 get_absolute_url and "View on site", I have no way of knowing that I need
 to now go read the site docs.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14223: Inconsistent exception raising on DB integrity errors

[Django]

#14223: Inconsistent exception raising on DB integrity errors
---+
  Reporter:  ramiro| Owner:  ramiro 

Status:  assigned  | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  
integrityerror backends orm
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Old description:

> It seems we aren't capturing the `.IntegrityError`
> exceptions raised when `connection.commit() is executed` in the same way
> we do in `execute()`.
>
> Found this while creating tests to verify FK constraint in sqlite
> (#14304). My `assertRaises(django.db.[utils.]IntegrityError, ...)`
> weren't being triggered and printing the exception type shows ` 'pysqlite2.dbapi2.IntegrityError'>`. Same thing happens now with postgres
> (see below).
>
> The `DatabaseError` and `IntegrityError` unification was introduced in
> r12352, if this is confirmed as an issue it wouldn't be a regression in
> 1.2, but a 1.2 feature introduced in an incomplete fashion.
>
> The two files pasted at the end form a small test case. When run under
> postgres you see:
>
> {{{
> ==
> ERROR: Try to create a model instance that violates a FK constraint.
> Should fail
> --
> Traceback (most recent call last):
>   File
> "/home/r/django/sqlite_fk2/tests/regressiontests/fk_constraints/tests.py",
> line 22, in test_integrity_checks_on_creation
> a.save()
>   File "/home/r/django/sqlite_fk2/django/db/models/base.py", line 434, in
> save
> self.save_base(using=using, force_insert=force_insert,
> force_update=force_update)
>   File "/home/r/django/sqlite_fk2/django/db/models/base.py", line 534, in
> save_base
> transaction.commit_unless_managed(using=using)
>   File "/home/r/django/sqlite_fk2/django/db/transaction.py", line 175, in
> commit_unless_managed
> connection._commit()
>   File "/home/r/django/sqlite_fk2/django/db/backends/__init__.py", line
> 32, in _commit
> return self.connection.commit()
> IntegrityError: insert or update on table "fk_constraints_article"
> violates foreign key constraint "fk_constraints_article_reporter_id_fkey"
> DETAIL:  Key (reporter_id)=(30) is not present in table
> "fk_constraints_reporter".
>
> 
> }}}
>
> {{{
> #!python
> # models.py
> from django.db import models
>
> class Reporter(models.Model):
> first_name = models.CharField(max_length=30)
> last_name = models.CharField(max_length=30)
> email = models.EmailField()
>
> def __unicode__(self):
> return u"%s %s" % (self.first_name, self.last_name)
>
> class Article(models.Model):
> headline = models.CharField(max_length=100)
> pub_date = models.DateField()
> reporter = models.ForeignKey(Reporter)
>
> def __unicode__(self):
> return self.headline
>
> class Meta:
> ordering = ('headline',)
> }}}
>
> {{{
> #!python
> # tests.py
> from datetime import datetime
>
> from django.db import utils
> from django.test import TransactionTestCase
>
> from models import Reporter, Article
>
> import sys
>
> class FkConstraintsTest(TransactionTestCase):
>
> def setUp(self):
> # Create a Reporter.
> self.r = Reporter.objects.create(first_name='John',
> last_name='Smith', email='j...@example.com')
> #self.r2 = Reporterobjects.create(first_name='Paul',
> last_name='Jones', email='p...@example.com')
>
> def test_integrity_checks_on_creation(self):
> """Try to create a model instance that violates a FK constraint.
> Should fail"""
> a = Article(headline="This is a test", pub_date=datetime(2005, 7,
> 27), reporter_id=30)
> #self.assertRaises(utils.IntegrityError, a.save)
> try:
> a.save()
> except Exception, e:
> print >>sys.stderr, type(e)
> raise
>
> def test_integrity_checks_on_update(self):
> """Try to update a model instance introducing a FK constraint
> violation. Should fail"""
> # Create an Article.
> Article.objects.create(headline="Test article",
> pub_date=datetime(2010, 9, 4), reporter=self.r)
> # Retrive it from the DB
> a = Article.objects.get(headline="Test article")
> a.reporter_id = 30
> #self.assertRaises(utils.IntegrityError, a.save)
> try:
> a.save()
> except Exception, e:
> print >

[Django] #14318: Add GEOSGeometry.valid_reason

[Django]

#14318: Add GEOSGeometry.valid_reason
---+
 Reporter:  rcoup  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  GIS| Version:  SVN   
 Keywords:  geos   |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 When you're messing with geometries it's handy to find out the reason why
 they're invalid. GEOS >= v3.1 supports `GEOSisValidReason()` for that
 purpose - returning a string about why a geometry is invalid. The attached
 patch adds support to the GeoDjango GEOS bindings as
 `GEOSGeometry.valid_reason`.

 Tests, docs, and error-chucking for GEOS http://code.djangoproject.com/ticket/14318>
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] #10870: Aggregates with joins ignore extra filters provided by setup_joins

[Django]

#10870: Aggregates with joins ignore extra filters provided by setup_joins
--+-
  Reporter:  fas  | Owner:  fas 

Status:  new  | Milestone:  1.3 

 Component:  ORM aggregation  |   Version:  SVN 

Resolution:   |  Keywords:  orm, aggregation, join, 
contenttypes, filter
 Stage:  Accepted | Has_patch:  0   

Needs_docs:  0|   Needs_tests:  0   

Needs_better_patch:  0|  
--+-
Comment (by Alex):

 So I've been thinking about this, and I'm wondering whether it perhaps
 makes sense to commit this patch, even with it excluding legitimate
 results.  My reasoning: the current status is that aggregate() and
 annotate() both return bogus data, with the patch aggregate() returns
 correct data, and annotate() returns data that is valid but is *missing*
 results for items with no related data.  This strikes me as a clear
 improvement, and even though the patch is obviously not completely
 correct, it is a first step to the more complicated completely correct
 implementation.

-- 
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] #14314: Import error on installation of Django 1.2.3

[Django]

#14314: Import error on installation of Django 1.2.3
+---
  Reporter:  gefisher   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  worksforme |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ramiro):

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

Comment:

 Most surely that's the reason of the failures you are seeing. WinZip 6.3
 is twelve years old (!).

 Quoting the Django [http://docs.djangoproject.com/en/1.2/topics/install
 /#installing-an-official-release installation docs]: ''Untar the
 downloaded file (e.g. tar xzvf Django-NNN.tar.gz, where NNN is the version
 number of the latest release). If you're using Windows, you can download
 the command-line tool bsdtar to do this, or you can use a GUI-based tool
 such as 7-zip.''

 Please ask further user support questions like this in the appropriate
 channels as suggested in a previous comment.

-- 
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] #14314: Import error on installation of Django 1.2.3

[Django]

#14314: Import error on installation of Django 1.2.3
+---
  Reporter:  gefisher   | 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 gefisher):

 Replying to [comment:3 ramiro]:
 >
 >>> Some things to check: Could be that the tarball you downloaded has
 been corrupt in any way?. Can you verify its SHA1 or MD5 checksum?.

 Probably not.  I just grabbed the file without bothering to do any
 checksum stuff.

 >>>How are you unpacking it?. What tool are you using for that?.
 I'm using an older version of winzip...probably around version 6.3 or some
 such.

 >>>Do the 0-byte sized `django\utils\__init__.py` file exist?.
 >>>Do the `django\utils\version.py` file exist?. They certainly exist in
 the official tarball.

 I think we're onto something here.  When I use winzip to look at the
 tarball I see bunches of __init.py__ files...and a lot of them are of size
 0.  However when I look in Django-1.2.3\django\utils there is no init.py
 file...perhaps because winzip didn't load it 'cause it's zero length.  In
 the tarball it's listed to go in there but it's size is zero.  Do you have
 an init.py file in there?  I'd try this now but I'm not at home where my
 development system is.  Thanks.

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

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

Re: [Django] #14314: Import error on installation of Django 1.2.3

[Django]

#14314: Import error on installation of Django 1.2.3
+---
  Reporter:  gefisher   | 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 ramiro):

 With the steps I took to reproduce this we've discovered that the official
 tarball isn't the problem and so, this bug tracker isn't the right channel
 and the django-users mailing or the #django IRC channel list would be a
 better place for this.

 Some things to check: Could be that the tarball you downloaded has been
 corrupt in any way?. Can you verify its SHA1 or MD5 checksum?. How are you
 unpacking it?. What tool are you using for that?. Do the 0-byte sized
 `django\utils\__init__.py` file exist?. Do the `django\utils\version.py`
 file exist?. They certainly exist in the official tarball.

-- 
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] #14314: Import error on installation of Django 1.2.3

[Django]

#14314: Import error on installation of Django 1.2.3
+---
  Reporter:  gefisher   | 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  |  
+---
Changes (by gefisher):

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

Comment:

 I've never installed Django before...this is a first for me.

 No ideas as to why a Python import statement would fail in your code ??

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13914: Add natural keys to contrib.auth.User and Group models

[Django]

#13914: Add natural keys to contrib.auth.User and Group models
-+--
  Reporter:  jbochi  | Owner:  nobody   
   
Status:  new | Milestone:  1.3  
   
 Component:  Authentication  |   Version:  SVN  
   
Resolution:  |  Keywords:  Contrib, Auth, User, 
Group, natural keys
 Stage:  Accepted| Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by canassa):

 * cc: cesar.cana...@gmail.com (added)

Comment:

 I am using his patch right now, so I can confirm that it works.

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

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

Re: [Django] #9806: GeometryField crashes contrib.gis.admin

[Django]

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

 Patch works for me against Django 1.2.3, at least against points. I
 haven't tried with any MULTI*, dont' have any of those handy.

-- 
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] #14317: numberformat.format produces wrong results

[Django]

#14317: numberformat.format produces wrong results
-+--
 Reporter:  akaariai |   Owner:  akaariai  
   Status:  new  |   Milestone:
Component:  Internationalization | Version:  1.2   
 Keywords:  Localization, number formatting  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 The problem:
 {{{
 >>> from django.utils.numberformat import format
 >>> print format(0.1, ',', 2)
 1e-10,2
 }}}

 It can be fixed with using '%.2f' % number (the format string can be
 constructed dynamically), and then replacing the decimal separator and
 doing the grouping if needed. As a bonus, it is faster that way.

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

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

Re: [Django] #14316: GeoModelAdmin forms have error on GeometryField

[Django]

#14316: GeoModelAdmin forms have error on GeometryField
-+--
  Reporter:  slinkp  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  GIS |   Version:  1.2   
Resolution:  duplicate   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by slinkp):

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

Comment:

 doh. just found #9806.
 The most recent patch
 (http://code.djangoproject.com/attachment/ticket/9806/9806.3.diff) works
 for me against Django 1.2.3.

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

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

[Django] #14316: GeoModelAdmin forms have error on GeometryField

[Django]

#14316: GeoModelAdmin forms have error on GeometryField
+---
 Reporter:  slinkp  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  GIS | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Given a model like this:

 {{{
 from django.contrib.gis.db import models

 class Foo(models.Model):
 location = models.GeometryField(blank=True, null=True)
 }}}

 And an Admin class like this:
 {{{
 from django.contrib.gis import admin

 class OSMModelAdmin(admin.GeoModelAdmin):
 pass

 admin.site.register(Foo, FooAdmin)

 }}}

 ... I get this error in firebug when looking at the admin view for a Foo
 instance:

 {{{
 controls[i] is undefined
 [Break on this error]
 this.controls=this.controls.concat(con...].panel_div.title=controls[i].title;}
 }}}

 It looks to me like this happens because of the line
 `geodjango_location.controls = [nav, draw_ctl, mod];`
 where draw_ctl is undefined unless either .is_point, .is_linestring, or
 .is_polygon is true;
 and if the field is a generic GeometryField, i.e. able to save any kind of
 geometry, then none of those is true.
 So draw_ctl is undefined and the following call to addControls() fails
 because of that.

 I'm not sure what *should* be done in the UI in this case, but throwing an
 error isn't great.

 Well, maybe the UI should allow the user to choose whether to add a point,
 linestring, or collection, but that'd take some work.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14315: memcached doesn't support negative deltas for incr() and decr()

[Django]

#14315: memcached doesn't support negative deltas for incr() and decr()
---+
  Reporter:  manfre| Owner:  manfre
Status:  new   | Milestone:  1.3   
 Component:  Cache system  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by manfre):

 The smart_str calls were added to make the incr() and decr() functions
 consistent with the rest of the cache class, which enforces that keys are
 utf-8 strings.

-- 
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] #14315: memcached doesn't support negative deltas for incr() and decr()

[Django]

#14315: memcached doesn't support negative deltas for incr() and decr()
---+
  Reporter:  manfre| Owner:  manfre
Status:  new   | Milestone:  1.3   
 Component:  Cache system  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * stage:  Ready for checkin => Accepted

Comment:

 Please don't mark your own tickets as RFC.  In this case I'm not sure
 what's with the change to add {{{ smart_str }}} calls, it's certainly
 untested.

-- 
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] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+--
  Reporter:  pixelcort   | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.admin|   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Changes (by glic3rinu):

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14315: memcached doesn't support negative deltas for incr() and decr()

[Django]

#14315: memcached doesn't support negative deltas for incr() and decr()
+---
  Reporter:  manfre | Owner:  manfre
Status:  new| Milestone:  1.3   
 Component:  Cache system   |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by manfre):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * milestone:  => 1.3
  * owner:  nobody => manfre
  * needs_docs:  => 0
  * stage:  Unreviewed => Ready for checkin

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

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

Re: [Django] #14314: Import error on installation of Django 1.2.3

[Django]

#14314: Import error on installation of Django 1.2.3
+---
  Reporter:  gefisher   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  worksforme |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ramiro):

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

Comment:

 Tried this with:

  * Windows XP 32 bits
  * Python 2.5.2
  * Django 1.2.3

 and coudn't reproduce the issue.

 Make sure you don't have any [incomplete] older version of Django
 installed.

-- 
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] #14315: memcached doesn't support negative deltas for incr() and decr()

[Django]

#14315: memcached doesn't support negative deltas for incr() and decr()
--+-
 Reporter:  manfre|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Cache system  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 cache.incr() and cache.decr() fail for memcached when delta < 0.

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

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

Re: [Django] #14299: Add additional cache.*_many functions

[Django]

#14299: Add additional cache.*_many functions
---+
  Reporter:  manfre| Owner:  manfre 
 
Status:  closed| Milestone:  1.3
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:  wontfix   |  Keywords:  cache, add_many, 
offset_many
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by manfre):

 For clarification, I'm assuming you mean the Django API loosely mimics the
 python-memcached client library, which exposes delete_multi and set_multi
 to reduce connection latency, and not the memcached protocol commands? Is
 this design restriction documented anywhere? Are there any other unwritten
 or hidden decisions along these lines regarding the cache framework?

-- 
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] #8217: Alphabetical sorted FilePathField

[Django]

#8217: Alphabetical sorted FilePathField
---+
  Reporter:  bernd | Owner:  nobody
Status:  new   | Milestone:
 Component:  Forms |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by paparent):

 Will this issue be fixed ?

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

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

Re: [Django] #14299: Add additional cache.*_many functions

[Django]

#14299: Add additional cache.*_many functions
---+
  Reporter:  manfre| Owner:  manfre 
 
Status:  closed| Milestone:  1.3
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:  wontfix   |  Keywords:  cache, add_many, 
offset_many
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 Django's cache API deliberately mimics memcached's API. Specifically, it
 doesn't implement any operations that aren't in memcached's API. Since
 these new _many operations aren't natively supported by memcached, they're
 not a good fit for Django's cache API.

 If you're attached to 'em you can always write a custom cache backend and
 use that instead.

 The incr/decr fixes should be filed a separate ticket; those are indeed
 bugs and should be fixed.

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

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

[Django] #14314: Import error on installation of Django 1.2.3

[Django]

#14314: Import error on installation of Django 1.2.3
---+
 Reporter:  gefisher   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Hi,
 I have Windows 2000 pro. and Python 2.5.2 which I've been working with for
 over a year.
 Today I unzipped the tar ball into Program Files\DJANGO\Django-1.2.3,
 started up a DOS
 window and issued the command "setup.py install".  I immediately got the
 error:

  Import error: no module named utils.version.

 This came from the file Django-1.2.3\django\__init.py__ where it was
 trying to execute
 the code:

  from django.utils.version import get_svn_revision.

 I tried a couple of variations of the "from" relative path variable such
 as:

  from utils.version import ...
  from .django.utils.version import ...
  from .utils.version import ...

 to no avail.  Any ideas ??

 thanks in advance,
 Gary -

-- 
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] #9682: icontains can be case-sensitive on MySQL

[Django]

#9682: icontains can be case-sensitive on MySQL
-+--
  Reporter:  to.roma.from.dj...@qwertty.com  | Owner:  nobody
Status:  new | Milestone:
 Component:  Database layer (models, ORM)|   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Someday/Maybe   | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by jakub):

 Specifying COLLATE in comparisons and ORDER BY clause is a very common
 MySQL pattern when dealing with languages with accented characters. I'd
 love see this in Django.

-- 
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] #14313: wrong display of field title in admin

[Django]

#14313: wrong display of field title in admin
---+
  Reporter:  feuervogel| Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

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

Comment:

 Could you reduce your model and correspoding !ModelAdmin to the minimal
 expression needed to reproduce the bug and paste it here please?.

-- 
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] #14290: Rendering is very inefficient when USE_L10N. Caching format values gives 2-7 times improvement

[Django]

#14290: Rendering is very inefficient when USE_L10N. Caching format values gives
2-7 times improvement
---+
  Reporter:  teemu | Owner:  jezdez 
 
Status:  assigned  | Milestone:  1.3
 
 Component:  Internationalization  |   Version:  SVN
 
Resolution:|  Keywords:  localization, 
rendering,
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Comment (by akaariai):

 Was this with just the latest patch to this ticket, or also with #14297
 and #14306 applied? Also, could you try this with the github branch
 ticket_14290_alt? It should be even faster than the latest patch to this
 ticket.

 But, if you really want to "render" the table fast, use python code
 directly to do that. It is easy to do:
 {{{
 buffer = []
 for obj in queryset:
 buffer.append(u'')
 # escape and localize as needed.
 buffer.append(obj.first_val)
 buffer.append(u'')
 buffer.append(obj.second_val)
 ...
 u''.join(buffer)
 }}}

 No amount of optimization to the template rendering system can beat the
 performance of that. I think you will easily get to somewhere around 1s
 for the monthly one. But going much lower than that seems hard, as then it
 is the database that will be your problem.

-- 
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] #9535: File uploads documentation is patchy

[Django]

#9535: File uploads documentation is patchy
+---
  Reporter:  Daniel Pope   | Owner:  
jacob
Status:  assigned   | Milestone:
   
 Component:  Documentation  |   Version:  
1.0  
Resolution: |  Keywords:
   
 Stage:  Accepted   | Has_patch:  0 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Comment (by onelson):

 This just came up on the mailing list, and as I started to look at the
 problem I found the docs in pretty much the same state today (a year on
 from the last update).
 The required reading to work with file uploads (and File/Image model
 fields) is spread around on the following pages:

  * http://docs.djangoproject.com/en/dev/ref/files/file/
  * http://docs.djangoproject.com/en/dev/topics/http/file-uploads/
  * http://docs.djangoproject.com/en/dev/topics/files/
  *
 
http://docs.djangoproject.com/en/dev/ref/models/fields/#django.db.models.FileField

 If people are happy with the idea of taking the http/file-uploads topic
 and expanding there, we can probably reduce the mystery a bit by adding
 some additional examples. Personally, when it comes to working with
 `models.FileField.save()` directly, my initial stumbling block was I
 didn't get that '''`contents`''' argument needed to be an instance of
 `django.core.files.File` rather than a regular file object.  This is
 mentioned quietly.

-- 
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] #14310: MySQL - collate in queries

[Django]

#14310: MySQL - collate in queries
+---
  Reporter:  jakub  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  duplicate  |  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:  => duplicate
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This is essentially #9682

-- 
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] #14290: Rendering is very inefficient when USE_L10N. Caching format values gives 2-7 times improvement

[Django]

#14290: Rendering is very inefficient when USE_L10N. Caching format values gives
2-7 times improvement
---+
  Reporter:  teemu | Owner:  jezdez 
 
Status:  assigned  | Milestone:  1.3
 
 Component:  Internationalization  |   Version:  SVN
 
Resolution:|  Keywords:  localization, 
rendering,
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Comment (by teemu):

 Just a quick update that the latest patch by akaariai is a great
 improvement for my real world scenario too.

 I've a sparse spreadsheet view for inputting and viewing weekly / monthly
 sales data. Cells are  either empty, ints, decimals or dates in that order
 of frequency. Non-trivial database queries are used to construct this view
 but Django rendering is still the biggest bottleneck.

 ||x||SVN HEAD||SVN HEAD with patch||Improvement||
 ||Monthly (~8000 cells)||8.5s||2.6s||3.3x||
 ||Weekly (~2000 cells)||1.9s||0.75s||2.5x||

 Thus, the patch is awesome improvement for real world scenario. After
 applying the patch, still a good chunk of time is spent in rendering, I
 think there are opportunities for improvement here, I'll look if I find
 some low-hanging fruits.

 Profiling data after the patch is applied:
 {{{
  956888 function calls (867495 primitive calls) in 3.294 CPU
 seconds
 ...
    By file 

   tottime
 28.6%   0.871 /Users/teemu/projects//django-
 performance/django/template/__init__.py
  9.0%   0.276
 /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
 /site-packages/MySQLdb/cursors.py
  6.1%   0.186 /Users/teemu/projects//sales/sales/spreadsheet.py
  6.0%   0.184 /Users/teemu/projects//django-
 performance/django/utils/safestring.py
  6.0%   0.184 /Users/teemu/projects//django-
 performance/django/db/models/base.py
  5.2%   0.160 /Users/teemu/projects//django-
 performance/django/utils/formats.py
  4.4%   0.133 /Users/teemu/projects//django-
 performance/django/utils/functional.py
  4.2%   0.128 /Users/teemu/projects//django-
 performance/django/template/context.py
  3.7%   0.114 /Users/teemu/projects//django-
 performance/django/template/defaulttags.py
  3.4%   0.103 /Users/teemu/projects//django-
 performance/django/utils/translation/__init__.py
  2.8%   0.086 /Users/teemu/projects//django-
 performance/django/utils/encoding.py
 }}}

-- 
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] #14313: wrong display of field title in admin

[Django]

#14313: wrong display of field title in admin
--+-
 Reporter:  feuervogel|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I have a model with a field *timestamp_month* which I've added to the
 *list_display* field of the model's admin. In the template it's displayed
 as:

 {{{
 
 Timestamp
 
 
 Month
 
 }}}

 Hence the HTML is generated deep down anywhere in the python code, I
 cannot provide a solution.

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

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

Re: [Django] #9268: Pass custom form values from post-comment to preview-comment

[Django]

#9268: Pass custom form values from post-comment to preview-comment
--+-
  Reporter:  taojian  | Owner:  stuartk
Status:  reopened | Milestone:  1.1
 Component:  django.contrib.comments  |   Version:  SVN
Resolution:   |  Keywords:  comment preview
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by vero216):

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

Comment:

 really liked what this tutorial has to offer! having not much experience
 in tnis sphere I really appreciate every piece of advice I can get. have
 used to download great books with useful information from
 [http://www.btscene.com/ BTscene torrent downloads] , but always search
 for smth new.

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

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

Re: [Django] #14290: Rendering is very inefficient when USE_L10N. Caching format values gives 2-7 times improvement

[Django]

#14290: Rendering is very inefficient when USE_L10N. Caching format values gives
2-7 times improvement
---+
  Reporter:  teemu | Owner:  jezdez 
 
Status:  assigned  | Milestone:  1.3
 
 Component:  Internationalization  |   Version:  SVN
 
Resolution:|  Keywords:  localization, 
rendering,
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Comment (by akaariai):

 There is a different approach to all this. Cache the format string for
 given (language, format_type) in render context. This approach is even
 faster than the method used in the current implementation. It gets around
 0.43 for the USE_L10N case, and 0.37 if not USE_L10N. This is with the
 settings optimization and translations optimization patches. The speedup
 is because we avoid going through a lot of functions when formatting, and
 we can avoid escaping formatted numbers. The speedup is for integers.
 Formatting floats, and the various date types is still slow. We could make
 the USE_L10N case as fast as the USE_L10N=False case, but that would mean
 that language changes in template tags or filters will not have any effect
 to localization in the rendering. Making a default tag that changes the
 language by flushing the cached values in context is easy, though. But
 this would most likely be backwards incompatible change...

 It is of course possible to apply the patch in this ticket AND use caching
 of formats in render context. This way using xxx_format would be fast if
 used in python code, and localization would be even faster when used in
 template rendering.

 For the interested, Jinja2 gets around 0.1 seconds for this case, with
 escaping on.

 There is a patch showing how the concept works at
 http://github.com/akaariai/django. Branch ticket14290_filter is having
 just this idea, ticket_14290_alt has all the patches (plus a bit more)
 applied. Try with DEBUG=True, the DEBUG=False renderer is a bit broken 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] #10427: Bound field needs an easy way to get form value

[Django]

#10427: Bound field needs an easy way to get form value
---+
  Reporter:  toxik | Owner:  nobody  
Status:  reopened  | Milestone:  
 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 trunet):

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

Comment:

 Replying to [comment:29 toxik]:
 > Why isn't this merged into trunk yet? It's been accepted for over a
 year; Django 1.2 was just released. People are clearly interested in this.
 What's the holdup? Sure core committers limited time etc. but for the love
 of god, a year?

 I second this!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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.