[django/django] ea9536: Note that Jython has an alpha with 2.7 support.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ea9536b17fe16b2be45aa4a3552f919682c93e3e
  
https://github.com/django/django/commit/ea9536b17fe16b2be45aa4a3552f919682c93e3e
  Author: Alex Gaynor 
  Date:   2012-06-22 (Fri, 22 Jun 2012)

  Changed paths:
M docs/releases/1.5.txt

  Log Message:
  ---
  Note that Jython has an alpha with 2.7 support.



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

开 心 网携程旅行网中彩网彩票百 姓 网

[apwwcyaa]

dj98188，
联系：13814047108 陈先生  客服QQ :1052491972   
普通(商品.商业.企业.工业)票
 广告业专用票
 建筑安装专用票
 运输专用票
 地税.国税代开票
（所开出票据验证后付款)
   apwwcyaa
   2012-6-23

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

Re: [Django] #18509: Bug: forms.DecimalField doesn't validate correctly when localized. (Unittest attached) (was: Bug: forms.DecimalField doesn't validate correctly when localized. (Unittest))

[Django]

#18509: Bug: forms.DecimalField doesn't validate correctly when localized.
(Unittest attached)
-+--
 Reporter:  serge_spaolonzi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.4
 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 serge_spaolonzi):

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


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

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

[Django] #18509: Bug: forms.DecimalField doesn't validate correctly when localized. (Unittest)

[Django]

#18509: Bug: forms.DecimalField doesn't validate correctly when localized.
(Unittest)
-+
 Reporter:  serge_spaolonzi  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 forms.DecimalField doesn't validate correctly when localized.
 A form DecimalField is expected to validate invalid values when the method
 to python is called.
 It throws a ValidationError for non localized instances when an incorrect
 value is introduced.
 But for localized instances that are expected to accept a comma (,) as
 decimal separator it doesn't throw any exception for a value with a dot
 (.) and take it as valid.

 Unittest attached

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

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

Re: [Django] #17083: sessions.backends.cache does not allow non-default cache to be configured

[Django]

#17083: sessions.backends.cache does not allow non-default cache to be 
configured
--+
 Reporter:  charles@… |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.sessions  |  Version:  master
 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 aptomkins):

 * version:  1.3 => master


Comment:

 Sent a pull request which should allow a custom cache backend -
 https://github.com/django/django/pull/169

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

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

Re: [Django] #18495: 404 with non-/ WSGI, script prefix not removed in core/urlresolvers.py: resolve()

[Django]

#18495: 404 with non-/ WSGI, script prefix not removed in core/urlresolvers.py:
resolve()
-+-
 Reporter:  django@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  404, | Triage Stage:
  WSGIScriptAlias, wsgi, resolve,|  Unreviewed
  url, prefix|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by StalkR):

 Ok, I understand. Thanks for your time!

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

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

Re: [Django] #14877: ModelFormSet.save() with a deleted form should work even if the model has already been deleted

[Django]

#14877: ModelFormSet.save() with a deleted form should work even if the model 
has
already been deleted
---+-
 Reporter:  andornaut  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.3-alpha
 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 olau):

 What the heck, I added a patch for fixing it based on andornaut's
 suggestion (it didn't apply verbatim to HEAD). With this the test case in
 #18508 passes.

 Just to recap, the problem here is that the code tries to call clean on
 the pk field which a) makes an extraneous DB query to validate it
 (extraneous because we just went through a form.is_valid()), b) fails if
 the object is already gone from the database.

 In my case, I basically had

 {{{
 if formset.is_valid():
 formset.save() # validation exception here!
 }}}

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

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

Django/Python -- New Mobile and eReader Design and Development

[James Nekton]

I am looking for a seasoned engineer (with Django/Python skills) who would
be open to cross-training on a variety of cutting-edge web technologies and
contribute to the development of the next generation of our mobile apps and
eReaders solutions.



I recruit for Safari Books Online.  Below my signature is a brief job and
company overview.



Interested in learning more?  If so, please send me an updated copy of
resume and I’ll touch base with you about next steps. Please feel free to
forward this to any of your contacts as well if you think they might be a
good fit.



We are doing some very cool stuff!  Talk to you soon.



James Nekton

Senior Recruiter

Safari Books Online

jnek...@safarijv.com

707-827-3055



Senior Engineer – New Mobile and eReader Design and Development -
Django/Python



This is an outstanding opportunity for the seasoned web engineer with a
history of shipping great code to join our small but elite team as we
develop the next generation of mobile solutions for our industry leading,
on-demand applications.  Your experience with Python, Java, or Ruby and the
willingness to learn other new web technologies will be critical to your
success.



Our current development stack is Django/Python, Backbone.js / RequireJS  /
and JQuery sitting on MySQL / Ubuntu.  We have a dedication to new web
technology (HTML 5) and testing (Nose, QUnit, Selenium) to make bulletproof
cutting-edge products for users around the World.  We stand at the
fore-front of mobile reading, eBooks and other emerging technologies.



We also have interest in candidates with data analysis and services as we
are actively developing services involving Hadoop, data mining and
streaming data.



Based in our new Seaport / Innovation District (Boston) office (or via
telecommuting) you will have the opportunity to expand your skill set and
have a high level of autonomy in our relaxed but innovative environment.  Our
engineering team is a group of life-long learners that is not married to a
particular technology, methodology or job description, instead we encourage
innovation, exploring the latest technology for elegant, efficient
solutions, and tackling and solving all technical challenges.  If this
sounds like an environment and role in which you would thrive then please
send your resume to jnek...@safarijv.com for consideration.



About us:



Safari Books Online gives subscribers on-demand access to more than 19,000
learning resources written by thought-leaders in technology, business and
digital media.  We offer books, videos, code snippets and practice exams in
one, easy-to-use destination. Our combination of vetted, up-to-date content
from the world's most well-known publishers, and our powerful platform
tools, enable subscribers to quickly find, organize, manage, share and
apply the information they find in our library. And, with Safari Books
Online's mobile optimized web site and its iPad app (Safari To Go),
subscribers can search the library, read books, watch videos and save
information from their mobile devices whenever they like.








-- 
James Nekton
Senior Recruiter
Safari Books Online
jnek...@safarijv.com
707-827-3055

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

Re: [Django] #14877: ModelFormSet.save() with a deleted form should work even if the model has already been deleted

[Django]

#14877: ModelFormSet.save() with a deleted form should work even if the model 
has
already been deleted
---+-
 Reporter:  andornaut  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.3-alpha
 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 olau):

 I added a test case in the related issue #18508 which also reproduces this
 bug. So if it's stalled on a on a missing automated test, this can perhaps
 help.

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

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

[Django] #18508: Bug in handling out-of-date POST data with inlineformset_factory

[Django]

#18508: Bug in handling out-of-date POST data with inlineformset_factory
+
 Reporter:  olau|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Forms   |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 Hi, there's a bug in BaseModelFormSet._construct_form. There's a guard
 supposed to take care of bound forms, but if one of the entries has been
 deleted, self._existing_object(pk) will return None so you can end up in

 {{{
 if i < self.initial_form_count() and not kwargs.get('instance'):
 kwargs['instance'] = self.get_queryset()[i]
 }}}

 which is dangerous for a bound form where you must use ids to identify
 elements since element "i" can have changed from when the form was
 generated. In my case, I got an IndexError because there weren't enough
 elements left from a recent deletion.

 I think the correct fix is to change the "if" to an "elif".

 I've attached a patch with this fix and a test case for reproducing the
 problem (there doesn't seem to be any tests of model formsets?).

 Note that the test as entered doesn't pass even with the fix because of
 issue #14877 - if you delete formset.save() and below in the test, it does
 pass.

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

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

Re: [Django] #17209: Dogfood class-based views in contrib.auth

[Django]

#17209: Dogfood class-based views in contrib.auth
-+-
 Reporter:  melinath |Owner:  andrews
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  contrib.auth |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  class-based views|  Needs documentation:  0
  admin auth |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anonymous):

 Also check out #16197 which has been closed as a duplicate of this ticket.

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

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

Re: [Django] #16197: Rewrite contrib auth to use class based views

[Django]

#16197: Rewrite contrib auth to use class based views
-+-
 Reporter:  hvdklauw |Owner:  hvdklauw
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  contrib.auth |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  dceu2011 |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

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


Comment:

 Closing as duplicate of #17209 since it has recent activity and more
 comments and code.

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

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

Re: [Django] #10944: Site app should be able to make absolute URLs.

[Django]

#10944: Site app should be able to make absolute URLs.
---+--
 Reporter:  jdunck |Owner:  krzysiumed
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  1.0
 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 krzysiumed):

 * owner:   => krzysiumed
 * cc: krzysiumed@… (added)


Comment:

 I added my draft where `site_url` is similar to `url` tag (actually it
 calls the `url` tag function and create instance of `URLNode` to avoid
 redundancy). It includes tests and docs but my english is poor. An example
 of using my `site_url`:

 {{{
   {% site_url site 'myapp.views.viewname' %} ==>
 'http://example.com/path/to/view'
   {% site_url site using https 'myapp.views.viewname' %} ==>
 'https://example.com/path/to/view'
 }}}

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

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

Re: [Django] #14877: ModelFormSet.save() with a deleted form should work even if the model has already been deleted

[Django]

#14877: ModelFormSet.save() with a deleted form should work even if the model 
has
already been deleted
---+-
 Reporter:  andornaut  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  1.3-alpha
 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 olau):

 * cc: olau@… (added)


Comment:

 Just hit this bug too on a site with a lot of writes. andornauts
 suggestion seems to work.

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

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

Re: [Django] #18023: Stop bundling simplejson and deprecate the module

[Django]

#18023: Stop bundling simplejson and deprecate the module
-+-
 Reporter:  ogier|Owner:  aaugustin
 Type:   |   Status:  reopened
  Cleanup/optimization   |  Version:  master
Component:  Core |   Resolution:
  (Serialization)| Triage Stage:  Accepted
 Severity:  Release blocker  |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by lukeplant):

 I agree - we should just consider simplejson as buggy on all counts, and
 document the incompatibilities in 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18495: 404 with non-/ WSGI, script prefix not removed in core/urlresolvers.py: resolve()

[Django]

#18495: 404 with non-/ WSGI, script prefix not removed in core/urlresolvers.py:
resolve()
-+-
 Reporter:  django@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  404, | Triage Stage:
  WSGIScriptAlias, wsgi, resolve,|  Unreviewed
  url, prefix|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by lukeplant):

 I think this is probably a fairly obscure corner case, and it wouldn't be
 worth the complication to get 404 pages to include stack traces. Sorry!

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

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

Re: [Django] #18507: Django 1.3 breaks ordering by the reverse of a one-to-one field

[Django]

#18507: Django 1.3 breaks ordering by the reverse of a one-to-one field
-+-
 Reporter:  vanschelven  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by lukeplant):

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


Comment:

 I can't reproduce this on trunk or 1.4. It's possible it was a real bug
 but was fixed already. Please re-open if you can demonstrate this on
 trunk. (We wouldn't fix this on the 1.3.X branch, so there is no point me
 testing 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #18471: Add a localization field option in Model Fields.

[Django]

#18471: Add a localization field option in Model Fields.
-+-
 Reporter:  serge_spaolonzi  |Owner:
 Type:  New feature  |  serge_spaolonzi
Component:  Database layer   |   Status:  closed
  (models, ORM)  |  Version:  1.4
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 No option about a presentation problem should be added to model fields,
 citing previously made mistakes that are hard to remove (e.g. help_text)
 isn't a reason to start doing that.

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

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

Re: [Django] #18507: Django 1.3 breaks ordering by the reverse of a one-to-one field

[Django]

#18507: Django 1.3 breaks ordering by the reverse of a one-to-one field
-+-
 Reporter:  vanschelven  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   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
-+-
Changes (by vanschelven):

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


Comment:

 In fact this is not restricted to Meta's ordering field but is also true
 for a "manual" call to ordering, i.e. removing ordering from Meta (whether
 poked or not) and calling:

 {{{
 User.objects.all().order_by("username__lastname")
 }}}

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

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

[django/django] 7f2258: Corrected the `instance_dict` description for form...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 7f225880e4b7f846a1e910f6be0bce11f9a8d5ec
  
https://github.com/django/django/commit/7f225880e4b7f846a1e910f6be0bce11f9a8d5ec
  Author: Florian Apolloner 
  Date:   2012-06-22 (Fri, 22 Jun 2012)

  Changed paths:
M django/contrib/formtools/wizard/views.py
M docs/ref/contrib/formtools/form-wizard.txt

  Log Message:
  ---
  Corrected the `instance_dict` description for form wizards.



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

[Django] #18507: Django 1.3 breaks ordering by the reverse of a one-to-one field

[Django]

#18507: Django 1.3 breaks ordering by the reverse of a one-to-one field
--+
 Reporter:  vanschelven   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I have a piece of code that breaks on migrating from 1.2 to 1.3. There is
 no mention of this in the 1.3 release notes, specifically in the section
 that speaks of backwards incompatibilities.

 Basically, I'm poking the order_by value on User's Meta to be ordered by
 properties of !UserProfile. !UserProfile has a !OneToOneField to user. On
 Django 1.2 this meant I could use !UserProfile's fields for sorting Users.
 On Django 1.3 things start to break badly.

 I.e.:

 {{{
 class UserProfile(models.Model):
 user = models.OneToOneField(User, editable=False)

 first_name = models.CharField(max_length=255, blank=True,
 verbose_name=_("Firstname"))
 name_prefix = models.CharField(max_length=50, blank=True,
 verbose_name=_("Lastname prefix"))
 last_name = models.CharField(max_length=255, blank=True,
 verbose_name=_("Lastname"))

 ...

 User._meta.ordering = ('userprofile__last_name',
 'userprofile__name_prefix', 'userprofile__first_name')
 }}}

 Django 1.2 situation:
 {{{
 >>> from django.contrib.auth.models import User
 >>> u = User.objects.all()[0]
 >>> User._meta.get_field_by_name('userprofile')
 (, None, False,
 False)
 >>>
 }}}


 Django 1.3 situation:
 {{{
 >>> from django.contrib.auth.models import User
 >>> u = User.objects.all()[0]
 Traceback (most recent call last):
   File "", line 1, in 
   [...]
   File "/home/klaas/dev/online/demo/django/db/models/sql/query.py", line
 1238, in setup_joins
 "Choices are: %s" % (name, ", ".join(names)))
 FieldError: Cannot resolve keyword 'userprofile' into field. Choices are:
 ...
 >>> User._meta.get_field_by_name('userprofile')
 Traceback (most recent call last):
   File "", line 1, in 
   File ".../django/db/models/options.py", line 313, in get_field_by_name
 % (self.object_name, name))
 FieldDoesNotExist: User has no field named 'userprofile'
 }}}

 The call to get_field_by_name is what goes wrong in the first place (i.e.
 it's the method call in setup_joins that's failing), so I've highlighted
 that above. I assume get_field_by_name() no longer existing for reverse
 fields might also cause breakage in certain applications, but haven't used
 it myself in a way that breaks.

 I suppose it's not related to poking on User's Meta, and is a problem in
 general, but I haven't checked that yet.

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

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

[django/django] 6bc1b2: Fixed our HTMLParser patches for python 2.7.4

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 6bc1b222994301782bd80780bdeec8c4eb44631a
  
https://github.com/django/django/commit/6bc1b222994301782bd80780bdeec8c4eb44631a
  Author: Florian Apolloner 
  Date:   2012-06-22 (Fri, 22 Jun 2012)

  Changed paths:
M django/utils/html_parser.py

  Log Message:
  ---
  Fixed our HTMLParser patches for python 2.7.4



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

Re: [Django] #18471: Add a localization field option in Model Fields.

[Django]

#18471: Add a localization field option in Model Fields.
-+-
 Reporter:  serge_spaolonzi  |Owner:
 Type:  New feature  |  serge_spaolonzi
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by vanschelven):

 Responding to the discussion here, the following remarks:

 * If blank/help_text/verbose_name are considered undesirable elements of
 Model Fields I'd love to know what the new canonical pattern for DRY
 between models and corresponding forms is. I _do_ think there is value in
 not repeating yourself between forms & models.
 * I'm not sure on localize=False being the correct default either; see the
 remarks above about the behavior of L10N in templates.
 * My workaround is to patch Django's code in a local branch. Not so great
 I suppose.

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

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

Re: [Django] #17776: DoesNotExist is not picklable

[Django]

#17776: DoesNotExist is not picklable
-+-
 Reporter:  ambv |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Luke Plant ):

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


Comment:

 In [a54a8bab0c6a96c03452040e92b2a3141695a363]:
 {{{
 #!CommitTicketReference repository=""
 revision="a54a8bab0c6a96c03452040e92b2a3141695a363"
 Fixed #17776 - DoesNotExist is not picklable

 Thanks to ambv for the report
 }}}

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

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

[django/django] a54a8b: Fixed #17776 - DoesNotExist is not picklable

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: a54a8bab0c6a96c03452040e92b2a3141695a363
  
https://github.com/django/django/commit/a54a8bab0c6a96c03452040e92b2a3141695a363
  Author: Luke Plant 
  Date:   2012-06-22 (Fri, 22 Jun 2012)

  Changed paths:
M django/db/models/base.py
M tests/regressiontests/queryset_pickle/tests.py

  Log Message:
  ---
  Fixed #17776 - DoesNotExist is not picklable

Thanks to ambv for the report



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

Re: [Django] #18506: (Model)Forms localize=True violates DRY

[Django]

#18506: (Model)Forms localize=True violates DRY
---+--
 Reporter:  vanschelven|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  duplicate
 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 vanschelven):

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

Re: [Django] #18471: Add a localization field option in Model Fields.

[Django]

#18471: Add a localization field option in Model Fields.
-+-
 Reporter:  serge_spaolonzi  |Owner:
 Type:  New feature  |  serge_spaolonzi
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by vanschelven):

 I just opened a duplicate ticket 'cause I missed this one. (#18506).
 Copy/pasta below for convenience.

 


 As it is now one cannot make localized !ModelForms without violating DRY.
 Developers w/o the desire for localized data in their application can
 simply take a model and then create a modelform in three lines and an
 admin interface in even less. However, a developer that wants localization
 to work in the admin/their modelforms needs to set the attribute
 localize=True for each single field that they want localized. This breaks
 DRY as there is both repetition of the "localize=True" and it also
 introduces new repetition between models & their forms.

 I understand that the decision to make localize=False the default was both
 deliberate and probably the correct one, as Russel explains here:
 http://groups.google.com/group/django-
 developers/browse_thread/thread/01096cd968bf276a/9ad982e939f1284f

 However, a couple of notes:

 * I think the case Russel mentions is the exception, not the rule.
 "Usually" a number is just a number, not a year. Postal codes and phone
 numbers are often not numbers at all.
 * We (Django) have made the opposite decision for template rendering:
 Indicating USE_L10N in settings makes localized rendering the default
 throughout the application, and the developer is left to find the
 exceptions and note them whenever they occur. This is inconsistent with
 the way we deal with forms (and has the usual drawbacks of inconsistency,
 such as the confusion of the OP in the email above).
 My suggested solution would be to add an attribute to !ModelFields.

 We already have a number of cases in which attributes of models' fields
 are propagated to your modelforms. blank => not required, verbose_name =>
 label and help_text => help_text spring to mind.

 I'd say name this attribute "localize" and default it to True (since
 that's the most common case). But this will introduce backwards breakage,
 so I can also imagine simply keeping it False as a default. That would at
 least get rid of the violation of DRY mentioned above. Alternatively the
 default value of this attribute could be settings.USE_L10N.

 Once we have localize=!True/False on modelfields, we could even envision
 using that value in template output as well, i.e. years will automatically
 be recognized as such and we no longer need to explicitly mark them as
 non-localized each time they're used in a template. But maybe that's
 ground for another ticket.

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

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

Re: [Django] #18506: (Model)Forms localize=True violates DRY

[Django]

#18506: (Model)Forms localize=True violates DRY
---+--
 Reporter:  vanschelven|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  duplicate
 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 anonymous):

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


Comment:

 Isn't this #18471?

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

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

[Django] #18506: (Model)Forms localize=True violates DRY

[Django]

#18506: (Model)Forms localize=True violates DRY
---+
 Reporter:  vanschelven|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 As it is now one cannot make localized !ModelForms without violating DRY.
 Developers w/o the desire for localized data in their application can
 simply take a model and then create a modelform in three lines and an
 admin interface in even less. However, a developer that wants localization
 to work in the admin/their modelforms needs to set the attribute
 localize=True for each single field that they want localized. This breaks
 DRY as there is both repetition of the "localize=True" and it also
 introduces new repetition between models & their forms.

 I understand that the decision to make localize=False the default was both
 deliberate and probably the correct one, as Russel explains here:
 http://groups.google.com/group/django-
 developers/browse_thread/thread/01096cd968bf276a/9ad982e939f1284f

 However, a couple of notes:
 * I think the case Russel mentions is the exception, not the rule.
 "Usually" a number is just a number, not a year. Postal codes and phone
 numbers are often not numbers at all.
 * We (Django) have made the opposite decision for template rendering:
 Indicating USE_L10N in settings makes localized rendering the default
 throughout the application, and the developer is left to find the
 exceptions and note them whenever they occur. This is inconsistent with
 the way we deal with forms (and has the usual drawbacks of inconsistency,
 such as the confusion of the OP in the email above).

 My suggested solution would be to add an attribute to !ModelFields.

 We already have a number of cases in which attributes of models' fields
 are propagated to your modelforms. blank => not required, verbose_name =>
 label and help_text => help_text spring to mind.

 I'd say name this attribute "localize" and default it to True (since
 that's the most common case). But this will introduce backwards breakage,
 so I can also imagine simply keeping it False as a default. That would at
 least get rid of the violation of DRY mentioned above. Alternatively the
 default value of this attribute could be settings.USE_L10N.

 Once we have localize=!True/False on modelfields, we could even envision
 using that value in template output as well, i.e. years will automatically
 be recognized as such and we no longer need to explicitly mark them as
 non-localized each time they're used in a template. But maybe that's
 ground for another ticket.

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

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

Re: [Django] #18057: Docs should say that caches are not cleared after each test

[Django]

#18057: Docs should say that caches are not cleared after each test
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.4
 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 aalbrecht):

 * cc: albrecht.andi@… (added)


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

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

Re: [Django] #18057: Docs should say that caches are not cleared after each test

[Django]

#18057: Docs should say that caches are not cleared after each test
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.4
 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 aalbrecht):

 Is this really just a documentation bug? I would expect that the cache is
 cleared between each test - just like the database too.

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

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

[Django] #18505: bad link from definitive guide to Dj web dev done right

[Django]

#18505: bad link from definitive guide to Dj web dev done right
+
 Reporter:  jacanterbury@…  |  Owner:  nobody
 Type:  Uncategorized   | Status:  new
Component:  Uncategorized   |Version:  1.4
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 fyi

 App G p421 of the definitive guide to django web development done right
 (PDF version) has a link to

 http://www.djangoproject.com/documentation/0.96/testing/

 which is broken.

 obviously the version # has moved on but a redirect might be nice?

 thanks

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

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

Re: [Django] #16017: createsuperuser fails if Python can't detect default locale

[Django]

#16017: createsuperuser fails if Python can't detect default locale
-+-
 Reporter:  prestontimmons   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  dceu2011 |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by nlsp):

 * cc: niels.poppe@… (removed)


Comment:

 Replying to [comment:34 mrab54@…]:
 > Ran into this on FreeBSD 8.2.
 >
 > Workaround:
 >

 [ platform specific shell commands ]

 > I don't see why this is required.  Doesn't Django default to UTF-8?  Or
 default to something?


 The whole point is that getting the “username” will **never** be solved in
 a platform independent way.

 Discussion about whether or not boxes are “misconfigured” when this
 happens are pointless. In my view is an error making Django depend on
 this.

 One fix is to not try default to a username, another fix is to be more
 flexible in recovering from possible decoding errors.

 Both are better than doing nothing. Or doing what is currently done:
 starting up a debate on how a ticket should be phrased and then doing
 nothing again.

 Good luck!

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

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

Re: [Django] #18023: Stop bundling simplejson and deprecate the module

[Django]

#18023: Stop bundling simplejson and deprecate the module
-+-
 Reporter:  ogier|Owner:  aaugustin
 Type:   |   Status:  reopened
  Cleanup/optimization   |  Version:  master
Component:  Core |   Resolution:
  (Serialization)| Triage Stage:  Accepted
 Severity:  Release blocker  |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by ogier):

 Replying to [comment:9 aaugustin]:
 > [https://groups.google.com/forum/?fromgroups#!topic/django-
 developers/JM4ndZbk_wY This thread on the mailing list] and
 
[https://github.com/django/django/commit/cec6bd5a59547dc97fe98975c570fc27a1e970be#L5R53
 this comment on the commit] indicate that this change may be backwards
 incompatible.
 >
 > Right now I don't know what the correct resolution is. In all cases it
 should be documented here.

 Here's what I believe is an accurate summary of the situation:

 '''First issue: str vs. unicode'''

 The simplejson API is documented as returning unicode strings for all JSON
 keys and string values.
 http://simplejson.readthedocs.org/en/latest/index.html#simplejson.JSONDecoder

 In fact, the optional C library (installed by default when installing
 simplejson) makes an API-changing optimization: if the value is entirely
 ASCII characters, a `str` instance is returned instead of a `unicode`
 instance.
 
https://github.com/simplejson/simplejson/blob/master/simplejson/_speedups.c#L527

 The Python standard library `json` package was forked from simplejson at
 version 1.9, and included this optimization. However, it was considered a
 bug and fixed in python 2.7. http://bugs.python.org/issue11982

 The net result is that it is possible that some code that runs on manually
 installed versions of simplejson or python <= 2.6 depends on this
 behavior. I think that Python core's approach is correct: we should
 consider this a bug, because it is behavior that directly contradicts the
 documentation. It's worth pointing out that any code that depends on this
 behavior is already broken on python 2.7.

 '''Second issue: namedtuple_as_object'''

 This is a systemic problem with any shim that is supposed to be
 transparent. In this case, `namedtuple_as_object` is a keyword argument to
 `simplejson.JSONEncoder` that was added in simplejson 2.2. The latest
 version of simplejson that was merged into the python standard library is
 2.0.9 and Django 1.4 shipped with simplejson 2.0.7 bundled. This means
 that nowhere in stock Django are there any references to this keyword.
 This wouldn't be a huge problem, except that Django subclasses
 `django.utils.simplejson.JSONEncoder` as
 `django.core.serializers.json.DjangoJSONEncoder`, and naturally doesn't
 know about this keyword argument.

 This is a deeper problem than just passing along unrecognized keyword
 arguments to the base class in `__init__()` to make sure that
 `DjangoJSONEncoder` never breaks. If we want to deprecate the
 `django.utils.simplejson` shim, then `DjangoJSONEncoder` must become a
 subclass of `json.JSONEncoder`. This has the unfortunate effect that calls
 to `simplejson.dumps({'hi':'there'}, cls=DjangoJSONEncoder)` will all fail
 (this is the `simplejson` on PyPI I'm talking about). Basically
 `DjangoJSONEncoder` will be incompatible with simplejson, which is a
 backwards incompatibility.

 The problem is that even leaving in the shim and subclassing as we do
 isn't a good solution. It means that DjangoJSONEncoder needs to not only
 be backwards compatible through all supported Python versions, but they
 also must be forwards compatible with the latest simplejson releases,
 which have already been shown to diverge in backwards incompatible ways.
 (Adding an argument to a method on a base class breaks contravariance.)

 If that paragraph seemed confusing, think of it this way: if
 `DjangoJSONEncoder` is a `json.JSONEncoder` then passing it to
 `simplejson.dumps()` is dangerous. If `DjangoJSONEncoder` is a
 `simplejson.JSONEncoder` then passing it to `json.dumps()` is dangerous.

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

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

Re: [Django] #18504: humanize template filters miss the `expects_localtime` parameter

[Django]

#18504: humanize template filters miss the `expects_localtime` parameter
--+-
 Reporter:  aaugustin |Owner:  aaugustin
 Type:  Bug   |   Status:  new
Component:  contrib.humanize  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Description changed by aaugustin:

Old description:

> This was reported on [ django-users]. Patch attached.

New description:

 This was reported on [https://groups.google.com/d/topic/django-users
 /izkJcX-Dko8/discussion django-users]. Patch attached.

--

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

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

[Django] #18504: humanize template filters miss the `expects_localtime` parameter

[Django]

#18504: humanize template filters miss the `expects_localtime` parameter
+---
   Reporter:  aaugustin |  Owner:  aaugustin
   Type:  Bug   | Status:  new
  Component:  contrib.humanize  |Version:  1.4
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
 This was reported on [ django-users]. Patch attached.

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

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

Re: [Django] #18471: Add a localization field option in Model Fields.

[Django]

#18471: Add a localization field option in Model Fields.
-+-
 Reporter:  serge_spaolonzi  |Owner:
 Type:  New feature  |  serge_spaolonzi
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by apollo13):

 Replying to [comment:5 Serge Spaolonzi (serge@…]:
 > There are already some options in the model field that are related to
 the Form/Widget display: help_text and editable.

 Yes, those are there due to history (blank is also just Form related).

 > One of the issues it deals with is the decimal separator implementation
 in the Admin site, in the USA and Canada people use the dot while people
 in Europe and Latino America use the comma.

 No argument here, we use comma here too…

 > I have tried other workarounds to help this issue but this one seems to
 be the cleanest.
 What are those other workarounds? Maybe if we all know them we can think
 of a cleaner solution?

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

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

Re: [Django] #18023: Stop bundling simplejson and deprecate the module

[Django]

#18023: Stop bundling simplejson and deprecate the module
-+-
 Reporter:  ogier|Owner:  aaugustin
 Type:   |   Status:  reopened
  Cleanup/optimization   |  Version:  master
Component:  Core |   Resolution:
  (Serialization)| Triage Stage:  Accepted
 Severity:  Release blocker  |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  closed => reopened
 * needs_docs:  1 => 0
 * has_patch:  1 => 0
 * resolution:  fixed =>
 * severity:  Normal => Release blocker


Comment:

 [https://groups.google.com/forum/?fromgroups#!topic/django-
 developers/JM4ndZbk_wY This thread on the mailing list] indicates that
 this change may be backwards incompatible.

 Right now I don't know what the correct resolution is. In all cases it
 should be documented here.

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

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