[Django] #19159: loaddata reports DeserializationError instead of MemoryError

[Django]

#19159: loaddata reports DeserializationError instead of MemoryError
---+
 Reporter:  django@…   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The command `manage.py loaddata data.json` errors with
 DeserializationError instead of MemoryError.

 files:
 {{{
 ../lib/python2.7/site-packages/django/core/serializers/json.py
 /usr/lib/python2.7/json/__init__.py
 }}}

 relevant code is `simplejson.load(stream)` inside the `try`:
 {{{
 def Deserializer(stream_or_string, **options):
 """
 Deserialize a stream or string of JSON data.
 """
 if isinstance(stream_or_string, basestring):
 stream = StringIO(stream_or_string)
 else:
 stream = stream_or_string
 try:
 for obj in PythonDeserializer(simplejson.load(stream), **options):
 yield obj
 except GeneratorExit:
 raise
 except Exception, e:
 # Map to deserializer error
 raise DeserializationError(e)
 }}}

-- 
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] #19158: FileField's error message about too long filename should use plural translation function

[Django]

#19158: FileField's error message about too long filename should use plural
translation function
--+
 Reporter:  void  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  i18n  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by julien):

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


Comment:

 Agreed. `ungettext_lazy` should be used instead.

-- 
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] #19157: String is marked for translation in one file, but not in other.

[Django]

#19157: String is marked for translation in one file, but not in other.
---+
 Reporter:  void   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admindocs  |  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 julien):

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


Comment:

 I suggest both be marked for translation. Why do you expect tests would
 fail?

-- 
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] #12043: Incorrect redirect to http instead of https

[Django]

#12043: Incorrect redirect to http instead of https
-+-
 Reporter:  admin@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Other) |  Version:  1.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  redirect http https  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by carljm):

 For future reference for those hitting this problem: Django 1.4+ now has a
 built-in solution in the form of the SECURE_PROXY_SSL_HEADER setting
 (https://docs.djangoproject.com/en/dev/ref/settings/#secure-proxy-ssl-
 header), so there's no need to write your own middleware.

-- 
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] #19158: FileField's error message about too long filename should use plural translation function

[Django]

#19158: FileField's error message about too long filename should use plural
translation function
--+
 Reporter:  void  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  File uploads/storage  |Version:  master
 Severity:  Normal|   Keywords:  i18n
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+
 `FileField`'s error message is currently defined as `_('Filename is
 %(extra)d characters too long.')`. It contains a number, but `_` in that
 context is `ugettext_lazy`, so translators cannot provide different
 translations for different pluralization forms.

-- 
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] #19157: String is marked for translation in one file, but not in other.

[Django]

#19157: String is marked for translation in one file, but not in other.
---+
 Reporter:  void   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admindocs  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 String 'A custom field type' is marked for translation in the file
 `django/admindocs/tests/__init__.py`, but it is not marked in the file
 `django/admindocs/tests/fields.py`
 Either both string should be marked for i18n, or none of them.
 I've discovered it accidentially, when seeing new text for translation for
 1.5.

 This will probably cause tests to fail after the moment when translation
 will be pulled from transifex.

-- 
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] #6527: A bug in HttpResponse with iterators

[Django]

#6527: A bug in HttpResponse  with iterators
-+-
 Reporter:  daonb   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  http iterators   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mrmachine):

 No. I meant that when `._container` is a list the response can be pickled.
 When it is an iterator/generator, it cannot. You are right about raising
 the warning when an `HttpResponse` is implicitly streamed, rather than
 when a user consumes the iterator content (accidentally or not). That
 makes more sense.

-- 
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] #19155: New session backend instance does not respect a session_key parameter.

[Django]

#19155: New session backend instance does not respect a session_key parameter.
-+-
 Reporter:  niwi |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.4
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by lrekucki):

 * status:  new => closed
 * resolution:   => invalid
 * stage:  Unreviewed => Design decision needed


Comment:

 Judging by the comment on the test you modified:

 {{{
 #!python
  def test_invalid_key(self):
  # Submitting an invalid session key (either by guessing, or if
 the db has
  # removed the key) results in a new key being generated.
 }}}

 and [https://docs.djangoproject.com/en/dev/topics/http/sessions/#using-
 sessions-out-of-views the docs]:

 > In order to prevent session fixation attacks, sessions keys that
 don't exist are regenerated.

 it's certainly not a bug (because it works as documented and we test for
 it), thus closing.

 I don't see an obvious use case for creating sessions with explicit keys,
 so if you decide to reopen this ticket as a feature request, please
 describe yours in more detail.

-- 
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] #19088: Blocktrans tag goes to infinite recursion if python dict string format is used

[Django]

#19088: Blocktrans tag goes to infinite recursion if python dict string format 
is
used
-+-
 Reporter:  vlinhart |Owner:  lrekucki
 Type:  Bug  |   Status:  new
Component:  Translations |  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Architekt):

 * stage:  Accepted => Ready for checkin


-- 
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] #7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse objects.

[Django]

#7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse
objects.
-+-
 Reporter:  mrmachine|Owner:  ccahoon
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  stream HttpResponse  | Triage Stage:  Accepted
  Content-Length |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Aymeric Augustin ):

 In [changeset:"5e629a015e96a5564a0b0a273e1374b9651ce8e9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5e629a015e96a5564a0b0a273e1374b9651ce8e9"
 Added tests for conditional_content_removal.

 Refs #7581. Thanks mrmachine.
 }}}

-- 
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] 5e629a: Added tests for conditional_content_removal.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 5e629a015e96a5564a0b0a273e1374b9651ce8e9
  
https://github.com/django/django/commit/5e629a015e96a5564a0b0a273e1374b9651ce8e9
  Author: Aymeric Augustin 
  Date:   2012-10-21 (Sun, 21 Oct 2012)

  Changed paths:
A tests/regressiontests/http_utils/__init__.py
A tests/regressiontests/http_utils/models.py
A tests/regressiontests/http_utils/tests.py

  Log Message:
  ---
  Added tests for conditional_content_removal.

Refs #7581. Thanks mrmachine.


  Commit: 104ca49c57e3e48fe518985e2eee60ce6969d7ab
  
https://github.com/django/django/commit/104ca49c57e3e48fe518985e2eee60ce6969d7ab
  Author: Aymeric Augustin 
  Date:   2012-10-21 (Sun, 21 Oct 2012)

  Changed paths:
M docs/ref/request-response.txt

  Log Message:
  ---
  Removed inaccurate statement from the StreamingHttpResponse docs.

Iterators will be closed for both regular and streaming responses;
this shouldn't be described as a difference.


Compare: https://github.com/django/django/compare/b4066d7d2149...104ca49c57e3

-- 
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] #6527: A bug in HttpResponse with iterators

[Django]

#6527: A bug in HttpResponse  with iterators
-+-
 Reporter:  daonb   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  http iterators   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Replying to [comment:32 mrmachine]:
 > I think that the desire to keep the partial streaming behaviour as-is
 for `HttpResponse` was primarily to minimise any disruption or edge-case
 backwards incompatibility when introducing explicit support for streaming
 responses. I think that eventually, the goal here should be a more
 explicit and consistent `HttpResponse` class that makes user intent clear.
 Did they pass an iterator as content because they want to stream the
 response, or as a convenience?

 Yes, I understand that.

 > I would like to keep the existing behaviour for now and raise a
 `PendingDeprecationWarning` when an iterator is consumed by accessing
 `.content`, that directs people to use the new streaming response class.
 When the deprecation cycle is finished, `HttpResponse` should consume
 iterators on assignment. This should give people enough time to switch
 over to the new streaming response class in those cases when they actually
 want a streaming response.

 Actually we would have to raise the warning when the iterator is *not*
 consumed by accessing `.content`, but rather by the WSGI server iterating
 the response.

 > An `HttpResponse` class that always stores its content in a list
 internally can be pickled (e.g. by cache middleware and possibly other 3rd
 party code) without first having to access the content, and will remove
 any ambiguity in situations where a response currently might or might not
 stream.

 Did you mean "stores its content in 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 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] #19154: TransactionManagementError raised when data is not changed

[Django]

#19154: TransactionManagementError raised when data is not changed
--+
 Reporter:  als   |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 claudep):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Documentation
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Yes, this is intended behaviour and the documentation should be updated.
 The behaviour is explicitely tested (see transactions_regress tests). You
 can read lengthy related discussions on #9964. It is not possible for
 Django to really know if data have been modified or not, as SELECT-only
 statements can modify data.

-- 
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] #18417: override_settings doesn't work with unittest.TestCase subclasses

[Django]

#18417: override_settings doesn't work with unittest.TestCase subclasses
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by aaugustin):

 Replying to [comment:3 claudep]:
 > Replying to [comment:2 aaugustin]:
 > > `override_settings` is Django-specific; I believe it's fair to
 restrict it to subclasses of `django.test.TransactionTestCase` or
 `TestCase`, provided an exception is raised when it's misused.
 >
 > I don't follow you here. There are clearly use-cases currently in our
 test suite that would need override_settings for `unittest.TestCase`. It
 does not appear so unnatural to me.

 Right -- `unittest.TestCase` is sometimes preferred because it's faster.

 The current practice in Django's test suite is to use
 `django.test.(Transaction)TestCase` when the test cases requires some
 Django-specific behavior (fixtures, test client, etc.) and
 `unittest.TestCase` when it doesn't.

 Since `override_settings` is Django-specific, I suggest switching test
 cases decorated with `@override_settings` to
 `django.test.(Transaction)TestCase`.

 If `override_settings` raises an exception for unsupported classes, we'll
 immediately know which ones need this change.

-- 
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] b4066d: Cleaned up the the http module. Moved all of the c...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b4066d7d2149782cd694b98d1a6ed5c7ee885f55
  
https://github.com/django/django/commit/b4066d7d2149782cd694b98d1a6ed5c7ee885f55
  Author: Alex Gaynor 
  Date:   2012-10-21 (Sun, 21 Oct 2012)

  Changed paths:
M django/http/__init__.py
A django/http/cookie.py
A django/http/request.py
A django/http/response.py
M django/http/utils.py

  Log Message:
  ---
  Cleaned up the the http module. Moved all of the code from __init__.py to 
request.py, response.py and utils.py



-- 
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] #18417: override_settings doesn't work with unittest.TestCase subclasses

[Django]

#18417: override_settings doesn't work with unittest.TestCase subclasses
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by claudep):

 Replying to [comment:2 aaugustin]:
 > `override_settings` is Django-specific; I believe it's fair to restrict
 it to subclasses of `django.test.TransactionTestCase` or `TestCase`,
 provided an exception is raised when it's misused.

 I don't follow you here. There are clearly use-cases currently in our test
 suite that would need override_settings for `unittest.TestCase`. It does
 not appear so unnatural to me.

 > > Currently, `override_settings` guarantees that the settings are reset
 before each test in the test case. Altering them in a test won't affect
 other tests. This isn't documented but it's likely that some people are
 relying on this behavior.

 That's right, and that's why I didn't commit it until now.

 (...)

 > In my eyes this is as a choice between:
 > - raising an exception for people who've written tests that never ran;
 and
 > - taking the risk to introduce unexpected test failures for people
 who've written working tests.
 >
 > I'm +1 on the first option and -0 on the second.

 There might be a third option, use `_pre_setup/_post_teardown` for Django
 test subclasses, and `setUpClass/tearDownClass` for `unittest.TestCase`
 subclasses. It's a bit peculiar to have different behaviours depending on
 the test class, but at least compatibility is kept, and we can document
 it.

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

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

Re: [Django] #18417: override_settings doesn't work with unittest.TestCase subclasses

[Django]

#18417: override_settings doesn't work with unittest.TestCase subclasses
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  1.4
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * stage:  Ready for checkin => Design decision needed


Comment:

 `override_settings` is Django-specific; I believe it's fair to restrict it
 to subclasses of `django.test.TransactionTestCase` or `TestCase`, provided
 an exception is raised when it's misused.

 Currently, `override_settings` guarantees that the settings are reset
 before each test in the test case. Altering them in a test won't affect
 other tests. This isn't documented but it's likely that some people are
 relying on this behavior.

 So the current patch will lead to test failures for some users after
 upgrading Django. These test failures won't happen if the failing test is
 run in isolation, making them hard to track down.

 In my eyes this is as a choice between:
 - raising an exception for people who've written tests that never ran; and
 - taking the risk to introduce unexpected test failures for people who've
 written working tests.

 I'm +1 on the first option and -0 on the second.

-- 
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] #19142: accept_language_re rejects languages which include numeric UN region codes

[Django]

#19142: accept_language_re rejects languages which include numeric UN region 
codes
-+-
 Reporter:  DrMeers  |Owner:  Architekt
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.4
  Internationalization   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-

Comment (by Claude Paroz ):

 In [changeset:"22471a41ba676afdab55daf34f1c7c25b327bbb9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="22471a41ba676afdab55daf34f1c7c25b327bbb9"
 Merge pull request #457 from JanBednarik/ticket_19142

 Fixed #19142 -- Language codes can include numbers (RFC 3066)
 }}}

-- 
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] #19142: accept_language_re rejects languages which include numeric UN region codes

[Django]

#19142: accept_language_re rejects languages which include numeric UN region 
codes
-+-
 Reporter:  DrMeers  |Owner:  Architekt
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.4
  Internationalization   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by Jan Bednařík ):

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


Comment:

 In [changeset:"e6b34193c5c7d117ededdab04bb16caf8864f07c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e6b34193c5c7d117ededdab04bb16caf8864f07c"
 Fixed #19142 -- Language codes can include numbers (RFC 3066).
 }}}

-- 
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] e6b341: Fixed #19142 -- Language codes can include numbers...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e6b34193c5c7d117ededdab04bb16caf8864f07c
  
https://github.com/django/django/commit/e6b34193c5c7d117ededdab04bb16caf8864f07c
  Author: Jan Bednařík 
  Date:   2012-10-20 (Sat, 20 Oct 2012)

  Changed paths:
M django/utils/translation/trans_real.py
M tests/regressiontests/i18n/tests.py

  Log Message:
  ---
  Fixed #19142 -- Language codes can include numbers (RFC 3066).


  Commit: 22471a41ba676afdab55daf34f1c7c25b327bbb9
  
https://github.com/django/django/commit/22471a41ba676afdab55daf34f1c7c25b327bbb9
  Author: Claude Paroz 
  Date:   2012-10-21 (Sun, 21 Oct 2012)

  Changed paths:
M django/utils/translation/trans_real.py
M tests/regressiontests/i18n/tests.py

  Log Message:
  ---
  Merge pull request #457 from JanBednarik/ticket_19142

Fixed #19142 -- Language codes can include numbers (RFC 3066)


Compare: https://github.com/django/django/compare/e987d20ac92c...22471a41ba67

-- 
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] #12043: Incorrect redirect to http instead of https

[Django]

#12043: Incorrect redirect to http instead of https
-+-
 Reporter:  admin@…  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Other) |  Version:  1.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  redirect http https  | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by simon@…):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 I'm seeing the same thing on AWS Elastic Beanstalk, where the
 communication between the load balancer and EC2 hosts is over HTTP. I
 wrote a simple middleware class that tackles the issue, since I can't find
 a way to tweak the Apache config on those Elastic Beanstalk EC2 instances.

 https://gist.github.com/3927386


 {{{
 class SecureRequestPropagationMiddleware(object):
 """
 When running on AWS Elastic Beanstalk, we suffer
 an issue where HTTPS requests arriving at the load
 balancer are propagated to the individual hosts as
 HTTP requests. If the host issues a redirect it
 issues it using the same scheme as its incoming
 request (HTTP) when it should use HTTPS.

 This issue isn't unique to AWS EB, it's discussed
 in the context of WebFaction hosting in this
 Django ticket:

 https://code.djangoproject.com/ticket/12043

 This middleware addresses the problem, by
 using the value of the X-Forwarded-Proto header
 to manually set the wsgi.url_scheme header.
 """
 def process_request(self, request):
 if 'HTTP_X_FORWARDED_PROTO' in request.META:
 request.META['wsgi.url_scheme'] =
 request.META['HTTP_X_FORWARDED_PROTO']
 return None
 }}}

-- 
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] e86e4c: Added 1.4.2 release notes

[GitHub]

  Branch: refs/heads/stable/1.4.x
  Home:   https://github.com/django/django
  Commit: e86e4ce0bd0a538fcde0f9b0c4f26c6810621bb5
  
https://github.com/django/django/commit/e86e4ce0bd0a538fcde0f9b0c4f26c6810621bb5
  Author: Preston Holmes 
  Date:   2012-10-21 (Sun, 21 Oct 2012)

  Changed paths:
M docs/releases/1.4.2.txt
M docs/releases/index.txt

  Log Message:
  ---
  Added 1.4.2 release notes



-- 
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] e987d2: Added 1.4.2 release notes

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: e987d20ac92ceef382cc02dfab38aac64d84dc5d
  
https://github.com/django/django/commit/e987d20ac92ceef382cc02dfab38aac64d84dc5d
  Author: Preston Holmes 
  Date:   2012-10-21 (Sun, 21 Oct 2012)

  Changed paths:
M docs/releases/1.4.2.txt
M docs/releases/index.txt

  Log Message:
  ---
  Added 1.4.2 release notes



-- 
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] #6412: [patch] Check for file permissions for proper error messages

[Django]

#6412: [patch] Check for file permissions for proper error messages
--+
 Reporter:  mbeachy@… |Owner:  lrekucki
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by lrekucki):

 * owner:  nobody => lrekucki


Comment:

 Eh, I have a hard time testing this on Windows (can't set a file
 unreadable). Will update the patch next week.

-- 
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] 1a3ff6: Updated error message for bad database engine

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 1a3ff63199cd14f772a86090c4546953f3f19343
  
https://github.com/django/django/commit/1a3ff63199cd14f772a86090c4546953f3f19343
  Author: Preston Holmes 
  Date:   2012-10-21 (Sun, 21 Oct 2012)

  Changed paths:
M django/core/management/sql.py

  Log Message:
  ---
  Updated error message for bad database engine

removing typo in the process. Thanks to Carlos Palol for the catch.
Closes pull 450



-- 
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] #18856: avoid set_language redirect to different host

[Django]

#18856: avoid set_language redirect to different host
-+-
 Reporter:  Gunnar   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.4
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  set_language |  checkin
  redirect infinite loop |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Architekt):

 * stage:  Accepted => Ready for checkin


-- 
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] #19034: Plural to MinLength, MaxLengt validation messages

[Django]

#19034: Plural to MinLength, MaxLengt validation messages
-+-
 Reporter:  clay.evil@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.4
  Internationalization   |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Architekt):

 * stage:  Accepted => Ready for checkin


-- 
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:  Gargamel
 Type:  New feature|   Status:  assigned
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
---+

Comment (by Gargamel):

 @FunkyBob: It shames me to tell you that I used some sort of git-gui
 program to generate it. I have just reinstalled my linux system, so now I
 can get on with learning the git syntax. Once I have fixed the last bugs
 I'll post a command line git diff :)

-- 
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] #19088: Blocktrans tag goes to infinite recursion if python dict string format is used

[Django]

#19088: Blocktrans tag goes to infinite recursion if python dict string format 
is
used
--+
 Reporter:  vlinhart  |Owner:  lrekucki
 Type:  Bug   |   Status:  new
Component:  Translations  |  Version:  1.4
 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 lrekucki):

 * needs_better_patch:  1 => 0


Comment:

 Updated pull request.

-- 
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] #19156: Test can not be run individually for apps that have tests.suite() defined

[Django]

#19156: Test can not be run individually for apps that have tests.suite() 
defined
---+
 Reporter:  aigarius   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Testing framework  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 This issue shows up if the tests are defined in the application using the
 suite(). The django.test.simple.build_suite() function has support for
 such arrangement (which is why testing the whole app works), but
 django.test.simple.build_test() does not which is why running a single
 test class or test case fails. The fix would be to call build_suite in
 build_test and then iterate over the TestSuite, just like it is done in
 the Doctest code in the same function.

-- 
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] #19155: New session backend instance does not respect a session_key parameter.

[Django]

#19155: New session backend instance does not respect a session_key parameter.
--+--
 Reporter:  niwi  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sessions  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by niwi):

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


Comment:

 I added to the same branch a possible solution. Pass all tests.

-- 
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] #19070: urlize template filter raises exception in some cases

[Django]

#19070: urlize template filter raises exception in some cases
-+-
 Reporter:  rivolaks@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.4
 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
-+-
Changes (by Architekt):

 * stage:  Accepted => Ready for checkin


Comment:

 Patch reviewed and it's RFC.

 Perhaps the question about swallowing exceptions shoud be discussed in
 django-developers or in separate 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 https://groups.google.com/groups/opt_out.

[Django] #19155: New session backend instance does not respect a session_key parameter.

[Django]

#19155: New session backend instance does not respect a session_key parameter.
--+
 Reporter:  niwi  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  contrib.sessions  |Version:  1.4
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 When I create an instance of the backend session with a specified key, if
 this key does not exist, creates a new key without respecting the one I
 specifically forced.

 Is appropriate behavior? In my point of view, No.
 This complicates a lot to create sessions with specific keys and forces me
 to do ugly hacks. That's because I have to access the low level API
 specific backend to create them the key. (This generates backend dependent
 code)

 I hope I have explained well.

 Test cases to reproduce the bug:
 https://github.com/niwibe/django/compare/bug/session-key

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

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

Re: [Django] #19088: Blocktrans tag goes to infinite recursion if python dict string format is used

[Django]

#19088: Blocktrans tag goes to infinite recursion if python dict string format 
is
used
--+
 Reporter:  vlinhart  |Owner:  lrekucki
 Type:  Bug   |   Status:  new
Component:  Translations  |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Architekt):

 * needs_better_patch:  0 => 1


Comment:

 Details in discussion https://github.com/django/django/pull/442

-- 
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] #19101: Non ascii chars in form cause Internal Server Error

[Django]

#19101: Non ascii chars in form cause Internal Server Error
-+-
 Reporter:  kristall |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Release blocker  |   Resolution:
 Keywords:  encoding | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Architekt):

 * stage:  Accepted => Ready for checkin


Comment:

 Patch reviewed.

-- 
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] #19154: TransactionManagementError raised when data is not changed

[Django]

#19154: TransactionManagementError raised when data is not changed
---+
 Reporter:  als|  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
---+
 According to Django documentation, a `commit_manually` decorator would
 raise `TransactionManagementError` if decorated block changes data and
 doesn't `commit()` or `rollback()`.

 Actually, `TransactionManagementError` is raised when no data is changed,
 but some SELECT statements were executed by model managers.

 If that is intended behavior, Django documentation should reflect it, but
 it would be better if SELECT statements could run without commit or
 rollback.

-- 
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] #6527: A bug in HttpResponse with iterators

[Django]

#6527: A bug in HttpResponse  with iterators
-+-
 Reporter:  daonb   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  http iterators   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mrmachine):

 I think that the desire to keep the partial streaming behaviour as-is for
 `HttpResponse` was primarily to minimise any disruption or edge-case
 backwards incompatibility when introducing explicit support for streaming
 responses. I think that eventually, the goal here should be a more
 explicit and consistent `HttpResponse` class that makes user intent clear.
 Did they pass an iterator as content because they want to stream the
 response, or as a convenience?

 I would like to keep the existing behaviour for now and raise a
 `PendingDeprecationWarning` when an iterator is consumed by accessing
 `.content`, that directs people to use the new streaming response class.
 When the deprecation cycle is finished, `HttpResponse` should consume
 iterators on assignment. This should give people enough time to switch
 over to the new streaming response class in those cases when they actually
 want a streaming response.

 An `HttpResponse` class that always stores its content in a list
 internally can be pickled (e.g. by cache middleware and possibly other 3rd
 party code) without first having to access the content, and will remove
 any ambiguity in situations where a response currently might or might not
 stream.

-- 
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] #18796: Refactor HttpResponse.__iter__ / _get_content

[Django]

#18796: Refactor HttpResponse.__iter__ / _get_content
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  HTTP handling|   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
-+-
Description changed by aaugustin:

Old description:

> The current implementation isn't DRY. It seems to me that `_get_content`
> should just return `b''.join(self)`.
>
> Unfortunately, implementing this naively results in test failures.
>
> This code is sensitive, tricky, and lacks comment. A refactoring would be
> useful.
>
> See also #4969, #16494, #18764, [5f2d9cdbb1], [2892cb0ec4], and
> [536b030363].

New description:

 The current implementation isn't DRY. It seems to me that `_get_content`
 should just return `b''.join(self)`.

 Unfortunately, implementing this naively results in test failures.

 This code is sensitive, tricky, and lacks comment. A refactoring would be
 useful.

 See also #4969, #16494, #18764, [5f2d9cdbb1], [2892cb0ec4], and
 [536b030363].

 '''To sum up: this ticket is about cleaning up the conversion of HTTP
 response content to bytes.'''

--

-- 
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] #18796: Refactor HttpResponse.__iter__ / _get_content

[Django]

#18796: Refactor HttpResponse.__iter__ / _get_content
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  HTTP handling|   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 aaugustin):

 This comment was made on #7581 but it actually falls in the scope of this
 ticket:

 Returning `self._iterator` directly in
 `HttpStreamingResponse.streaming_content`, instead of a new iterator that
 yields bytestrings means that middleware authors can't expect consistent
 bytestring chunks when wrapping streaming_content in a new iterator? They
 may have to type check or coerce each chunk (potentially reproducing
 something like `make_bytes()`? For comparison, `HttpResponse.content`
 always returns a bytestring.

-- 
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] #7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse objects.

[Django]

#7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse
objects.
-+-
 Reporter:  mrmachine|Owner:  ccahoon
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  stream HttpResponse  | Triage Stage:  Accepted
  Content-Length |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Replying to [comment:43 mrmachine]:
 > 1. We're not checking if the `close` attribute on assigned content is
 callable before adding it to `_closable_objects`? Probably an edge case
 not worth worrying about, though.

 Yes, primarily because `callable` is gone in Python 3.

 If someone has a custom file-like / iterator object that has a `close`
 attribute that isn't callable, that'll teach him a bit of API design
 principles :)

 > 2. Should we pop closable objects off the list before closing them (or
 just empty the list after closing all items), so that multiple calls to
 `close()` don't re-attempt to close objects already closed? Graham's blog
 seems to indicate that multiple WSGI middleware may each call `close()` on
 the response? http://blog.dscpl.com.au/2012/10/obligations-for-calling-
 close-on.html

 I'm not sure which part of that blog post you're referring to. This
 sentence indicates that `close()` should be called once:

 > The intent of that statement, at least from the perspective of the WSGI
 server, is that close() only be called once all content has been consumed
 from the iterable and that content has been sent to the client.

 Furthermore, `close()` can usually be called on objects that are already
 closed; it just does nothing.

 > 3. Returning `self._iterator` directly in
 `HttpStreamingResponse.streaming_content`, instead of a new iterator that
 yields bytestrings means that middleware authors can't expect consistent
 bytestring chunks when wrapping streaming_content in a new iterator? They
 may have to type check or coerce each chunk (potentially reproducing
 something like `make_bytes()`? For comparison, `HttpResponse.content`
 always returns a bytestring.

 That's what #18796 is about: normalizing the conversion of the content to
 `bytes` (which is moot because content is already `bytes` in 99.99% of
 responses).

 I'll copy your remark over there.

 > 4. There may still be a case for consuming iterators assigned to
 `HttpResponse.content` immediately, rather than on first access. Maybe
 after a deprecation period, though? If `HttpResponse._container` is an
 iterator, the response can't be pickled by cache middleware.

 If that's true, it's a bug of the cache middleware, which can easily be
 fixed by making it access `response.content`. If that bug wasn't reported
 yet, could you create a new ticket?

 > It would also allow additional content to be written to the response.
 This is probably an issue for another ticket, anyway.

 Allowing writes to a regular response instantiated with an iterator is
 #6527. I've uploaded a patch extracted from your work over there.

 > 5. We should add an `ETag` header in the `serve()` view, if etags are
 enabled in settings. ETags are normally added by `CommonMiddleware`, but
 middleware can't calculate an ETag for a streaming response, and we do
 have access to the raw file in `serve()` so it should be done there (like
 we do for `Last-Modified` and `Content-Length`).

 This never came into the discussion until now, could you create a new
 ticket for this feature request?

 > 6. The note in the docs about iterators being closed after the response
 is iterated as a point of difference from regular responses is not true
 anymore. We rely on WSGI to call `close()` on both regular and streaming
 responses.

 I'll fix that.

 > 7. The `http_utils` test wasn't included?

 Oops, my git-fu must have failed me. I'll commet them separately.

-- 
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] #18796: Refactor HttpResponse.__iter__ / _get_content

[Django]

#18796: Refactor HttpResponse.__iter__ / _get_content
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  HTTP handling|   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 aaugustin):

 * owner:  nobody => aaugustin


-- 
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] #7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse objects.

[Django]

#7581: Middleware accessing HttpResponse.content breaks streaming HttpResponse
objects.
-+-
 Reporter:  mrmachine|Owner:  ccahoon
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  stream HttpResponse  | Triage Stage:  Accepted
  Content-Length |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by mrmachine):

 Excellent. Very happy to see this committed. I have a couple of comments
 that may or may not be important.

 1. We're not checking if the `close` attribute on assigned content is
 callable before adding it to `_closable_objects`? Probably an edge case
 not worth worrying about, though.

 2. Should we pop closable objects off the list before closing them (or
 just empty the list after closing all items), so that multiple calls to
 `close()` don't re-attempt to close objects already closed? Graham's blog
 seems to indicate that multiple WSGI middleware may each call `close()` on
 the response? http://blog.dscpl.com.au/2012/10/obligations-for-calling-
 close-on.html

 3. Returning `self._iterator` directly in
 `HttpStreamingResponse.streaming_content`, instead of a new iterator that
 yields bytestrings means that middleware authors can't expect consistent
 bytestring chunks when wrapping streaming_content in a new iterator? They
 may have to type check or coerce each chunk (potentially reproducing
 something like `make_bytes()`? For comparison, `HttpResponse.content`
 always returns a bytestring.

 4. There may still be a case for consuming iterators assigned to
 `HttpResponse.content` immediately, rather than on first access. Maybe
 after a deprecation period, though? If `HttpResponse._container` is an
 iterator, the response can't be pickled by cache middleware. It would also
 allow additional content to be written to the response. This is probably
 an issue for another ticket, anyway.

 5. We should add an `ETag` header in the `serve()` view, if etags are
 enabled in settings. ETags are normally added by `CommonMiddleware`, but
 middleware can't calculate an ETag for a streaming response, and we do
 have access to the raw file in `serve()` so it should be done there (like
 we do for `Last-Modified` and `Content-Length`).

 6. The note in the docs about iterators being closed after the response is
 iterated as a point of difference from regular responses is not true
 anymore. We rely on WSGI to call `close()` on both regular and streaming
 responses.

 7. The `http_utils` test wasn't included?

-- 
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] #16671: 5th tutorial on turning Polls into a reusable app

[Django]

#16671: 5th tutorial on turning Polls into a reusable app
---+
 Reporter:  stumbles   |Owner:  ben@…
 Type:  New feature|   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
---+

Comment (by russellm):

 I'm happy keeping the link to djangopackages.com; it's a reasonably robust
 part of the community, and we can start negotiations with Danny about
 making the arrangement a little more formal.

 And yes, my objection was to the tutorial05 part in the URL. If that's
 just a build artefact, that's fine - I just raising it in case it was the
 proposed location in the source tree.

-- 
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] #19141: Git tags for new versions

[Django]

#19141: Git tags for new versions
-+-
 Reporter:  saippuakauppias  |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Djangoproject.com|  Version:  1.3
  Web site   |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  git, tags|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by Architekt):

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


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

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