Re: [Django] #17627: contrib.admin.util is misnamed

2012-02-01 Thread Django 
#17627: contrib.admin.util is misnamed
--+
 Reporter:  PaulM |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by claudep):

 * type:  Uncategorized => Cleanup/optimization
 * severity:  Release blocker => Normal


Comment:

 Yes, it is known that some unification is needed regarding util.py vs
 utils.py files. However this has not been introduced in r17145, but in
 r7967 4 years ago. Hence removing the release blocker flag.

-- 
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] #17481: leading zeros are missing from result of pbkdf2

2012-02-01 Thread Django 
#17481: leading zeros are missing from result of pbkdf2
-+---
 Reporter:  bhuztez  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---
Changes (by PaulM):

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


Comment:

 In [17418]:
 {{{
 #!CommitTicketReference repository="" revision="17418"
 Fixed #17481. pbkdf2 hashes no longer ommit leading zeros.

 Some existing user passwords may need to be reset or converted
 after this change. See the 1.4-beta release notes for more details.

 Thanks bhuztez for the report and initial patch, claudep for the test.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] r17418 - in django/trunk: django/utils tests/regressiontests/utils

2012-02-01 Thread noreply 
Author: PaulM
Date: 2012-02-01 20:44:17 -0800 (Wed, 01 Feb 2012)
New Revision: 17418

Modified:
   django/trunk/django/utils/crypto.py
   django/trunk/tests/regressiontests/utils/crypto.py
Log:
Fixed #17481. pbkdf2 hashes no longer ommit leading zeros. 

Some existing user passwords may need to be reset or converted 
after this change. See the 1.4-beta release notes for more details.

Thanks bhuztez for the report and initial patch, claudep for the test.


Modified: django/trunk/django/utils/crypto.py
===
--- django/trunk/django/utils/crypto.py 2012-02-01 21:36:18 UTC (rev 17417)
+++ django/trunk/django/utils/crypto.py 2012-02-02 04:44:17 UTC (rev 17418)
@@ -10,8 +10,8 @@
 from django.conf import settings
 
 
-trans_5c = "".join([chr(x ^ 0x5C) for x in xrange(256)])
-trans_36 = "".join([chr(x ^ 0x36) for x in xrange(256)])
+_trans_5c = "".join([chr(x ^ 0x5C) for x in xrange(256)])
+_trans_36 = "".join([chr(x ^ 0x36) for x in xrange(256)])
 
 
 def salted_hmac(key_salt, value, secret=None):
@@ -66,7 +66,7 @@
 return result == 0
 
 
-def bin_to_long(x):
+def _bin_to_long(x):
 """
 Convert a binary string into a long integer
 
@@ -75,17 +75,15 @@
 return long(x.encode('hex'), 16)
 
 
-def long_to_bin(x):
+def _long_to_bin(x, hex_format_string):
 """
-Convert a long integer into a binary string
+Convert a long integer into a binary string.
+hex_format_string is like "%020x" for padding 10 characters.
 """
-hex = "%x" % (x)
-if len(hex) % 2 == 1:
-hex = '0' + hex
-return binascii.unhexlify(hex)
+return binascii.unhexlify(hex_format_string % x)
 
 
-def fast_hmac(key, msg, digest):
+def _fast_hmac(key, msg, digest):
 """
 A trimmed down version of Python's HMAC implementation
 """
@@ -93,9 +91,9 @@
 if len(key) > dig1.block_size:
 key = digest(key).digest()
 key += chr(0) * (dig1.block_size - len(key))
-dig1.update(key.translate(trans_36))
+dig1.update(key.translate(_trans_36))
 dig1.update(msg)
-dig2.update(key.translate(trans_5c))
+dig2.update(key.translate(_trans_5c))
 dig2.update(dig1.digest())
 return dig2
 
@@ -123,13 +121,15 @@
 l = -(-dklen // hlen)
 r = dklen - (l - 1) * hlen
 
+hex_format_string = "%%0%ix" % (hlen * 2)
+
 def F(i):
 def U():
 u = salt + struct.pack('>I', i)
 for j in xrange(int(iterations)):
-u = fast_hmac(password, u, digest).digest()
-yield bin_to_long(u)
-return long_to_bin(reduce(operator.xor, U()))
+u = _fast_hmac(password, u, digest).digest()
+yield _bin_to_long(u)
+return _long_to_bin(reduce(operator.xor, U()), hex_format_string)
 
 T = [F(x) for x in range(1, l + 1)]
 return ''.join(T[:-1]) + T[-1][:r]

Modified: django/trunk/tests/regressiontests/utils/crypto.py
===
--- django/trunk/tests/regressiontests/utils/crypto.py  2012-02-01 21:36:18 UTC 
(rev 17417)
+++ django/trunk/tests/regressiontests/utils/crypto.py  2012-02-02 04:44:17 UTC 
(rev 17418)
@@ -108,6 +108,17 @@
"c4007d5298f9033c0241d5ab69305e7b64eceeb8d"
"834cfec"),
 },
+# Check leading zeros are not stripped (#17481) 
+{
+"args": { 
+"password": chr(186), 
+"salt": "salt", 
+"iterations": 1, 
+"dklen": 20, 
+"digest": hashlib.sha1, 
+}, 
+"result": '0053d3b91a7f1e54effebd6d68771e8a6e0b2c5b',
+},
 ]
 
 def test_public_vectors(self):
@@ -125,11 +136,15 @@
 Theory: If you run with 100 iterations, it should take 100
 times as long as running with 1 iteration.
 """
-n1, n2 = 1000, 10
-elapsed = lambda f: timeit.Timer(f, 'from django.utils.crypto import 
pbkdf2').timeit(number=1)
+# These values are chosen as a reasonable tradeoff between time
+# to run the test suite and false positives caused by imprecise
+# measurement.
+n1, n2 = 20, 80
+elapsed = lambda f: timeit.Timer(f, 
+'from django.utils.crypto import pbkdf2').timeit(number=1)
 t1 = elapsed('pbkdf2("password", "salt", iterations=%d)' % n1)
 t2 = elapsed('pbkdf2("password", "salt", iterations=%d)' % n2)
 measured_scale_exponent = math.log(t2 / t1, n2 / n1)
-# This should be less than 1. We allow up to 1.1 so that tests don't 
+# This should be less than 1. We allow up to 1.2 so that tests don't 
 # fail nondeterministically too often.
-self.assertLess(measured_scale_exponent, 1.1)
+self.assertLess(measured_scale_exponent, 1.2)

-- 
You received this message because you are subscribed to the Google Groups 
"Django

Re: [Django] #16735: Queryset values should be aliasable

2012-02-01 Thread Django 
#16735: Queryset values should be aliasable
-+-
 Reporter:  alex.latchford@… |Owner:  nate_b
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  queryset, alias, |  decision needed
  values |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 What is the rationale of doing this for values_list()? If I am not
 mistaken, you will get a list back anyways. So the aliases are used for
 what?

 The .annotate() + values_list() seems to be a bug. Basically, multiple
 annotates in one .annotate() call have indeterminate order, which results
 in indeterminate order in the values_list(). I bet some users will be hit
 if/when Python randomizes the hashing algorithm. So, indeterminate order
 is not good. Unfortunately I don't see a fix other than disallowing
 multiple annotates in one call. Which is backwards incompatible.

 In addition, some benchmark that this doesn't slow down fetching large
 sets of objects from the DB is needed. .values() is mostly an
 optimization, so it should remain as fast as possible. Maybe django-bench
 contains some benchmark already?

-- 
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] #17627: contrib.admin.util is misnamed

2012-02-01 Thread Django 
#17627: contrib.admin.util is misnamed
---+
   Reporter:  PaulM|  Owner:  nobody
   Type:  Uncategorized| Status:  new
  Component:  contrib.admin|Version:  SVN
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+
 r17145 included a change which added `contrib.admin.util`. This module
 should be `contrib.admin.utils` in line with similar existing modules
 throughout the rest of the codebase.

 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/util.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-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] #16735: Queryset values should be aliasable

2012-02-01 Thread Django 
#16735: Queryset values should be aliasable
-+-
 Reporter:  alex.latchford@… |Owner:  nate_b
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  queryset, alias, |  decision needed
  values |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by nate_b):

 * stage:  Accepted => Design decision needed


Comment:

 Ostensibly, I agree with you - it's a bit odd, and I don't presume to know
 why one would use it.  Initially, when I added that to
 {{{values_list()}}}, it was to "harmonize" it with the features added to
 {{{values()}}}.  However, similar behavior results when you {{{annotate}}}
 or {{{aggregate}}} on a {{{values_list()}}} call - the aliased names are
 added in the order of the keys.

 So, I would propose one of three solutions:

 1.  Remove aliased names in the {{{values_list()}}} call entirely,
 replaced with a dummy empty dictionary.
 2.  Force the sorting of the aliases, presumably alphabetically; this
 would also suggest repairing this defect with annotations and
 aggregations, which may not be quite so simple.
 3.  Leave as is in my updated patch, with indeterminate order returned.

 I will be happy to implement which ever one seems best to a core
 developer.  As such, I'm setting this to DDN.

-- 
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] r17417 - django/trunk/django/test

2012-02-01 Thread noreply 
Author: aaugustin
Date: 2012-02-01 13:36:18 -0800 (Wed, 01 Feb 2012)
New Revision: 17417

Modified:
   django/trunk/django/test/testcases.py
Log:
Improved the fix of r17416 so it actually works on all platforms. Refs #17469.


Modified: django/trunk/django/test/testcases.py
===
--- django/trunk/django/test/testcases.py   2012-02-01 20:08:10 UTC (rev 
17416)
+++ django/trunk/django/test/testcases.py   2012-02-01 21:36:18 UTC (rev 
17417)
@@ -998,8 +998,8 @@
 return settings.MEDIA_URL
 
 def serve(self, request):
-return serve(request, request.path,
-document_root=self.get_base_dir())
+relative_url = request.path[len(self.base_url[2]):]
+return serve(request, relative_url, document_root=self.get_base_dir())
 
 
 class LiveServerThread(threading.Thread):

-- 
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] #17469: `StartProject.test_custom_project_template_from_tarball_by_url` fails under Windows

2012-02-01 Thread Django 
#17469: `StartProject.test_custom_project_template_from_tarball_by_url` fails 
under
Windows
-+-
 Reporter:  aaugustin|Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:
  commands)  |  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 In [17417]:
 {{{
 #!CommitTicketReference repository="" revision="17417"
 Improved the fix of r17416 so it actually works on all platforms. Refs
 #17469.
 }}}

-- 
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] #16682: KeyboardInterrupt not handled properly in transaction aborting

2012-02-01 Thread Django 
#16682: KeyboardInterrupt not handled properly in transaction aborting
-+-
 Reporter:  mtredinnick  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 I eventually found a trick to generate the !KeyboardInterrupt to create a
 failing test. Don't ask me why the os.kill has to be called twice...

-- 
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] r17416 - django/trunk/django/test

2012-02-01 Thread noreply 
Author: aaugustin
Date: 2012-02-01 12:08:10 -0800 (Wed, 01 Feb 2012)
New Revision: 17416

Modified:
   django/trunk/django/test/testcases.py
Log:
Fixed #17469 -- Prevented a double URL-to-filesystem path translation in the 
media handler of LiveServerTestCase, which led to infinite redirection loops 
under Windows and test failures.

Modified: django/trunk/django/test/testcases.py
===
--- django/trunk/django/test/testcases.py   2012-02-01 04:25:30 UTC (rev 
17415)
+++ django/trunk/django/test/testcases.py   2012-02-01 20:08:10 UTC (rev 
17416)
@@ -998,7 +998,7 @@
 return settings.MEDIA_URL
 
 def serve(self, request):
-return serve(request, self.file_path(request.path),
+return serve(request, request.path,
 document_root=self.get_base_dir())
 
 

-- 
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] #17469: `StartProject.test_custom_project_template_from_tarball_by_url` fails under Windows

2012-02-01 Thread Django 
#17469: `StartProject.test_custom_project_template_from_tarball_by_url` fails 
under
Windows
-+-
 Reporter:  aaugustin|Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:
  commands)  |  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17416]:
 {{{
 #!CommitTicketReference repository="" revision="17416"
 Fixed #17469 -- Prevented a double URL-to-filesystem path translation in
 the media handler of LiveServerTestCase, which led to infinite redirection
 loops under Windows and test failures.
 }}}

-- 
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] #17626: Update FAQ for Py3k status

2012-02-01 Thread Django 
#17626: Update FAQ for Py3k status
-+
   Reporter:  Alex   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Documentation  |Version:  SVN
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 https://docs.djangoproject.com/en/1.3/faq/install/#can-i-use-django-with-
 python-3 is no longer particularly up to date, with the creation of the
 py3k branch, it should be updated.

-- 
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] #17624: Transaction committed on user abort

2012-02-01 Thread Django 
#17624: Transaction committed on user abort
-+-
 Reporter:  galund   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 This is a duplicate of #16682

-- 
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] #16682: KeyboardInterrupt not handled properly in transaction aborting

2012-02-01 Thread Django 
#16682: KeyboardInterrupt not handled properly in transaction aborting
-+-
 Reporter:  mtredinnick  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by claudep):

 #17624 is a duplicate with a patch

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16682: KeyboardInterrupt not handled properly in transaction aborting

2012-02-01 Thread Django 
#16682: KeyboardInterrupt not handled properly in transaction aborting
-+-
 Reporter:  mtredinnick  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * status:  closed => reopened
 * resolution:  needsinfo =>
 * stage:  Unreviewed => Accepted


Comment:

 I've been able to reproduce it with the following code (you can insert it
 in regressiontests/transactions_regress/tests.py):

 {{{
 def test_rollback_on_keyboardinterrupt(self):
 import time
 try:
 with transaction.commit_on_success():
 Mod.objects.create(fld=17624)
 print "Hit Ctrl-C now!"
 time.sleep(5)
 print "Too late, and I didn't bother to return a
 HttpResponse"
 except KeyboardInterrupt:
 pass
 self.assertEqual(Mod.objects.all().count(), 0)
 }}}

 Unfortunately, I didn't manage to simulate a Ctrl-C programmatically, so
 as to be able to include a real test. Ideas welcome.

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

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

2012-02-01 Thread Django 
#13914: Add natural keys to contrib.auth.User and Group models
-+-
 Reporter:  jbochi   |Owner:  aaugustin
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  Contrib, Auth,   | Triage Stage:  Ready for
  User, Group, natural keys  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by charettes):

 Replying to [comment:25 gcc]:
 > Users can retrofit this, without modifying Django source, using the
 following monkey patch:
 >
 > {{{
 >
 > from django.contrib.auth import models as auth_models
 > from django.db import models as db_models
 > class GroupManagerWithNaturalKey(db_models.Manager):
 > def get_by_natural_key(self, name):
 > return self.get(name=name)
 > auth_models.Group.objects = GroupManagerWithNaturalKey()
 > def group_natural_key(self):
 > return (self.name)
 > auth_models.Group.natural_key = group_natural_key
 > }}}
 I think you might want to return a tuple in {{{ group_natural_key }}}.
 {{{
 def group_natural_key(self):
 return (self.name,)
 }}}

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

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

2012-02-01 Thread Django 
#13914: Add natural keys to contrib.auth.User and Group models
-+-
 Reporter:  jbochi   |Owner:  aaugustin
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  Contrib, Auth,   | Triage Stage:  Ready for
  User, Group, natural keys  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gcc):

 Users can retrofit this, without modifying Django source, using the
 following monkey patch:

 {{{

 from django.contrib.auth import models as auth_models
 from django.db import models as db_models
 class GroupManagerWithNaturalKey(db_models.Manager):
 def get_by_natural_key(self, name):
 return self.get(name=name)
 auth_models.Group.objects = GroupManagerWithNaturalKey()
 def group_natural_key(self):
 return (self.name)
 auth_models.Group.natural_key = group_natural_key
 }}}

-- 
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] #13914: Add natural keys to contrib.auth.User and Group models

2012-02-01 Thread Django 
#13914: Add natural keys to contrib.auth.User and Group models
-+-
 Reporter:  jbochi   |Owner:  aaugustin
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  Contrib, Auth,   | Triage Stage:  Ready for
  User, Group, natural keys  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by gcc):

 * cc: chris+django@… (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] #11739: ContentFile() does not support unicode data

2012-02-01 Thread Django 
#11739: ContentFile() does not support unicode data
--+
 Reporter:  adamnelson|Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  File uploads/storage  |  Version:  1.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 While thinking about this, I had an idea of a third way to workaround this
 unicode problem, which should always use the fastest StringIO available.
 Naming might not be accurate, but at least you get the idea.

-- 
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] #17625: Management command docs should mention underscore prefix

2012-02-01 Thread Django 
#17625: Management command docs should mention underscore prefix
---+-
 Reporter:  murphyke   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.4-alpha-1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+-
 The documentation for custom management commands should mention how to
 exclude source files from being listed or used as management commands.
 I've confirmed that the dev docs do not mention this.

 Looking at the (1.3) source code for django.core.management, I see that
 files prefixed with underscores ("_") are ignored or prevented from being
 considered as management commands.

 Being able to do so is occasionally important, as when several commands
 depend on a helper class.

 Reference: https://docs.djangoproject.com/en/dev/howto/custom-management-
 commands/

-- 
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] #17621: django.utils.translation.activate() issue

2012-02-01 Thread Django 
#17621: django.utils.translation.activate() issue
-+-
 Reporter:   |Owner:  nobody
  tomasz.zawadzinski@…   |   Status:  closed
 Type:  Bug  |  Version:  1.3
Component:   |   Resolution:
  Internationalization   |  worksforme
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 This is exactly the reason why `ugettext_lazy` exists :)

 https://docs.djangoproject.com/en/dev/topics/i18n/translation/#lazy-
 translation

-- 
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] #17621: django.utils.translation.activate() issue

2012-02-01 Thread Django 
#17621: django.utils.translation.activate() issue
-+-
 Reporter:   |Owner:  nobody
  tomasz.zawadzinski@…   |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:   |   Resolution:
  Internationalization   | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 I'm sorry, everything is fine using ugettext_lazy. I don't know if this
 problem is worth solving anymore.

 code looked like this (other strings were translated properly, these in
 templates and other helping functions):


 {{{

 from django.utils.translation import ugettext as _

 class BookingForm(forms.Form):
name = forms.CharField(max_length=25, label=_(u'Imię'),
 error_messages={'required': _(u'Proszę wpisać imię.')})
[...]

 def index(request, lang=''):
if lang == 'en':
   translation.activate('en')
elif lang == 'pl':
   translation.activate('pl')

c = {'form': BookingForm()}
[...]
 }}}

-- 
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] #6623: commit_manually decorator: Better error message (show exception)

2012-02-01 Thread Django 
#6623: commit_manually decorator: Better error message (show exception)
-+-
 Reporter:  guettli  |Owner:  jacob
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by umbrae@…):

 * ui_ux:   => 0


Comment:

 Just a "me, too" here. This is a serious issue for us on our high-volume
 production site at Readability.

-- 
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] #17624: Transaction committed on user abort

2012-02-01 Thread Django 
#17624: Transaction committed on user abort
-+-
 Reporter:  galund   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by galund):

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


Comment:

 So here's my patch. Reproducing this bug is difficult: about 50% of runs
 of my code, I found that `exc_value` was set - the rest of the time, the
 transaction was getting committed due to this bug.

 This patch is no good if it is considered that Transaction is part of the
 public API, i.e. if anyone else might have defined their own decorators
 for some other kind of behaviour. Which seems unlikely to me, but clearly
 other ways of fixing this are possible.

-- 
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] #17624: Transaction committed on user abort

2012-02-01 Thread Django 
#17624: Transaction committed on user abort
--+
 Reporter:  galund|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 If the user aborts execution of some code (e.g. with Control+C), any
 ongoing transaction is committed, rather than rolled back. This is in
 Python 2.5, I suspect later versions could be different.

 {{{
 from __future__ import with_statement
 from django.db import transaction
 with transaction.commit_on_success():
  for x in xx:
   # long loop
 }}}

 If an "normal" exception is raised during the long loop, the transaction
 aborts correctly.

 However, if the user presses Control+C (very possible during a management
 command), the half-finished transaction is committed.

 The reason is that the Transaction's
 
[https://code.djangoproject.com/browser/django/trunk/django/db/transaction.py#L202
 __exit__ method] only passes on exc_value, but not exc_type.

 At least in Python 2.5, exc_type can be set, whilst exc_value is still
 None.

 {{{
 (Pdb) exc_type
 
 (Pdb) exc_value
 (Pdb) exc_value is None
 True
 }}}

 This is really confusing, and I'd certainly hope it got fixed in a later
 version of Python.

 From a brief look at the code it looks like rather than pass on exc_value
 to the `exiting` function, we could just pass on a Boolean success flag,
 based on whether any of the three `__exit__` parameters were set. I'll try
 and work up a patch today.

-- 
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] #17621: django.utils.translation.activate() issue

2012-02-01 Thread Django 
#17621: django.utils.translation.activate() issue
-+-
 Reporter:   |Owner:  nobody
  tomasz.zawadzinski@…   |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:   |   Resolution:
  Internationalization   | Triage Stage:
 Severity:  Normal   |  Unreviewed
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


Comment:

 Please provide us with real code so as we can judge if the problem is in
 Django or on your side. Did you use ugettext_lazy to mark form class
 strings for translation?

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