Re: [Django] #18062: Document Best Practice for Choices in Model Fields

[Django]

#18062: Document Best Practice for Choices in Model Fields
--+
 Reporter:  guettli   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  1.4
 Severity:  Normal|   Resolution:  fixed
 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 guettli):

 * cc: hv@… (removed)


Comment:

 Thank you James!

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18696: A mistake in the title of article "Creating a WizardView class"

[Django]

#18696: A mistake in the title of article "Creating a WizardView class"
-+-
 Reporter:  sergzach |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:  wizard-view form-| Triage Stage:
  wizard |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by sergzach):

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


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

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

Re: [Django] #18511: Admin Site: Error Message displays different for Changeforms and the Password Change screen.

[Django]

#18511: Admin Site: Error Message displays different for Changeforms and the
Password Change screen.
-+-
 Reporter:  serge_spaolonzi  |Owner:
 Type:   |  serge_spaolonzi
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  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:  1
-+-

Comment (by serge_spaolonzi):

 I have modified the code, I have deleted an extra test that was
 unnecessary.
 https://github.com/cobalys/django/tree/ticket_18511

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #18744: NamedTemporaryFile opened in read mode cannot be written to by another process on Windows

[Django]

#18744: NamedTemporaryFile opened in read mode cannot be written to by another
process on Windows
--+
 Reporter:  ty@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (Other)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The documentation for NamedTemporaryFile says that it exists so that on
 Windows so other processes can open the file, which is not possible using
 Python's implementation of NamedTemporaryFile because of the O_TEMPORARY
 flag that is passed by default.

 However, if the temporary file is opened in read mode (r+), another
 process cannot write to the file, unless the temp file is closed before
 the outside process is called. This comes up with django_compressor when
 trying to use lessc (either https://github.com/duncansmart/less.js-windows
 or http://www.dotlesscss.org/).

 I've attached a test that demonstrates the problem. On *nix, this test
 should 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 https://groups.google.com/groups/opt_out.

[django/django] 727557: Clarified thread safety note in class based views;...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 7275576235ae2e87f3de7b0facb3f9b0a2368f28
  
https://github.com/django/django/commit/7275576235ae2e87f3de7b0facb3f9b0a2368f28
  Author: Tim Graham 
  Date:   2012-08-09 (Thu, 09 Aug 2012)

  Changed paths:
M docs/ref/class-based-views/index.txt

  Log Message:
  ---
  Clarified thread safety note in class based views; thanks rafadura for the 
patch.



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18490: Datefield input format options don't match the docs

[Django]

#18490: Datefield input format options don't match the docs
---+
 Reporter:  david@…|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.4
 Severity:  Normal |   Resolution:
 Keywords:  date input format  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+
Changes (by timo):

 * needs_better_patch:  0 => 1


Comment:

 The patch reflects the behavior if settings.USE_L10N = True but the docs
 are correct if USE_L10N = False

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #18743: select_for_update() silently ignored on aggregate queries

[Django]

#18743: select_for_update() silently ignored on aggregate queries
--+
 Reporter:  anonymous |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When used on aggregate queries, the new 1.4 select_for_update() silently
 omits "FOR UPDATE" from the generated SQL. Instead, I would expect Django
 to raise a database exception, as "SELECT FOR UPDATE" on an aggregate
 query does not make sense. For instance, raw PostgreSQL yields an error
 message:

 # select max(id) from mytable for update;
 ERROR:  SELECT FOR UPDATE/SHARE is not allowed with aggregate functions

 In constrast, a Django query containing an aggregate like Max() and also
 using select_for_update() does not raise an exception.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #18742: Template tag length returns invalid value

[Django]

#18742: Template tag length returns invalid value
-+
 Reporter:  lukaslipka@… |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.4
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 The length template tag shows some weird behavior for undefined values.

 A condition such as evaluates true, when blabla is undefined:

 {{{
 {% if blabla|length > 5 %}
   {{ blabla|length }}
 {% endif %}
 }}}

 Even though it evaluates true, the output of {{ blabla|length }} is 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 https://groups.google.com/groups/opt_out.

Re: [Django] #10790: Too many joins in a comparison for NULL.

[Django]

#10790: Too many joins in a comparison for NULL.
-+-
 Reporter:  mtredinnick  |Owner:
 Type:  Bug  |  mtredinnick
Component:  Database layer   |   Status:  new
  (models, ORM)  |  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
-+-

Comment (by akaariai):

 I did some work on doing the removal beforehand. Some things broke, while
 fixing them more things broke and so on...

 I do agree fixing this is important, getting efficient SQL is important.
 To me it seems one part of the problem is that once generated joins which
 are then trimmed away can be later on reused. Causes all sorts of
 problems. However, this is needed so that certain things work (run a
 query, pickle it, unpickle it, rerun it -> same query string generated).
 Complex stuff...

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18741: Small cleanup to split_exclude()

[Django]

#18741: Small cleanup to split_exclude()
-+-
 Reporter:  akaariai |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Ready for
 Severity:  Normal   |  checkin
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * stage:  Accepted => Ready for checkin


Comment:

 A patch in https://github.com/akaariai/django/tree/split_exclude_cleanup

 Marking this RFC as I am pretty sure the patch is correct. Hopefully I
 will get this (and some other pending patches) committed during the
 weekend.

-- 
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 https://groups.google.com/groups/opt_out.

[Django] #18741: Small cleanup to split_exclude()

[Django]

#18741: Small cleanup to split_exclude()
-+-
   Reporter:  akaariai   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |Version:  master
  Component:  Database   |   Keywords:
  layer (models, ORM)|  Has patch:  0
   Severity:  Normal |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 sql.query.split_exclude() contains this call:
 {{{
 query = Query(self.model)
 query.add_filter(filter_expr, can_reuse=can_reuse)
 }}}
 Here a new subquery is created, and the can_reuse set is a set of joins
 that are reusable from the outer query.

 The problem is that passing the can_reuse here doesn't make any sense -
 the new query contains no joins so there of course isn't anything to
 reuse. If the .add_filter() adds something to the can_reuse set, that
 addition will be incorrect for the outer query. However I am not sure if
 it is possible to create an actual error because of this.

 This also makes it slightly easier to see what happens in split_exclude().

 When I got rid of can_reuse all tests 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 https://groups.google.com/groups/opt_out.

Re: [Django] #15819: Admin searches should use distinct, if query involves joins

[Django]

#15819: Admin searches should use distinct, if query involves joins
-+-
 Reporter:  Adam Kochanowski |Owner:  ryankask
  |   Status:  reopened
 Type:  Bug  |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Yeah, I agree about distinct being slow, and as mentioned in the article
 it is usually a sign of badly written query.

 I find it hard to believe doing the distinct operation on Python side
 would lead to a net win. Databases are written in C and they will be
 faster at doing the distinct than transferring the whole dataset to Python
 and then doing the distinct on that side.

 Making the ORM to do transformation of m2m filter to subquery should be
 easy in the trivial cases, as we already do them for m2m exclude joins.
 The harder problem is doing them for queries like this:
 {{{
 qs.filter(Q(m2m_rel__foo='Bar')|Q(m2m_rel__foo='Baz'))
 }}}
 The problem is that lookups inside one filter should target the same join
 (IIRC), but the transform-to-subquery logic doesn't know anything about
 that.

 Still, as a long term goal it would be nice to move away from the current
 confusing situation where filters to m2m can create duplicate results.
 However, doing that cleanly in the ORM is hard, and then there are
 backwards compatibility issues too.

 There is a closely related issue: use aggregations and m2m filters in the
 same query -> wrong results.

 So, for the time being, I think we will just need to use the ORM to detect
 when to use distinct. It should be a small step forward. I hope we can
 have automatic subqueries, but this isn't likely to happen in the close
 future.

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
---+
 Reporter:  pixelcort  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 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:  1
---+
Changes (by dekkers):

 * cc: jeroen@… (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 https://groups.google.com/groups/opt_out.

Re: [Django] #15819: Admin searches should use distinct, if query involves joins

[Django]

#15819: Admin searches should use distinct, if query involves joins
-+-
 Reporter:  Adam Kochanowski |Owner:  ryankask
  |   Status:  reopened
 Type:  Bug  |  Version:  master
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by hcarvalhoalves):

 The problem, though, is that `DISTINCT` is '''painfully slow''' on most
 databases. A query like...

 {{{
 SELECT DISTINCT "mytable"."id", ... ORDER BY "mytable"."somefield" DESC
 LIMIT 100
 }}}

 ..will force a full table scan and query time will increase linearly with
 the number of rows. Django shouldn't ''guess'' when to use it internally
 without a way for client code to override it, ''specially'' if this logic
 is moved to the ORM.

 This currently happens on `contrib.admin` if you include a M2M relation in
 the `list_filters`, and makes the `changelist` views unusable if your
 database has more than a couple hundred queries. See ticket #18729 for
 that.

 More often than not, you want to optimize the query to use a subquery
 (giving hints to the query planner because it increases selectivity), or
 querying ''without'' `DISTINCT` and removing duplicates on Python side.
 Here's a case study on optimizing queries to avoid use of `DISTINCT`:
 http://www.databasejournal.com/features/postgresql/article.php/3437821
 /SELECT-DISTINCT-A-SQL-Case-Study.htm

-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 751774: [py3] Fixed mail tests with Python 3

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 751774c29f6ad8f6ad08bc48a4d085829dd279e0
  
https://github.com/django/django/commit/751774c29f6ad8f6ad08bc48a4d085829dd279e0
  Author: Claude Paroz 
  Date:   2012-08-09 (Thu, 09 Aug 2012)

  Changed paths:
M django/core/mail/message.py
M tests/regressiontests/mail/tests.py

  Log Message:
  ---
  [py3] Fixed mail tests with Python 3



-- 
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 https://groups.google.com/groups/opt_out.

[django/django] 5f8da5: [py3k] use the base64 module, instead of bytes.enc...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 5f8da527abf6ce1d995d4f6454a07f7e442f7fd5
  
https://github.com/django/django/commit/5f8da527abf6ce1d995d4f6454a07f7e442f7fd5
  Author: Alex Gaynor 
  Date:   2012-08-09 (Thu, 09 Aug 2012)

  Changed paths:
M django/contrib/auth/hashers.py

  Log Message:
  ---
  [py3k] use the base64 module, instead of bytes.encode('base64')



-- 
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 https://groups.google.com/groups/opt_out.

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:  ramiro
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  dceu2011 |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by ramiro):

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


-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18726: Combination of F() expression with query seems to confuse sql compiler's table aliases

[Django]

#18726: Combination of F() expression with query seems to confuse sql compiler's
table aliases
-+-
 Reporter:  bugs@…   |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.4
  (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 bugs@…):

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


Comment:

 Ok here we are - a models.py that causes the problem:

 {{{#!python
 from django.db import models

 class ModelC ( models.Model ):
 pass

 class ModelB ( models.Model ):
 m2m_field_q = models.ManyToManyField ( ModelC )

 class ModelA ( models.Model ):
 m2m_field_r = models.ManyToManyField ( ModelB )

 class ModelY ( models.Model ):
 fk_field_s = models.ForeignKey ( ModelC )

 class ModelX ( models.Model ):
 fk_field_t = models.ForeignKey ( ModelY )
 m2m_field_u = models.ManyToManyField ( ModelA , through =
 "ModelXThroughA" )

 class ModelXThroughA ( models.Model ):
 fk_field_v = models.ForeignKey ( ModelX )
 fk_field_w = models.ForeignKey ( ModelA )
 }}}

 which upon running:

 {{{#!python
 ModelXThroughA.objects.exclude ( fk_field_w__m2m_field_r__m2m_field_q = F
 ( "fk_field_v__fk_field_t__fk_field_s" ) )
 }}}

 results in:

 {{{
 DatabaseError: missing FROM-clause entry for table "u4"
 LINE 1: ...id") INNER JOIN "dummy_modela_m2m_field_r" U5 ON (U4."id" = ...
 }}}

-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #11974: Submit_row in admin doesn't follow the pattern of using admin/app_label/model/submit_line.html

[Django]

#11974: Submit_row in admin doesn't follow the pattern of using
admin/app_label/model/submit_line.html
-+-
 Reporter:  vbmendes |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:
 Severity:  Normal   |   Resolution:
 Keywords:  django admin | Triage Stage:  Accepted
  templates  |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jgbreezer):

 * cc: jgbreezer@… (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 https://groups.google.com/groups/opt_out.

[django/django] 5c09c5: [py3] Renamed `next` to `__next__` in iterators.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 5c09c59bc76510a5388623259b3827ee894cd66b
  
https://github.com/django/django/commit/5c09c59bc76510a5388623259b3827ee894cd66b
  Author: Aymeric Augustin 
  Date:   2012-08-09 (Thu, 09 Aug 2012)

  Changed paths:
M django/core/serializers/base.py
M django/core/serializers/xml_serializer.py
M django/db/backends/oracle/base.py
M django/http/__init__.py
M django/http/multipartparser.py

  Log Message:
  ---
  [py3] Renamed `next` to `__next__` in iterators.

See PEP 3114. `next` is retained as an alias for Python 2.



-- 
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 https://groups.google.com/groups/opt_out.

Re: [Django] #18731: "makemessages" management command should handle import aliases

[Django]

#18731: "makemessages" management command should handle import aliases
-+-
 Reporter:  diabeteman   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  1.4
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  makemessages i18n|  Unreviewed
  gettext|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by diabeteman):

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


Comment:

 I forgot to explain some stuff about the patch :)

 Basically, if you use the i18n functions like this:

 {{{
 from django.utils.translation import ugettext as tr, ugettext_lazy as
 tr_lazy

 tr('some translatable string')
 tr_lazy('some lazy translatable string')
 }}}

 You can generate/update the .po files with this command (run into the app
 directory and/or from the project root)

 {{{
 $ django-admin.py makemessages --locale=fr_FR --extra-keyword=tr --extra-
 keyword=tr_lazy
 }}}

 It will take all your translatable strings into account.

-- 
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 https://groups.google.com/groups/opt_out.