date:20130702

Re: [Django] #17270: methods of the manager on subqueries QuerySet objects

2013-07-02 Thread Django

#17270: methods of the manager on subqueries QuerySet objects
-+-
 Reporter:  Wojciech Banaś   |Owner:  fizista@…
  |   Status:  closed
 Type:  New feature  |  Version:  master
Component:  Database layer   |   Resolution:  duplicate
  (models, ORM)  | Triage Stage:
 Severity:  Normal   |  Someday/Maybe
 Keywords:  queryset manager |  Needs documentation:  1
  Extends|  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by akaariai):

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


Comment:

 I am closing this as duplicate of #20625 - that ticket has more momentum
 than this one.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/091.747f9fc6c8ddbe9a0bb3544f73503ed4%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20625: Custom Chainable QuerySets

2013-07-02 Thread Django

Comment (by akaariai):

Yes, I like the smart defaults idea more than opt-in.

The only ugly case in the as_manager() approach seems to be that if you
want manager-only methods you will need to create a Manager class, and
then use MyQuerySet.as_manager(base_cls=MyManager) (or alternatively
subclass MyQuerySet.manager_cls()). This isn't as-pretty-as-possible. But,
in general having methods on the qs even if they only make sense as
manager methods isn't too bad. Django has multiple examples of this,
qs.create() doesn't actually make sense, but the create on qs doesn't hurt
anybody either.

I am sure that if one defines the same method on both the qs and the
manager in complex enough ways you can break super(). This seems to be a
case of "don't do that".

I think it is now the time to complete the 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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.98f43c92fdefd6858a85368eec14a4fe%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20687: Document that the max_age argument of TimeStampSigner.unsign should be a number of seconds

2013-07-02 Thread Django

#20687: Document that the max_age argument of TimeStampSigner.unsign should be a
number of seconds
--+
 Reporter:  bmispelon |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Elvard):

 * cc: tomas.ehrlich@… (added)
 * has_patch:  0 => 1


Comment:

 I was looking for it this morning. Added documentation for signing data
 structures too (wasn't mentioned, it uses TimestampSigner neither).

 https://github.com/django/django/pull/1323

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.64391e67659d83fbedb91203d12d5a6e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by shai):

 (comment:16 is me, of course).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.2f400d6b2b2e6795375c2ca0973e1981%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

Comment (by anonymous):

Having slept about it,

(a) I concede that the implicit conversion should not be encouraged, and
(b) I agree that a special marker would be, essentially, interface cruft
that we would keep just for the benefit of something we don't really want.

But backwards compatibility still is a problem; I suggest to solve it with
a deprecation cycle. Given (a) above, I think even an expedited cycle may
be enough.

So,

Django 1.7:
`{'attr':True}` becomes `attr="True"`, with `DeprecationWarning('The
meaning of Boolean values for widget attributes will change in Django
1.8')`
Django 1.8:
`{'attr':True}` becomes `attr`

What do you think?

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/080.aabb8860d997def5930accb2741f74f3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20625: Custom Chainable QuerySets

2013-07-02 Thread Django

#20625: Custom Chainable QuerySets
-+-
 Reporter:  danols   |Owner:  loic84
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  QuerySet,|  Needs documentation:  1
  models.Manager, chainable  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by loic84):

 @akaariai: I'm glad you presented this idea; I find `as_manager()` very
 elegant as it removes all the boilerplate from `Manager` while remaining
 backward compatible, it's probably more efficient as well.

 Its semantic is already used throughout Django (`View.as_view()`,
 `Form.as_p()`, etc.) so people should feel right at home.

 Regarding the copy logic, I see you've used the "opt in" strategy from my
 initial patch, as per @danols' suggestion I like better the "opt out with
 smart defaults" one.

 I had a stab at it:
 https://github.com/loic/django/compare/loic:ticket20625_copy

 {{{
 class MyQuerySet(models.QuerySet):
 # Private methods are ignored by default.
 def _foo(self):
 return ...

 # Public methods are copied by default.
 def foo(self):
 return ...

 # Opt in.
 def _bar(self):
 return ...
 _bar.manager = True

 # Opt out.
 def bar(self):
 return ...
 bar.manager = False

 class MyModel(Model):
 objects = MyQuerySet.as_manager()
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.4f7b6fe5138acd69c6a5e2dd3517d8e8%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20694: Non-ascii unicode characters considered invalid in username

2013-07-02 Thread Django

#20694: Non-ascii unicode characters considered invalid in username
---+--
 Reporter:  akhayyat@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by akhayyat@…):

 I am unaware of any Django policies, but the non-ASCII username works fine
 as a slug in a URL for me even without this patch.

 The user change form is the only piece I have encountered so far that does
 not work well with non-ASCII characters.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.180ae594f570deaf263d569dde4bfd1b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20694: Non-ascii unicode characters considered invalid in username

2013-07-02 Thread Django

#20694: Non-ascii unicode characters considered invalid in username
---+--
 Reporter:  akhayyat@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by hirokiky):

 * cc: hirokiky@… (added)
 * needs_docs:   => 1
 * needs_tests:   => 1
 * needs_better_patch:   => 0


Comment:

 I sometime use the username as some slugs on URL, like:

 {{{
 http://myservice.co.jp/username/
 }}}

 If the username allow to use Unicode, we will have to use Unicode in the
 URL.
 Non-ASCII url is not allowed on Django, I remember so.

 Either allowed or not, this patch should contain some tests and 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/076.18710ac2591398de8d43c8fd6deebb6d%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20694: Non-ascii unicode characters considered invalid in username

2013-07-02 Thread Django

#20694: Non-ascii unicode characters considered invalid in username
---+
 Reporter:  akhayyat@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  contrib.auth   |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 In the admin's user change form, entering a new username with non-ascii
 unicode characters, e.g. é or ع, and saving the form results in an "Enter
 a valid username" error message.

 The model field accepts such usernames programmatically, but editing a
 form with such a username prevents saving it unless the username is
 changed to remove all non-ascii characters.

 This pull request fixes the problem, and allows saving the form with non-
 ascii unicode characters in the username field:

 https://github.com/django/django/pull/1322

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.865645dfd4a0a5fc4440b80293994f12%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20625: Custom Chainable QuerySets

2013-07-02 Thread Django

#20625: Custom Chainable QuerySets
-+-
 Reporter:  danols   |Owner:  loic84
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  QuerySet,|  Needs documentation:  1
  models.Manager, chainable  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by akaariai):

 Sorry for the Django super() requirement confusion.

 While writing my previous post I got an idea. I did some quick testing and
 it seems the idea needs to be presented. There are two key things in the
 idea:
   - Managers are created by CustomQuerySet.manager_cls() method - this is
 a factory constructing a new manager class.
   - The new manager class has dynamically created proxy methods for those
 methods in the CustomQuerySet that should be present in the manager.

 So, you could do something like this:
 {{{
 class MyQuerySet(models.QuerySet):
 def bar(self):
 return ...
 bar.manager = True

 class MyModel(Model):
 objects = MyQuerySet.as_manager()
 }}}

 Now, MyModel.objects is a custom Manager subclass which has a proxy method
 for bar(). And it really *has the method*, so super() works correctly.

 The API might not be optimal, but the idea that proxy methods are
 automatically created on dynamically created Manager classes should be
 considered carefully. In my opinion it offers better semantics than the
 `__getattr__` based approach.

 I wrote a very quick proof-of-concept patch. It is available from:
 https://github.com/akaariai/django/tree/manager_factory. The only
 interesting part of the patch is the method at
 
https://github.com/akaariai/django/commit/283af213d1873cefd642b6d9aeb97f285ef227c4#L2R44

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.5eada20e908b957945484457bc992c53%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20625: Custom Chainable QuerySets

2013-07-02 Thread Django

#20625: Custom Chainable QuerySets
-+-
 Reporter:  danols   |Owner:  loic84
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  QuerySet,|  Needs documentation:  1
  models.Manager, chainable  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by loic84):

 @akaariai: I agree with the all or nothing stance regarding the method
 deprecation, and I also agree that the maintenance burden is rather small.

 Just a clarification, Django itself doesn't need the calls to `super()`,
 the problem is backward compatibility.

 I'll tackle docs and tests tomorrow, hopefully we'll have an RFC patch
 pretty soon.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.ab52161d860c1443829a6a004523d7f9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20429: Add QuerySet.update_or_create method

2013-07-02 Thread Django

#20429: Add QuerySet.update_or_create method
-+-
 Reporter:  tunixman |Owner:
 Type:  New feature  |  elektrrrus
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by tunixman):

 Can you take me off this ticket then? I'm through and don't need the
 notifications about it anymore.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7f5bfb048592013dc3d256f2ada98777%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20429: Add QuerySet.update_or_create method

2013-07-02 Thread Django

* stage: Accepted => Ready for checkin

Comment:

Replying to [comment:26 tunixman]:
> I strongly think Django should be choosing the non-race-condition
approach with loud and immediate errors rather than the race-condition
approach with no errors at the time of corruption, but loud and opaque
errors much later.

I'm not sure I understand how you would do that. If you are referring to
the backend specific upsert, it could be added in the future.

@timo: Left a comment on the PR, other than that I'm happy with the
current 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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.47c19e6b4fece7119d66898006f2c76a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20691: Documentation for "Choosing between str() and unicode()" is written for Python2 specifically

2013-07-02 Thread Django

#20691: Documentation for "Choosing between __str__() and __unicode__()" is 
written
for Python2 specifically
--+
 Reporter:  garrison  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 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
--+
Changes (by timo):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.4f9bf27ec37cd552218a2edec700f7f2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20691: Documentation for "Choosing between str() and unicode()" is written for Python2 specifically

2013-07-02 Thread Django

#20691: Documentation for "Choosing between __str__() and __unicode__()" is 
written
for Python2 specifically
--+
 Reporter:  garrison  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * needs_better_patch:  0 => 1


Comment:

 I think I would have written a note at the start of the subsection: `If
 you are on Python 3, you can skip this section because you'll always
 create __str__()...`. This can prevent a Python 3 user to read the
 paragraph just to finally realize that he's not concerned.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.b7f7d338e49f8cb7a6330b906dff0f6a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20673: Clarify that HttpRequest.user uses AUTH_USER_MODEL (was: Improve HttpRequest.user documentation)

2013-07-02 Thread Django

#20673: Clarify that HttpRequest.user uses AUTH_USER_MODEL
--+
 Reporter:  littlepig |Owner:  susan
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.5
 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
--+

Comment (by timo):

 Susan, the problem is that the docs say that a
 `django.contrib.auth.models.User` object is returned, but with the
 introduction of custom user models, that may no longer be true.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2bcb06b0d0e40ff515d138c8bc80b476%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20625: Custom Chainable QuerySets

2013-07-02 Thread Django

#20625: Custom Chainable QuerySets
-+-
 Reporter:  danols   |Owner:  loic84
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  QuerySet,|  Needs documentation:  1
  models.Manager, chainable  |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by akaariai):

 I have tried various versions of making Manager a subclass of QuerySet.
 The most promising approach was to use a temporary class for hiding
 QuerySet only functionality from the manager, and drop the temp class on
 first clone. So:
   1. On creation of manager, create a dynamic class and add
 HideQuerySetMethods to the `__bases__` of the dynamic class. Effect is
 that for example .delete() calls HideQuerySetMethods.delete(), not
 QuerySet.delete().
   2. On first clone, switch the class to the original class, that is drop
 the HideQuerySetMethods class from `__bases__`.

 I got the solution to almost working state, but it required too many
 kluges. I ended up deleting the branch as there was just too many little
 problems to make it work cleanly.


 I have seen the idea of this ticket discussed multiple times. Every time
 some solutions are offered, but the solutions always have some problematic
 cases that end up stalling the development effort. I think the solution in
 this ticket is clean, and makes it easy enough to add queryset methods.
 So, my opinion is that we should go forward with it.

 I wouldn't actually remove the proxy methods at all. Removing them doesn't
 seem worth the effort, the maintenance burden of the methods is very
 small. If they are going to be removed, then all must be removed in one
 go. It is just weird if some of the proxy methods are still there because
 Django needs the super() method to be present, but other are removed.

 It seems #17270 is a duplicate, I guess that one could be closed as this
 ticket seems to have more momentum 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.d1898c9feb4097414f006674632832e0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by claudep):

 I can see the point of Shai, but I'd tend to agree with the boolean
 version also.

 We are not in a hurry though, so let's see if others have strong opinions
 about 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.75ca269a1e4b0a136070ff689e50eca7%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20693: Add timezone support to built-in time template filter

2013-07-02 Thread Django

#20693: Add timezone support to built-in time template filter
-+--
 Reporter:  warren@… |Owner:  wsmith323
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by wsmith323):

 I have the code modified. I'm working on adding tests and tweaking the
 documentation.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/079.f59f2e864068283ae5b9349bbfd60cbf%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20693: Add timezone support to built-in time template filter

2013-07-02 Thread Django

#20693: Add timezone support to built-in time template filter
-+--
 Reporter:  warren@… |Owner:  wsmith323
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  1.5
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by wsmith323):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * owner:  nobody => wsmith323
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/079.b799dd30ef109d8733b5ad4d4ac0fdce%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20693: Add timezone support to built-in time template filter

2013-07-02 Thread Django

#20693: Add timezone support to built-in time template filter
-+
 Reporter:  warren@… |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Template system  |Version:  1.5
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Currently, the built-in time template filter does not support timezone,
 even if timezone information is present on the time or datetime object
 that is passed to it.

 The built-in date filter DOES support timezone if passed a datetime
 object, so this is often used as a workaround. However, when attempting to
 use the DATE_FORMAT and TIME_FORMAT settings in conjunction with naked {{
 value|date }} and {{ value|time }} template expressions to get consistent
 date and time formatting across a site, the lack of timezone support in
 the time filter is a problem if timezone information needs to be displayed
 after the time.

 There is a discussion of this issue on the Django Developers list:
 https://groups.google.com/forum/#!topic/django-developers/r-7dMZROTs4

 The consensus so far seems to be to modify the
 django.utils.dateformat.TimeFormat class so that it has similar timezone
 support for datetime objects as does the DateFormat class in the same
 module. Since DateFormat is a subclass of TimeFormat, it is likely that
 the timezone support methods can just be moved from DateFormat into
 TimeFormat, along with the __init__() method.

 Some modification to the methods will need to occur to account for the
 case where a time object (not a datetime object) is passed to a filter
 with a timezone-related format specifier. It was decided in the discussion
 that the behavior in this case should be that the format method will
 return an empty string.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.2984f84933c1c22f162fc249b1c27f52%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18134: BoundField.label_tag should include form.label_suffix

2013-07-02 Thread Django

#18134: BoundField.label_tag should include form.label_suffix
-+-
 Reporter:  Evil Clay|Owner:
|  gabejackson
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Forms|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  forms|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Tim Graham ):

 In [changeset:"5ecdf0eb9ccd47c102deb873a242ed40d1cf45cd"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5ecdf0eb9ccd47c102deb873a242ed40d1cf45cd"
 [1.6.x] A couple more semicolon -> colon fixes; refs #18134.

 Backport of 3632d289de from master.
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/089.9c24272bf512a17714defd742fb271ae%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 5ecdf0: [1.6.x] A couple more semicolon -> colon fixes; re...

2013-07-02 Thread GitHub

  Branch: refs/heads/stable/1.6.x
  Home:   https://github.com/django/django
  Commit: 5ecdf0eb9ccd47c102deb873a242ed40d1cf45cd
  
https://github.com/django/django/commit/5ecdf0eb9ccd47c102deb873a242ed40d1cf45cd
  Author: Tim Graham 
  Date:   2013-07-02 (Tue, 02 Jul 2013)

  Changed paths:
M docs/ref/forms/api.txt
M docs/releases/1.6.txt
M docs/topics/forms/index.txt

  Log Message:
  ---
  [1.6.x] A couple more semicolon -> colon fixes; refs #18134.

Backport of 3632d289de from master.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/51d3190591dfb_79eb603de45016d%40hookshot-fe1-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #18134: BoundField.label_tag should include form.label_suffix

2013-07-02 Thread Django

#18134: BoundField.label_tag should include form.label_suffix
-+-
 Reporter:  Evil Clay|Owner:
|  gabejackson
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.4
Component:  Forms|   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  forms|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Tim Graham ):

 In [changeset:"3632d289dedc2e83cde1976e5a4cd00b08c799ee"]:
 {{{
 #!CommitTicketReference repository=""
 revision="3632d289dedc2e83cde1976e5a4cd00b08c799ee"
 A couple more semicolon -> colon fixes; refs #18134.
 }}}

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/089.1d6715e5b3db41d8d66ebee32b69da32%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 3632d2: A couple more semicolon -> colon fixes; refs #1813...

2013-07-02 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 3632d289dedc2e83cde1976e5a4cd00b08c799ee
  
https://github.com/django/django/commit/3632d289dedc2e83cde1976e5a4cd00b08c799ee
  Author: Tim Graham 
  Date:   2013-07-02 (Tue, 02 Jul 2013)

  Changed paths:
M docs/ref/forms/api.txt
M docs/releases/1.6.txt

  Log Message:
  ---
  A couple more semicolon -> colon fixes; refs #18134.



-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/51d318c3713d_2bb5fb3de46258c%40hookshot-fe3-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20692: Wrong italian translation

2013-07-02 Thread Django

#20692: Wrong italian translation
-+-
 Reporter:  marina.gerace@…  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Translations |  Version:  1.5
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  wrong italian| Triage Stage:
  translation|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 Translation fixes are handled at [https://www.transifex.com/projects/p
 /django-core/ Transifex] not via this ticket tracker, 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/081.13ac1cac9f92ba6412f93933e2e7828f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[django/django] 8160e6: Fix "semicolon" in docs

2013-07-02 Thread GitHub

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 8160e6341d160607f7898ea4a9c389e84d547763
  
https://github.com/django/django/commit/8160e6341d160607f7898ea4a9c389e84d547763
  Author: Ben Firshman 
  Date:   2013-07-02 (Tue, 02 Jul 2013)

  Changed paths:
M docs/topics/forms/index.txt

  Log Message:
  ---
  Fix "semicolon" in docs


  Commit: ddf9ced5bc542c9ca9146450df752ed8ccdccc5f
  
https://github.com/django/django/commit/ddf9ced5bc542c9ca9146450df752ed8ccdccc5f
  Author: Preston Holmes 
  Date:   2013-07-02 (Tue, 02 Jul 2013)

  Changed paths:
M docs/topics/forms/index.txt

  Log Message:
  ---
  Merge pull request #1321 from bfirsh/semicolon-colon-docs

Fix "semicolon" in form docs


Compare: https://github.com/django/django/compare/6c66a41c3dc6...ddf9ced5bc54

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/51d317226ba52_434b7b7dd412125%40hookshot-fe4-pe1-prd.aws.github.net.mail.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20692: Wrong italian translation

2013-07-02 Thread Django

#20692: Wrong italian translation
-+---
 Reporter:  marina.gerace@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Translations |Version:  1.5
 Severity:  Normal   |   Keywords:  wrong italian translation
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+---
 In django/conf/locale/it/LC_MESSAGES/django.po there is an incorrect
 translation in row 380 and in row 397.
 The wrong translation is the word "Assicuratii" :
 380msgstr "Assicuratii che questo valore sia maggiore o uguale a
 %(limit_value)s."
 397"Assicuratii che questo valore non contenga più di %(limit_value)d
 caratteri "

 You need to replace the word "Assicuratii" with "Assicurati" (only one
 'i')

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.456a8c7ea9790cfac19e81f4e6c17f16%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20649: Add an easier way to override the blank option for CharFields with choices

2013-07-02 Thread Django

#20649: Add an easier way to override the blank option for CharFields with 
choices
-+--
 Reporter:  brillgen |Owner:  alexcouper
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by alexcouper):

 @timo - I prefer that approach too.

 The {{{empty_label}}} option felt wrong while I was implementing it TBH.

 I'll be away for the next week or so but after that I'll amend my fix
 (unless I'm beaten to it by someone else).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.6b322f68b46ba5a0bfc08112e14d46e6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by shai):

 I don't feel very strongly about this, but I'm also not convinced. In my
 opinion, we shouldn't make code stop working unless it's required to fix a
 bug, or the code that gets broken can be seen as a bug. IMO, this feature
 is not important enough, and the implicit conversion is not buggy enough,
 to justify a breaking change.

 But maybe that's just 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.cb1e2bb6873063ab808cdc5edae32b3b%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

Comment (by charettes):

Replying to [comment:11 loic84]:
> A special marker is a bit overkill IMO and it's not exactly convenient
since you have to import it before using it.
It is also overkill IMO. W3 defined the semantic of boolean attributes and
I think we should try to stick to it. As pointed out by @loic84 a release
note concerning backward compatibility should be enough.

Replying to [comment:12 loic84]:
> Because explicit is better than implicit, people who really want
`"True"` should cast the boolean to a string.
Agreed that `True` -> `"True"` implicit conversion is not a pattern we
should encourage.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/080.76fead864189667238a2c1ba265d5010%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20429: Add QuerySet.update_or_create method

2013-07-02 Thread Django

Comment (by tunixman):

Race conditions are conditions that silently accept corruption, so
database constraints are the exact opposite of race conditions. They
inform the programmer that data integrity was preserved, rather than
silently corrupting it. Dealing with those exceptions at that point
properly is the right thing, because it prevents having to go through the
database much later trying to understand why there are duplicates of some
rows but not others, and why there are other more opaque exceptions (like
.get() failing), or why relations to one item are actually to several
different items. Those are race conditions, but loudly saying "I'm sorry I
can't corrupt your data for you" is not a race condition, and I strongly
think Django should be choosing the non-race-condition approach with loud
and immediate errors rather than the race-condition approach with no
errors at the time of corruption, but loud and opaque errors much later.

--
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 unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.b96237d4b7895b0833774a8342b130ff%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by loic84):

 Replying to [comment:11 shai]:
 > Replying to [comment:10 loic84]:
 > >
 > > Also relying on the implicit conversion of `True` to `"True"` is not a
 pattern we should encourage,
 >
 > Why not? Especially in `data-` attributes?
 Because explicit is better than implicit, people who really want `"True"`
 should cast the boolean to a string.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.90b8333fa30c9466dcf9589b8f28150c%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by shai):

 Replying to [comment:10 loic84]:
 >
 > Also relying on the implicit conversion of `True` to `"True"` is not a
 pattern we should encourage,

 Why not? Especially in `data-` attributes?

 > we could list the change as backward incompatible in the release notes.
 >
 Yes, but exactly because of the `"required": is_required()` pattern you
 brought up, uses may be hard to detect.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.d8717f8e3a6583137245b1d6c08af767%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by loic84):

 A special marker is a bit overkill IMO and it's not exactly convenient
 since you have to import it before using it.

 Also relying on the implicit conversion of `True` to `"True"` is not a
 pattern we should encourage, we could list the change as backward
 incompatible in the release notes.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.fc0a92aa7ff7fa60fc35159a0181e926%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #6785: QuerySet.get() should only attempt to fetch a limited number of rows

2013-07-02 Thread Django

#6785: QuerySet.get() should only attempt to fetch a limited number of rows
-+-
 Reporter:  deadwisdom   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
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:  0|
Easy pickings:  0|
-+-
Changes (by timo):

 * status:  closed => new
 * needs_better_patch:  1 => 0
 * resolution:  wontfix =>


Comment:

 Updated pull request based on django-developers discussion:
 https://github.com/django/django/pull/1320

 I'm not sure it needs docs or a mention in the release notes, but happy to
 add them if necessary.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.76adf2d3e34109606520d62c480b0fcf%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by shai):

 * cc: shai@… (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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.612a46ce5c39530823f67448363c2bb8%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by shai):

 Yes, this makes a lot of sense; the reason I suggested a special marker is
 backwards-compatibility -- if code exists which relies on the value being
 converted to string, and so expects that attr=True will manifest in HTML
 as `attr="True"`, this may very well break it.

 I still find it preferable to use a special marker -- but I guess
 `NoValue` is a bad 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.394f5765a8a8f672a0cf40aea560d46a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20691: Documentation for "Choosing between str() and unicode()" is written for Python2 specifically

2013-07-02 Thread Django

#20691: Documentation for "Choosing between __str__() and __unicode__()" is 
written
for Python2 specifically
--+
 Reporter:  garrison  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 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
--+
Changes (by timo):

 * cc: timograham@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.5 => master
 * needs_docs:   => 0
 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.6dffa63f701f011622babcd8a07bdab5%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by loic84):

 Interestingly comments on a feature branch get lost upon forced pushes.

 @charettes wasn't convinced that the `False` value was necessary.

 I brought up the use case of setting the value programmatically with an
 expression like `'required': is_required()` and we agreed that it could be
 useful.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.9b90610cb0fe06495df16324238f6431%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20685: Document options to install Python 2.7 on RHEL 6

2013-07-02 Thread Django

#20685: Document options to install Python 2.7 on RHEL 6
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Documentation|   Resolution:
 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
-+-

Comment (by timo):

 This may be appropriate for the
 [https://code.djangoproject.com/wiki/Distributions Distributions] wiki
 page. For example, we could link this
 [http://developerblog.redhat.com/2013/02/14/setting-up-django-and-
 python-2-7-on-red-hat-enterprise-6-the-easy-way/ blog post].

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.b4f71300106a2e68d13fd48dccf6f302%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20691: Documentation for "Choosing between str() and unicode()" is written for Python2 specifically

2013-07-02 Thread Django

#20691: Documentation for "Choosing between __str__() and __unicode__()" is 
written
for Python2 specifically
---+
 Reporter:  garrison   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 At https://docs.djangoproject.com/en/dev/ref/unicode/#choosing-between-
 str-and-unicode it should be mentioned that {{{__str__()}}} is to be used
 instead of {{{__unicode__()}}} in Python3.  And a note about
 
[https://docs.djangoproject.com/en/dev/ref/utils/#django.utils.encoding.python_2_unicode_compatible
 Python2 compatibility for using] {{{__str__()}}} should be provided.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.a03c2d3cab21b9b712e7823e3f74e7e1%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20429: Add QuerySet.update_or_create method

2013-07-02 Thread Django

#20429: Add QuerySet.update_or_create method
-+-
 Reporter:  tunixman |Owner:
 Type:  New feature  |  elektrrrus
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  master
 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 timo):

 I've updated the patch with the documentation suggested by @loic84 and
 also to reflect the fact that this will have to go into 1.7 rather than
 1.6.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.c045b9654565f5e97bce35434b6b5f78%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20690: LOCALE_PATH

2013-07-02 Thread Django

#20690: LOCALE_PATH
---+
 Reporter:  rene@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 [https://docs.djangoproject.com/en/1.5/topics/i18n/translation
 /#localization-how-to-create-language-files This section] ("The script
 should be run from one of two places") should mention that you need to
 configure LOCALE_PATHS if you want Django to search your project directory
 for message files. It's mentioned further down under "implementation
 notes", but a small note further up would be nice for new users, who might
 not read the Implementation notes section.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.b0452aa2f9bca2172264b928823940b4%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20689: Django 1.5.1: severe performance degradation on Oracle

2013-07-02 Thread Django

#20689: Django 1.5.1: severe performance degradation on Oracle
-+-
 Reporter:  zakharov.vv@…|  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Database layer   |Version:  1.5
  (models, ORM)  |   Keywords:  Oracle, cx_oracle,
 Severity:  Normal   |  unicode
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 After migrating to Django 1.5.1, several queries takes thousands times
 more time comparing to Django 1.4.5.

 Example query generated by ORM:
 {{{
 SELECT COUNT(*) FROM "TICKETS" WHERE ("TICKETS"."T_TYPE" IN (:arg0, :arg1,
 :arg2, :arg3) AND "TICKETS"."T_PARTNER_CODE" = :arg4 AND
 "TICKETS"."T_CHANEL" = :arg5 AND "TICKETS"."T_WORKER_CODE" = :arg6 AND
 "TICKETS"."T_CDATE" <= :arg7 AND "TICKETS"."T_CDATE" >= :arg8 )
 }}}

 Django 1.4.5: ~7ms
 Django 1.5.1: ~193574ms (about 27000 times more!)

 `git bisect` points to this commit:
 
https://github.com/django/django/commit/d194f290571f7e9dda7d2fd7a6f2b171120f2f14.
 Indeed, forcing `convert_unicode` to be equal to `force_bytes` solves the
 issue.

 The only found difference is in params to query:
 Django 1.4.5:
 {{{
 [1, 38, 76, 92, '777-61', 61, 'pupkin', '2013-07-03 00:00:00', '2013-06-01
 00:00:00']
 }}}

 Django 1.5.1:
 {{{
 [1, 38, 76, 92, u'777-61', 61, u'pupkin', u'2013-07-03 00:00:00',
 u'2013-06-01 00:00:00']
 }}}

 Django 1.5.1 hangs on this string
 (''django/db/backends/oracle/base.py:710''):
 {{{
 return self.cursor.execute(query,
 self._param_generator(params))
 }}}

 Directly using cx_Oracle for this query shows no difference for two
 variants of query params.

 Used versions:
 * cx-Oracle 5.1.2
 * instantclient 11.2.0.3.0 (same for instantclient 10.2.0.5)
 * Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit
 Production

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.6b6e946567e7ecf455917cf89481f7d5%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by charettes):

 As @claudep initially suggested I would have chosen `None` for that but in
 the light of @shai's comment I think @loic84's approach is the correct
 one.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.9f41e906f0c53d6798c3674c3502a5c9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by loic84):

 * cc: loic@… (added)
 * needs_better_patch:  0 => 1
 * version:  1.5 => master
 * easy:  0 => 1
 * needs_docs:  0 => 1
 * has_patch:  0 => 1


Comment:

 POC: https://github.com/loic/django/compare/ticket20684

 I'll write the docs for it if that's validated.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.a2068041bf18fca4c6439ee3173d8e77%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20649: Add an easier way to override the blank option for CharFields with choices

2013-07-02 Thread Django

#20649: Add an easier way to override the blank option for CharFields with 
choices
-+--
 Reporter:  brillgen |Owner:  alexcouper
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by charettes):

 @timo I see that most of the choice logic is unfortunately already defined
 at the db field level thus you can ignore my last concern.

 You suggested approach should work and is way less invasive.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.36b4c7ca0f9743ea8ee3bfff66e89b61%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9084: File-based session does not store any data on Windows

2013-07-02 Thread Django

#9084: File-based session does not store any data on Windows
-+-
 Reporter:  mizutori |Owner:  joeri
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.5
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sprint2013   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by me21@…):

 In fact, since MoveFileEx API is considered to be atomic (for example,
 Java uses it: http://bugs.python.org/issue8828#msg146307), Django could
 use it through ctypes interface even now (https://github.com/mitsuhiko
 /python-atomicfile/ - _rename() function - and disregard that its author
 believes it to be non-atomic, it seems to be atomic actually). The
 os.replace() function in Python 3.3 is implemented through MoveFileEx
 anyway.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.98b75e371706dc0293d1f5e203244a02%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20649: Add an easier way to override the blank option for CharFields with choices

2013-07-02 Thread Django

#20649: Add an easier way to override the blank option for CharFields with 
choices
-+--
 Reporter:  brillgen |Owner:  alexcouper
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by charettes):

 @timo I also think it would make more sense than an `empty_label` option
 however both alternatives introduce a form specific option at the ORM
 level.

 IMHO this belongs at the form level.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.4ff3d4f7fe3a9e67d97596351efb8d06%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  1.5
 Severity:  Normal|   Resolution:
 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 loic84):

 As Shai pointed out, these *are* booleans
 (http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#boolean-
 attributes), why not treat them as such?

 Value in python should be either True or False, False behing noop in
 `flatatt()`

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.249653dd6ceaaa68b16ba814ff96d92f%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20555: Subwidgets not passed id attribute

2013-07-02 Thread Django

#20555: Subwidgets not passed id attribute
-+---
 Reporter:  mdj2@…   |Owner:  mdj2
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  1.6-alpha-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+---

Comment (by timo):

 The patch looks good to me. Unfortunately, it's too late to add this to
 1.6 (beta marks the feature freeze), but we can commit it to master.

 Would a documentation update be helpful here? For example, in the
 discussion of iterating over RadioSelect choices:
 https://docs.djangoproject.com/en/dev/ref/forms/widgets/#radioselect

 I don't think this is backwards-incompatible, but just want to confirm.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.6a6bb323e052b496396b5a6f2638e302%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  1.5
 Severity:  Normal|   Resolution:
 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 shai):

 Actually, I'd rather use some special marker rather than None -- most such
 attributes are essentially boolean, and None -- which is False when
 evaluated as a boolean -- would come to mark True, and this can be
 confusing.

 I'd introduce a new constant, and call it NoValue -- probably along the
 lines of `class NoValue(object): pass`. Then you could write
 {{{
 widget=forms.TextInput(
 attrs={
 'required': NoValue
 }))
 }}}
 And also have correct behavior on things like `if
 widget.attrs['required']: ...`

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.be0ec7c10820cf980d8b220cc0af0792%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #17001: Allow usage of custom querysets in prefetch_related

2013-07-02 Thread Django

#17001: Allow usage of custom querysets in prefetch_related
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  prefetch_related |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by naktinis@…):

 Would be great to have this! What is the status of this feature request
 currently?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.79dbd18bba54aa9b53675245dc8f09b2%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20663: Admin Now and Today buttons use confusing time / timezone

2013-07-02 Thread Django

#20663: Admin Now and Today buttons use confusing time / timezone
---+-
 Reporter:  imfletcher |Owner:  aaugustin
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by loic84):

 * version:  1.5 => master
 * needs_tests:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.62cf45ad2fffee30d2d1555fac5ae08a%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20688: A suggestion

2013-07-02 Thread Django

#20688: A suggestion
-+-
 Reporter:  Javalangu@…  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:  wontfix
 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 claudep):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Documentation => Database layer (models, ORM)
 * needs_tests:   => 0
 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => New feature


Comment:

 Thanks for the suggestion. However, I'm not sure about the `every site
 needs that model` assertion. There are many ways to build statistics for a
 site, so I think this could be a nice idea for an external Django app (if
 not already existing).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.8a7bfc7a748e0ade6fc0740907ef96d1%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20687: Document that the max_age argument of TimeStampSigner.unsign should be a number of seconds

2013-07-02 Thread Django

#20687: Document that the max_age argument of TimeStampSigner.unsign should be a
number of seconds
--+
 Reporter:  bmispelon |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 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):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.d535d3dc35cc98c44cbced626f024cf0%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19940: Regression: setup_databases in test.simple.DjangoTestSuiteRunner doesn't handle aliases for 'default'

2013-07-02 Thread Django

#19940: Regression: setup_databases in test.simple.DjangoTestSuiteRunner doesn't
handle aliases for 'default'
---+
 Reporter:  simonpercivall |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.5-rc-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timo):

 * needs_tests:  1 => 0


Comment:

 Thanks, I'm not sure if this will be backported to 1.5.x though. Could you
 provide a patch against master (some code/files have been moved around
 there)?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.35f3f4608f8da7f60d0063b65fa6d246%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  1.5
 Severity:  Normal|   Resolution:
 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 claudep):

 * stage:  Unreviewed => Accepted


Comment:

 Agreed. However I'd rather use `None` instead of the empty string to mean
 no attribute value, because there might be cases where an empty value is
 wanted.

 At first sight, this seems rather trivial to implement in `flatatt`
 (https://github.com/django/django/blob/master/django/forms/util.py#L15).

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.a6702f331e4125cfe10b1aa9b69dc189%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20684: Support form element attributes with no value

2013-07-02 Thread Django

#20684: Support form element attributes with no value
--+--
 Reporter:  sneethling@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Forms |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by claudep):

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


Old description:

> There are a couple of form attributes such as required that was
> introduced in HTML5 that should not contain a value. For exaple
> required="required" is valid but for example required="true" will result
> in failed validation with true being marked as a bad value.
>
> The correct use would be:
>
> 
>
> Currently in forms.py attributes cannot be specified without a value
> which rely on the author knowing that a value of 'true' not being valid
> but 'required' being ok. it would be great if Django supports valueless
> attributes.
>
> Perhaps doing:
>
> widget=forms.TextInput(
> attrs={
> 'required': ''
> }))
>
> will result in an input of:
>
> 

New description:

 There are a couple of form attributes such as required that was introduced
 in HTML5 that should not contain a value. For exaple required="required"
 is valid but for example required="true" will result in failed validation
 with true being marked as a bad value.

 The correct use would be:

 {{{}}}

 Currently in forms.py attributes cannot be specified without a value which
 rely on the author knowing that a value of 'true' not being valid but
 'required' being ok. it would be great if Django supports valueless
 attributes.

 Perhaps doing:
 {{{
 widget=forms.TextInput(
 attrs={
 'required': ''
 }))
 }}}
 will result in an input of:

 {{{}}}

--

Comment:

 Description reformatted, please use preview when posting.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/080.5face5e9c9bf7f6ebccc96dae71c3d52%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20649: Add an easier way to override the blank option for CharFields with choices

2013-07-02 Thread Django

#20649: Add an easier way to override the blank option for CharFields with 
choices
-+--
 Reporter:  brillgen |Owner:  alexcouper
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by timo):

 On second thought, rather than `empty_label`, how about doing what the OP
 did and just making sure that the Django blank choice isn't added if a
 blank choice is already defined in `choices`?:

 {{{
 CHOICES = (
 ('', 'Please select one'),
 ('p', 'Python'),
 ('j', 'Java')
 )
 }}}

 Opinions?

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.7738b072933a5f97f14bc6dadafb7bc3%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19940: Regression: setup_databases in test.simple.DjangoTestSuiteRunner doesn't handle aliases for 'default'

2013-07-02 Thread Django

#19940: Regression: setup_databases in test.simple.DjangoTestSuiteRunner doesn't
handle aliases for 'default'
---+
 Reporter:  simonpercivall |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.5-rc-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by simonpercivall):

 New patch that applies on stable/1.5.x, and test case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.9945300793b3b826db0a4287c2ea9021%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20649: Add an easier way to override the blank option for CharFields with choices

2013-07-02 Thread Django

#20649: Add an easier way to override the blank option for CharFields with 
choices
-+--
 Reporter:  brillgen |Owner:  alexcouper
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by alexcouper):

 * needs_docs:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.b7a1f41a53fbb67cc01fcba9afcf855e%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20649: Add an easier way to override the blank option for CharFields with choices

2013-07-02 Thread Django

#20649: Add an easier way to override the blank option for CharFields with 
choices
-+--
 Reporter:  brillgen |Owner:  alexcouper
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 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
-+--
Changes (by alexcouper):

 * cc: info@… (added)
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.159f4f384a61f6371cfe6a1870b94057%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #19940: Regression: setup_databases in test.simple.DjangoTestSuiteRunner doesn't handle aliases for 'default'

2013-07-02 Thread Django

#19940: Regression: setup_databases in test.simple.DjangoTestSuiteRunner doesn't
handle aliases for 'default'
---+
 Reporter:  simonpercivall |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.5-rc-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timo):

 * cc: timograham@… (added)
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 Patch no longer applies cleanly and needs a 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.ace1908bd1d0093a9a5acc67f63b2b69%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20688: A suggestion

2013-07-02 Thread Django

#20688: A suggestion
---+
 Reporter:  Javalangu@…|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.5
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hi...What about creating a built-in model for STATISTICS every site needs
 that model.

 as ADMIN SITE ,also there is a statistics model Just enable it and you
 will be ready for reading your statistics about your site .



 thank you .

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.31cef3eee06d32ff734c7a37786e2af9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Django] #20687: Document that the max_age argument of TimeStampSigner.unsign should be a number of seconds

2013-07-02 Thread Django

#20687: Document that the max_age argument of TimeStampSigner.unsign should be a
number of seconds
--+
 Reporter:  bmispelon |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Core (Other)  |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 Currently, neither the documentation [1] or the code [2] are very explicit
 about what kind of value `max_age` is supposed to receive (a `timedelta`,
 a `datetime`, ...?).

 It's only by looking at the error message that you can guess it's
 expecting seconds.

 [1] https://docs.djangoproject.com/en/dev/topics/signing/#verifying-
 timestamped-values
 [2]
 https://github.com/django/django/blob/master/django/core/signing.py#L185

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.52270794faf9ff74451570ce1378dd50%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20681: teardown_databases tries to tear down aliases, which fails

2013-07-02 Thread Django

#20681: teardown_databases tries to tear down aliases, which fails
---+--
 Reporter:  simonpercivall |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.5
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by simonpercivall):

 Added new patch (more correct, I think), with test case.

 The test won't work until #19940 is fixed, though.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.e6d27ffe3ea7a554ca694f54b7e55fb9%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #9084: File-based session does not store any data on Windows

2013-07-02 Thread Django

#9084: File-based session does not store any data on Windows
-+-
 Reporter:  mizutori |Owner:  joeri
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.5
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sprint2013   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by me21@…):

 A new function is introduced in Python 3.3, os.replace(), which renames
 files atomically and cross-platformly: http://bugs.python.org/issue8828
 It might be possible to use this function in future, when Django support
 for Python 2.x is abandoned, or when os.replace() is (ever) backported to
 Python 2.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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.4157d650e9b328eede05135da218eb80%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #13936: django-admin makemessages generates PO files with an incorrect path to source code files

2013-07-02 Thread Django

#13936: django-admin makemessages generates PO files with an incorrect path to
source code files
-+-
 Reporter:  ciupicri |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.2
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by vslavik@…):

 FIY, [http://www.poedit.net Poedit] will handle this case correctly
 starting with 1.5.6 release. Sorry it took so long to fix on my side.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.41b46d65b4c33a11f58261db4183b0f6%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20609: Document how to use request.user with RequestFactory

2013-07-02 Thread Django

#20609: Document how to use request.user with RequestFactory
--+
 Reporter:  michel@…  |Owner:  susan
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.5
 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
--+

Comment (by susan):

 See https://github.com/django/django/pull/1319/files for PR. I edited the
 given doc patch. Please code review. 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.250c1312b4353913337a29d270b76c41%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #20609: Document how to use request.user with RequestFactory

2013-07-02 Thread Django

#20609: Document how to use request.user with RequestFactory
--+
 Reporter:  michel@…  |Owner:  susan
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.5
 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 susan):

 * status:  new => assigned
 * owner:  nobody => susan


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.4ee76343a5c81c682df93dbf3aec5f15%40djangoproject.com.
For more options, visit https://groups.google.com/groups/opt_out.

72 matches

Mail list logo