Re: [Django] #8275: Unused and unnecessary imports in auth views

[Django]

#8275: Unused and unnecessary imports in auth views
-+--
  Reporter:  julien  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Authentication  |   Version:  SVN   
Resolution:  fixed   |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by russ):

 Oops, sorry -- I ought to have read the rules carefully, first. I should
 have set this to worksforme, since I'm certainly no core developer. My
 mistake!

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

Re: [Django] #8275: Unused and unnecessary imports in auth views

[Django]

#8275: Unused and unnecessary imports in auth views
-+--
  Reporter:  julien  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Authentication  |   Version:  SVN   
Resolution:  fixed   |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russ):

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

Comment:

 The latest SVN version doesn't have the extra import statements. Fixed by
 r8386.

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

[Changeset] r10174 - in django/trunk/django/contrib/gis/geos: . tests

[noreply]

Author: jbronn
Date: 2009-03-25 21:07:11 -0500 (Wed, 25 Mar 2009)
New Revision: 10174

Removed:
   django/trunk/django/contrib/gis/geos/tests/pymutable_geometries.py
Modified:
   django/trunk/django/contrib/gis/geos/collections.py
   django/trunk/django/contrib/gis/geos/geometry.py
   django/trunk/django/contrib/gis/geos/mutable_list.py
   django/trunk/django/contrib/gis/geos/point.py
   django/trunk/django/contrib/gis/geos/polygon.py
   django/trunk/django/contrib/gis/geos/tests/test_mutable_list.py
Log:
Fixed #10620 -- removed carriage returns in a GEOS tests module; fixed other 
errata such as unnecessary `pymutable_geometries` module and not having 
`GEOSGeometry` call `__init__`.



Modified: django/trunk/django/contrib/gis/geos/collections.py
===
--- django/trunk/django/contrib/gis/geos/collections.py 2009-03-25 11:00:20 UTC 
(rev 10173)
+++ django/trunk/django/contrib/gis/geos/collections.py 2009-03-26 02:07:11 UTC 
(rev 10174)
@@ -13,7 +13,6 @@
 
 class GeometryCollection(GEOSGeometry):
 _typeid = 7
-_minlength = 0
 
 def __init__(self, *args, **kwargs):
 "Initializes a Geometry Collection from a sequence of Geometry 
objects."
@@ -77,12 +76,6 @@
 if srid: self.srid = srid
 capi.destroy_geom(prev_ptr)
 
-# Because GeometryCollections need to be rebuilt upon the changing of a
-# component geometry, these routines are set to their counterparts that
-# rebuild the entire geometry.
-_set_single = GEOSGeometry._set_single_rebuild
-_assign_extended_slice = GEOSGeometry._assign_extended_slice_rebuild
-
 @property
 def kml(self):
 "Returns the KML for this Geometry Collection."

Modified: django/trunk/django/contrib/gis/geos/geometry.py
===
--- django/trunk/django/contrib/gis/geos/geometry.py2009-03-25 11:00:20 UTC 
(rev 10173)
+++ django/trunk/django/contrib/gis/geos/geometry.py2009-03-26 02:07:11 UTC 
(rev 10174)
@@ -91,6 +91,7 @@
 
 # Post-initialization setup.
 self._post_init(srid)
+super(GEOSGeometry, self).__init__()
 
 def _post_init(self, srid):
 "Helper routine for performing post-initialization setup."

Modified: django/trunk/django/contrib/gis/geos/mutable_list.py
===
--- django/trunk/django/contrib/gis/geos/mutable_list.py2009-03-25 
11:00:20 UTC (rev 10173)
+++ django/trunk/django/contrib/gis/geos/mutable_list.py2009-03-26 
02:07:11 UTC (rev 10174)
@@ -50,7 +50,18 @@
 _maxlength = None
 _IndexError = IndexError
 
-### Special methods for Python list interface ###
+### Python initialization and list interface methods ###
+
+def __init__(self, *args, **kwargs):
+if not hasattr(self, '_getitem_internal'):
+self._getitem_internal = self._getitem_external
+
+if not hasattr(self, '_set_single'):
+self._set_single = self._set_single_rebuild
+self._assign_extended_slice = self._assign_extended_slice_rebuild
+
+super(ListMixin, self).__init__(*args, **kwargs)
+
 def __getitem__(self, index):
 "Gets the coordinates of the point(s) at the specified index/slice."
 if isinstance(index, slice):
@@ -128,19 +139,6 @@
 
 ### Private API routines unique to ListMixin ###
 
-def __init__(self, *args, **kwargs):
-if not hasattr(self, '_getitem_internal'):
-self._getitem_internal = self._getitem_external
-
-if hasattr(self, '_set_single'):
-self._canSetSingle = True
-else:
-self._canSetSingle = False
-self._set_single = self._set_single_rebuild
-self._assign_extended_slice   = self._assign_extended_slice_rebuild
-
-super(ListMixin, self).__init__(*args, **kwargs)
-
 def _rebuild(self, newLen, newItems):
 if newLen < self._minlength:
 raise ValueError('Must have at least %d items' % self._minlength)

Modified: django/trunk/django/contrib/gis/geos/point.py
===
--- django/trunk/django/contrib/gis/geos/point.py   2009-03-25 11:00:20 UTC 
(rev 10173)
+++ django/trunk/django/contrib/gis/geos/point.py   2009-03-26 02:07:11 UTC 
(rev 10174)
@@ -52,9 +52,6 @@
 
 return capi.create_point(cs)
 
-def _getitem_external(self, index):
-return self._cs.getOrdinate(index, 0)
-
 def _set_collection(self, length, items):
 ptr = self._create_point(length, items)
 if ptr:

Modified: django/trunk/django/contrib/gis/geos/polygon.py
===
--- django/trunk/django/contrib/gis/geos/polygon.py 2009-03-25 11:00:20 UTC 
(rev 10173)
+++ django/trunk/django/contrib/gis/geos/polygon.py 2009-03-26 02:07:11 UTC 
(rev 

Re: [Django] #10620: All .py files have LF line endings except test_mutable_list.py

[Django]

#10620: All .py files have LF line endings except test_mutable_list.py
---+
  Reporter:  ruiyen| Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  GIS   |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by jbronn):

 Damn!  However, I didn't forgot to set `svn:ignore`.

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

Re: [Django] #7596: Multiple Database Inserts using 1 query

[Django]

#7596: Multiple Database Inserts using 1 query
---+
  Reporter:  erikcw| Owner:  nobody 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  database, 
create, multirow, feature
 Stage:  Design decision needed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 Quick question: A multiple db inserts using one query would achieve more
 of a speed of than just using transaction managent e.g.
 @transaction.commit_on_success?

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

[Django] #10627: Middleware using len() on response.content is gobbling generators

[Django]

#10627: Middleware using len() on response.content is gobbling generators
+---
 Reporter:  FunkyBob|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  SVN   
 Keywords:  middleware  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 We recently found that a slow view (4 to 5 minutes) was made even worse
 because we couldn't give a generator to HttpResponse and have it still
 work.

 This turned out to be because two of the built-in middlewares ( gzip and
 conditional-get ) assume the response.content is a string, and call
 len(response.content) -- which consumes the generator.

 Once we bypassed these, the time to first response was seconds, and the
 entire process ran smoothly.

 So, attached are two patches to work around this issue:
  1. In the case of conditional-get, it skips setting Content-Length header
 if not response._is_string.
  2. In the case of gzip, simply move the Content-Encoding test to the
 front, so the documentation saying gzip will be skipped on anything with a
 Content-Encoding header works as expected.

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

Re: [Django] #10623: scheme for filtering an object based on a ManyToManyField or a reverse ForeignKeyField

[Django]

#10623: scheme for filtering an object based on a ManyToManyField or a reverse
ForeignKeyField
+---
  Reporter:  while0pass | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 I have no idea what this ticket is referring to. Is it a correction for
 existing documentation? Is it a suggestion for new documentation? What
 problem is it trying to correct? If you're going to go to the effort of
 opening a ticket, PLEASE go to the effort of actually explaining the
 problem you are trying to fix.

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

Re: [Django] #10626: Default model ordering affects annotation query

[Django]

#10626: Default model ordering affects annotation query
--+-
  Reporter:  kmassey  | Owner:  
Status:  closed   | Milestone:  1.1 beta
 Component:  ORM aggregation  |   Version:  1.1-beta-1  
Resolution:  duplicate|  Keywords:  values annotate ordering
 Stage:  Unreviewed   | Has_patch:  0   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by Alex):

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

Comment:

 This is a dupe of #10574.

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

[Django] #10626: Default model ordering affects annotation query

[Django]

#10626: Default model ordering affects annotation query
--+-
 Reporter:  kmassey   |   Owner:
   Status:  new   |   Milestone:  1.1 beta  
Component:  ORM aggregation   | Version:  1.1-beta-1
 Keywords:  values annotate ordering  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Example models without default orderings:
 {{{
 class Author(models.Model):
 id = models.IntegerField(primary_key=True,
  help_text='Uniquely identifies an author.')
 name= models.CharField(max_length=200,
  help_text="Author's first name.")

 class Book(models.Model):
 id = models.IntegerField(primary_key=True,
  help_text='Uniquely identifies a book.')
 title = models.CharField(max_length=200,
  help_text='The title of this book.')
 author = models.ForeignKey(Author, db_column='author_id',
  help_text='The author of this book.')
 price = models.FloatField(
  help_text='Price of the book.')
 inventory = models.IntegerField(
  help_text='Copies of book in the store.')
 }}}

 Use values() and annotate() to determine the number of books at each
 price. This works as I expected:
 {{{
 >>> q = Book.objects.values('price').annotate(Count('price'))
 >>> list(q)
 [{'price': 7.9902, 'price__count': 2}, {'price':
 9.9902, 'price__count': 1}]
 }}}

 Now add default orderings to the models:
 {{{
 class Author(models.Model):
 id = models.IntegerField(primary_key=True,
  help_text='Uniquely identifies an author.')
 name= models.CharField(max_length=200,
  help_text="Author's first name.")
 class Meta:
 ordering = ['id']

 class Book(models.Model):
 id = models.IntegerField(primary_key=True,
  help_text='Uniquely identifies a book.')
 title = models.CharField(max_length=200,
  help_text='The title of this book.')
 author = models.ForeignKey(Author, db_column='author_id',
  help_text='The author of this book.')
 price = models.FloatField(
  help_text='Price of the book.')
 inventory = models.IntegerField(
  help_text='Copies of book in the store.')
 class Meta:
 ordering = ['id']
 }}}

 And repeat the query:

 {{{
 >>> q = Book.objects.values('price').annotate(Count('price'))
 >>> list(q)
 [{'price': 9.9902, 'price__count': 1}, {'price':
 7.9902, 'price__count': 1}, {'price': 7.9902,
 'price__count': 1}]
 }}}

 This isn't what I expected. It took me a while to make the connection
 between the model default ordering and the behavior of the annotation
 query. Once I saw it, the fix was easy:
 {{{
 >>> q = Book.objects.values('price').annotate(Count('price')).order_by()
 >>> list(q)
 [{'price': 7.9902, 'price__count': 2}, {'price':
 9.9902, 'price__count': 1}]
 }}}

 I'm not sure if this should be a bug per se. If not, perhaps it could be
 noted in the aggregation documentation.

 Thanks,
 Kevin

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

Re: [Django] #10622: List editable breaks with model inheritance

[Django]

#10622: List editable breaks with model inheritance
---+
  Reporter:  oyvind| Owner:  nobody 
  
Status:  new   | Milestone:  1.1
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  list_editable 
inheritance
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

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

[Django] #10625: Ewkt regexp incorrectly escaped

[Django]

#10625: Ewkt regexp incorrectly escaped
-+--
 Reporter:  timlinux |   Owner:  springmeyer
   Status:  new  |   Milestone:  1.1 beta   
Component:  GIS  | Version:  SVN
 Keywords:  regexp ewkt  |   Stage:  Unreviewed 
Has_patch:  1|  
-+--
 Hi

 in
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/gis/templates/gis/admin/openlayers.js
 the regexp on line 3 is incorrectly escaped, causing conversion from ewkt
 to wkt to fail for me. I fixed it by changing:

 {{{
 new RegExp("^SRID=\d+;(.+)", "i");
 }}}

 to

 {{{
 new RegExp("^SRID=\\d+;(.+)", "i");
 }}}

 After which it correctly works for me. Would be great if you can apply
 this fix.

 Thanks

 Tim

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

Re: [Django] #10624: has_add_permission not working correctly

[Django]

#10624: has_add_permission not working correctly
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 This is a dupe of #9036.

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

[Django] #10624: has_add_permission not working correctly

[Django]

#10624: has_add_permission not working correctly
---+
 Reporter:  anonymous  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 There's a remaining issue regarding ticket
 [http://code.djangoproject.com/ticket/5447 #5447]. I added the method "def
 has_add_permission(*args):return False" to a ModelAdmin class, but the
 "Add" button stills appearing in the application page
 (http://mysite/myproject/admin/myapplication) next to the model.

 It doesn't show up in the Home admin page
 (http://mysite/myproject/admin/), neither in the model modify page
 (http://mysite/myproject/admin/myapplication/somemodel), and also clicking
 in the "Add" button that appears in the application page, it shows the
 message "Permission denied", which is the expected behavior.

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

Re: [Django] #2367: [patch] pagination for date based generic views

[Django]

#2367: [patch] pagination for date based generic views
--+-
  Reporter:  andr...@weblinc.com  | Owner:  nobody
Status:  new  | Milestone:
 Component:  Generic views|   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Changes (by afitzpatrick):

 * cc: ai...@reincubate.com (added)

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

Re: [Django] #10609: Permissions on admin actions

[Django]

#10609: Permissions on admin actions
+---
  Reporter:  leitjohn   | Owner:  leitjohn  
Status:  assigned   | Milestone:  1.1   
 Component:  Uncategorized  |   Version:  1.1-beta-1
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by leitjohn):

  * status:  new => assigned

Comment:

 Opps, that was a little ambitious of me :)

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

Re: [Django] #10611: Doc TOC becomes invisible during scroll down

[Django]

#10611: Doc TOC becomes invisible during scroll down
-+--
  Reporter:  adrian_...@yahoo.com| Owner:  nobody
Status:  new | Milestone:
 Component:  Documentation   |   Version:  SVN   
Resolution:  |  Keywords:  CSS   
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by adrian_...@yahoo.com):

 There's also the option to do it like O'Reilly Safari.  Most doc browsers
 do have visible navigation/position indication.

 But I guess people just don't like the idea so I'll
 drop it.   Thanks for considering it.

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

Re: [Django] #9315: Keyword arguments with spaces and the url tag

[Django]

#9315: Keyword arguments with spaces and the url tag
--+-
  Reporter:  alexisbellido| Owner:  nessita 

Status:  assigned | Milestone:  1.1 

 Component:  Template system  |   Version:  1.0 

Resolution:   |  Keywords:  url, tplrf-fixed, 
pycamp2009
 Stage:  Accepted | Has_patch:  1   

Needs_docs:  0|   Needs_tests:  0   

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

 Last night, while being unable to sleep, I figured out that the non-greedy
 part of the proposed regular expression (in teh pacth attached) can be
 changed to a greedy expression, improving the performance of it.

 So, where it reads:

 {{{
 smart_split_re = re.compile(r"""(\S*?"(?:[^"\\]*(?:\\.[^"\\]*)*)"\S*| #
 matches '"value with spaces"' and 'keyword="value with spaces"'
  \S*?'(?:[^'\\]*(?:\\.[^'\\]*)*)'\S*| #
 same as above but with quotes swapped
  \S+) #
 matches not whitespaces""",
 re.VERBOSE)
 }}}

 the {{{\S+?"}}} can be changed to {{{[^\s"]"}}} (same for the {{{'}}}
 character). I'll submit a new patch in a while, prior some checkings.

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

Re: [Django] #10611: Doc TOC becomes invisible during scroll down

[Django]

#10611: Doc TOC becomes invisible during scroll down
-+--
  Reporter:  adrian_...@yahoo.com| Owner:  nobody
Status:  new | Milestone:
 Component:  Documentation   |   Version:  SVN   
Resolution:  |  Keywords:  CSS   
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by kmtracey):

 Replying to [comment:2 adrian_...@yahoo.com]:
 > Apart from the question of how to accomplish it, isn't it clear that a
 column with the TOC in it is better than a blank column?
 >

 Eh, not necessarily, and how to accomplish it is significant.  Like
 Malcolm, I find floating things that move along as I scroll very
 distracting.  And I don't find the frames solution much better -- I like
 there to be only one scroll bar for the page.  That may be a personal
 quirk, but there you are: personally I prefer what we have now than either
 of the solutions mentioned so far.  The top of the page is easy enough to
 get to if I want to see the TOC, as is simply searching on the page for a
 likely keyword to get where I really want to be.

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

Re: [Django] #10611: Doc TOC becomes invisible during scroll down

[Django]

#10611: Doc TOC becomes invisible during scroll down
-+--
  Reporter:  adrian_...@yahoo.com| Owner:  nobody
Status:  new | Milestone:
 Component:  Documentation   |   Version:  SVN   
Resolution:  |  Keywords:  CSS   
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by adrian_...@yahoo.com):

 Perhaps I should have mentioned another point.   The TOC has links to
 sections of the current page, which are very useful
 especially in the reference documentation.  When they are visible.  This
 is a common use case.

 Secondly there is no movement in the MS example.   You could argue against
 using frames but it is clearly more usable
 that what we have now.

 Apart from the question of how to accomplish it, isn't it clear that a
 column with the TOC in it is better than a blank column?

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

[Django] #10623: scheme for filtering an object based on a ManyToManyField or a reverse ForeignKeyField

[Django]

#10623: scheme for filtering an object based on a ManyToManyField or a reverse
ForeignKeyField
---+
 Reporter:  while0pass |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 http://docs.djangoproject.com/en/dev/topics/db/queries/#spanning-multi-
 valued-relationships

 filtering an object based on a ManyToManyField or a reverse
 ForeignKeyField:


 {{{
 filter_1 (condition_11, ..., condition_1n). ... .filter_k (condition_11,
 ..., condition_1m) ==
 (condition_11 ''AND'' ... ''AND'' condition_1n) '''OR''' ... '''OR'''
 (condition_11 ''AND'' ... ''AND'' condition_1m)

 }}}

 filtering an object based NOT on a ManyToManyField or a reverse
 ForeignKeyField:


 {{{
 filter_1 (condition_11, ..., condition_1n). ... .filter_k (condition_11,
 ..., condition_1m) ==
 (condition_11 ''AND'' ... ''AND'' condition_1n) '''AND''' ... '''AND'''
 (condition_11 ''AND'' ... ''AND'' condition_1m)
 }}}

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

Re: [Django] #10622: List editable breaks with model inheritance

[Django]

#10622: List editable breaks with model inheritance
---+
  Reporter:  oyvind| Owner:  nobody 
  
Status:  new   | Milestone:  1.1
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  list_editable 
inheritance
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by oyvind):

 In file /home/oyvind/code/django/contrib/admin/templatetags/admin_list.py

 line 240, in items_for_result

 {{{
 #!python
 yield mark_safe(force_unicode(form[cl.model._meta.pk.attname]))
 }}}

 Changed to

 {{{
 #!python
 yield mark_safe(force_unicode(form[cl.model._meta.pk.name]))
 }}}

 name is used here:

 http://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L444

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

[Django] #10622: List editable breaks with model inheritance

[Django]

#10622: List editable breaks with model inheritance
---+
 Reporter:  oyvind |   Owner:  nobody
   Status:  new|   Milestone:
Component:  django.contrib.admin   | Version:  SVN   
 Keywords:  list_editable inheritance  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I register a model in the adminsite that is inherited from another model
 with list_editable on some fields, then add a entry. When I am redirected
 to the change_list I get a traceback about a missing field in the form.

 http://dpaste.com/18906/ - traceback

 http://dpaste.com/18895/ - example app

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

Re: [Django] #9994: list_filter ignores to_field

[Django]

#9994: list_filter ignores to_field
---+
  Reporter:  jzylks| Owner:  mtredinnick
Status:  closed| Milestone:  1.1
 Component:  django.contrib.admin  |   Version:  1.0
Resolution:  fixed |  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 @lucalenardi - You appear to be correct; changeset [10140] introduced a
 regression into 1.0.X. This was corrected in [10170] for trunk; I'll merge
 down the fix for 1.0.X.

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

[Django] #10621: Add a way to have an aggregate() result as a queryset

[Django]

#10621: Add a way to have an aggregate() result as a queryset
--+-
 Reporter:  mtredinnick   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 If one is trying to construct a complex queryset, involving nesting other
 querysets, there's currently no way to include the results of an
 `aggregate()` call. For example, consider
 {{{
 #!python
 class Item(models.Model):
name = models.CharField(max_length=10)
 }}}

 If I want to include the number of Items in some other queryset, such as
 {{{
 #!python
 
Foo.objects.filter(items__in=[...]).annotate(num=Count("items").filter(num=item_count)
 }}}
 We can't write item_count (which would be
 `Items.objects.aggregate(Count("id"))`) as an inner queryset here, since
 the `aggregate()` call returns a dictionary, not a queryset.

 The return value of `aggregate()` is fine, but this ticket is about adding
 a version that does return a queryset. Right now, there's no way to fake
 this with `annotate(...).values(...)` since that always introduces a
 `GROUP BY` clause and the whole point is not to group by anything.

 Not sure whether adding a parameter to `aggregate()` is the right idea, or
 adding something to the `annotate()` route to specify "no grouping
 whatsoever". This is all 1.2 timeframe stuff, but it's something to think
 about.

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

Re: [Django] #10478: Multiple querysets as rvalues generating bad SQL

[Django]

#10478: Multiple querysets as rvalues generating bad SQL
---+
  Reporter:  mtredinnick   | Owner:  mtredinnick
Status:  closed| Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:  invalid   |  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 I wasn't thinking clearly here. The results produced by this query are
 correct.

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

Re: [Django] #9518: Wrong JSON snippet on fixture documentation

[Django]

#9518: Wrong JSON snippet on fixture documentation
-+--
  Reporter:  cla...@2xlibre.net  | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Documentation   |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by hheimbuerger):

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

Comment:

 Sorry, still incorrect. As shown in cla...@2xlibre.net's correction, the
 outer list may not have a comma at the end either.

 The last two lines have to be
 {{{
   }
 ]
 }}}
 not
 {{{
   },
 ]
 }}}

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

[Changeset] r10172 - in django/trunk/docs: ref/models topics/db

[noreply]

Author: mtredinnick
Date: 2009-03-25 04:05:38 -0500 (Wed, 25 Mar 2009)
New Revision: 10172

Modified:
   django/trunk/docs/ref/models/querysets.txt
   django/trunk/docs/topics/db/aggregation.txt
Log:
Fixed #10574 -- Documented interaction between annotations and order_by.

In the future, I'd like to fix this properly, but the current behavior
has the advantage of being consistent across the board (and changing it
everywhere is backwards-incompatible with documented functionality).

Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2009-03-25 08:28:57 UTC (rev 
10171)
+++ django/trunk/docs/ref/models/querysets.txt  2009-03-25 09:05:38 UTC (rev 
10172)
@@ -296,6 +296,8 @@
 ordering was undefined prior to calling ``reverse()``, and will remain
 undefined afterward).
 
+.. _querysets-distinct:
+
 ``distinct()``
 ~~
 

Modified: django/trunk/docs/topics/db/aggregation.txt
===
--- django/trunk/docs/topics/db/aggregation.txt 2009-03-25 08:28:57 UTC (rev 
10171)
+++ django/trunk/docs/topics/db/aggregation.txt 2009-03-25 09:05:38 UTC (rev 
10172)
@@ -315,6 +315,57 @@
 clause is applied after the ``annotate()`` clause, you need to explicitly
 include the aggregate column.
 
+Interaction with default ordering or ``order_by()``
+
+
+Fields that are mentioned in the ``order_by()`` part of a queryset (or which
+are used in the default ordering on a model) are used when selecting the
+output data, even if they are not otherwise specified in the ``values()``
+call. These extra fields are used to group "like" results together and they
+can make otherwise identical result rows appear to be separate. This shows up,
+particularly, when counting things.
+
+By way of example, suppose you have a model like this::
+
+class Item(models.Model):
+name = models.CharField(max_length=10)
+data = models.IntegerField()
+
+class Meta:
+ordering = ["name"]
+
+The important part here is the default ordering on the ``name`` field. If you
+want to count how many times each distinct ``data`` value appears, you might
+try this::
+
+# Warning: not quite correct!
+Item.objects.values("data").annotate(Count("id"))
+
+...which will group the ``Item`` objects by their common ``data`` values and
+then count the number of ``id`` values in each group. Except that it won't
+quite work. The default ordering by ``name`` will also play a part in the
+grouping, so this query will group by distinct ``(data, name)`` pairs, which
+isn't what you want. Instead, you should construct this queryset::
+
+Item.objects.values("data").annotate(Count("id")).order_by()
+
+...clearing any ordering in the query. You could also order by, say, ``data``
+without any harmful effects, since that is already playing a role in the
+query.
+
+This behavior is the same as that noted in the queryset documentation for
+:ref:`distinct() ` and the general rule is the same:
+normally you won't want extra columns playing a part in the result, so clear
+out the ordering, or at least make sure it's restricted only to those fields
+you also select in a ``values()`` call.
+
+.. note::
+You might reasonably ask why Django doesn't remove the extraneous columns
+for you. The main reason is consistency with ``distinct()`` and other
+places: Django **never** removes ordering constraints that you have
+specified (and we can't change those other methods' behavior, as that
+would violate our :ref:`misc-api-stability` policy).
+
 Aggregating annotations
 ---
 


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

Re: [Django] #10574: Remove unnecessary ordering in values() queries

[Django]

#10574: Remove unnecessary ordering in values() queries
--+-
  Reporter:  mtredinnick  | Owner:  mtredinnick
Status:  new  | Milestone:  1.1
 Component:  ORM aggregation  |   Version:  SVN
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by mtredinnick):

 I'm going to document our way out of this one so that Django's behaviour
 is consistent (if not brilliant). We never remove ordering constraints
 internally, it's always up to the user.

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

[Changeset] r10171 - django/trunk/django/conf/locale/pl/LC_MESSAGES

[noreply]

Author: zgoda
Date: 2009-03-25 03:28:57 -0500 (Wed, 25 Mar 2009)
New Revision: 10171

Modified:
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
Log:
Regenerated and recompiled Polish translations after [10168] (no real change, 
just cleanup)


Modified: django/trunk/django/conf/locale/pl/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2009-03-25 
04:41:40 UTC (rev 10170)
+++ django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2009-03-25 
08:28:57 UTC (rev 10171)
@@ -5,7 +5,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2009-03-24 09:26+0100\n"
+"POT-Creation-Date: 2009-03-25 09:18+0100\n"
 "PO-Revision-Date: 2008-02-25 15:53+0100\n"
 "Last-Translator: Jarek Zgoda \n"
 "MIME-Version: 1.0\n"
@@ -463,16 +463,6 @@
 msgid "One or more %(fieldname)s in %(name)s:"
 msgstr "Jedno lub więcej %(fieldname)s w %(name)s:"
 
-# from the code it seems these translations are not really used
-# is it placeholder only? i'm leaving them as fuzzy (JZ)
-#: contrib/admin/util.py:222
-#, fuzzy
-msgid "verbose_name"
-msgid_plural "verbose_name_plural"
-msgstr[0] ""
-msgstr[1] ""
-msgstr[2] ""
-
 #: contrib/admin/widgets.py:70
 msgid "Date:"
 msgstr "Data:"
@@ -671,8 +661,8 @@
 "your account doesn't have permission to delete the following types of "
 "objects:"
 msgstr ""
-"Skasowanie %(object_name)s spowoduje usunięcie zależnych obiektów, lecz "
-"nie posiadasz uprawnień do usunięcia następujących typów obiektów:"
+"Skasowanie %(object_name)s spowoduje usunięcie zależnych obiektów, lecz nie "
+"posiadasz uprawnień do usunięcia następujących typów obiektów:"
 
 #: contrib/admin/templates/admin/delete_selected_confirmation.html:22
 #, python-format
@@ -3882,14 +3872,14 @@
 msgid "Enter a valid time in HH:MM[:ss[.uu]] format."
 msgstr "Proszę wpisać poprawną godzinę w formacie HH:MM[:ss[.uu]]."
 
-#: db/models/fields/related.py:779
+#: db/models/fields/related.py:787
 msgid ""
 "Hold down \"Control\", or \"Command\" on a Mac, to select more than one."
 msgstr ""
 "Przytrzymaj wciśnięty klawisz \"Ctrl\" lub \"Command\" na Mac'u aby "
 "zaznaczyć więcej niż jeden wybór."
 
-#: db/models/fields/related.py:857
+#: db/models/fields/related.py:865
 #, python-format
 msgid "Please enter valid %(self)s IDs. The value %(value)r is invalid."
 msgid_plural ""


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

Re: [Django] #10607: Use 'get_fieldset' to retieve fieldsets for inline related forms

[Django]

#10607: Use 'get_fieldset' to retieve fieldsets for inline related forms
---+
  Reporter:  juriejan  | Owner:  juriejan   
 
Status:  new   | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  fieldsets inline 
related
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by juriejan):

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

Re: [Django] #10607: Use 'get_fieldset' to retieve fieldsets for inline related forms

[Django]

#10607: Use 'get_fieldset' to retieve fieldsets for inline related forms
---+
  Reporter:  juriejan  | Owner:  juriejan   
 
Status:  new   | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  fieldsets inline 
related
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by juriejan):

 * cc: juriejanbo...@gmail.com (added)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

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

Re: [Django] #10620: All .py files have LF line endings except test_mutable_list.py

[Django]

#10620: All .py files have LF line endings except test_mutable_list.py
---+
  Reporter:  ruiyen| Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  GIS   |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 We just need to send the eol-style. It happens sometimes.

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

[Django] #10620: All .py files have LF line endings except test_mutable_list.py

[Django]

#10620: All .py files have LF line endings except test_mutable_list.py
+---
 Reporter:  ruiyen  |   Owner:  nobody
   Status:  new |   Milestone:  1.1 beta  
Component:  GIS | Version:  1.1-beta-1
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Source file
 
http://code.djangoproject.com/svn/django/trunk/django/contrib/gis/geos/tests/test_mutable_list.py
 (as of revision 10170 and version 1.1-beta-1) has CRLF line endings,
 whereas all other .py files under
 http://code.djangoproject.com/svn/django/trunk/django/ have LF line
 endings.

 This interfered with a Python 2to3 conversion that I was experimenting
 with, although I am very aware that Python 3 is not supported yet.

 Minimal solution: Replace the CRLF line endings in file
 test_mutable_list.py with LF line endings.

 Full solution: Replace the CRLF line endings in file test_mutable_list.py
 with LF line endings, then set the "svn:mime-type" property of all .py
 files to "text/x-python", and set the "svn:eol-style" property of all .py
 files to "native".

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