Re: [Django] #20147: Provide an alternative to request.META for accessing HTTP headers

[Django]

#20147: Provide an alternative to request.META for accessing HTTP headers
---+---
 Reporter:  Luke Plant |Owner:  santiagobasulto
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by Zach Borboa):

 * cc: Zach Borboa (added)


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

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

Re: [Django] #28901: Document considerations with read committed isolation level and InnoDB

[Django]

#28901: Document considerations with read committed isolation level and InnoDB
-+-
 Reporter:  Dirkjan Ochtman  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 Django can't override binlog_format since it is set on the server level
 only, which requires either super privilege (django apps shouldn't have
 this) or editing the config file. Also it has a huge number of
 considerations, see https://mariadb.com/kb/en/library/binary-log-formats/
 .

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

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

[Django] #29602: Django 2.0 breaks interop with Jinja2 forceescape filter

[Django]

#29602: Django 2.0 breaks interop with Jinja2 forceescape filter
---+
   Reporter:  Richard Eames|  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Template system  |Version:  2.0
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 Not sure if this is a Django bug, jinja bug, or something I need to change
 for upgrading to Django 2.0, but since it was a Django commit causes it,
 I'm reporting here first.

 I recently upgraded to Django 2.0, and shortly after had a complaint from
 one of our users about a page not displaying correctly. I tracked down the
 issue to a usage of Jinja's `forceescape` filter.

 My usage is that we're displaying a preview of an email that will be sent
 out, and we do this by using the `srcdoc` attribute of iframe, so our code
 looks like:

 {{{
 
 }}}

 The `rendered_email` variable is from a call to
 `get_template(template_name).render(ctx)`, which returns a `SafeString`
 object. Which makes sense since a rendered template should be html. And
 since I want to  display the email inside of html again, it needs to be
 re-escape, logically with the `forceescape` filter.

 However, a change from [https://code.djangoproject.com/ticket/27795 this
 
ticket]/[https://github.com/django/django/commit/ccfd1295f986cdf628d774937d0b38a14584721f
 #diff-58d9f7a5099962dc591a93a47a671b72 this commit] causes the
 `forceescape` filter to fail on the jinja side. `forcescape` calls `str()`
 on it's argument to remove the "safety", then re-escapes it, however, the
 aforementioned commit allow `SafeString` to bypass the assumption that
 jinja makes when calling `str()`.

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

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

Re: [Django] #29600: Remove usage of django.utils.datetime_safe where possible

[Django]

#29600: Remove usage of django.utils.datetime_safe where possible
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"013d439ff038ca8e750e6d1dcd6965f33ad4cf3e" 013d439f]:
 {{{
 #!CommitTicketReference repository=""
 revision="013d439ff038ca8e750e6d1dcd6965f33ad4cf3e"
 Refs #29600 -- Added test for datetime_safe usage in localize_input().
 }}}

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

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

Re: [Django] #29600: Remove usage of django.utils.datetime_safe where possible

[Django]

#29600: Remove usage of django.utils.datetime_safe where possible
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"76852c398943cf8a3b7a517f05614df3e47970c8" 76852c39]:
 {{{
 #!CommitTicketReference repository=""
 revision="76852c398943cf8a3b7a517f05614df3e47970c8"
 Refs #29600 -- Added test for datetime_safe usage in
 SelectDateWidget.value_from_datadict().
 }}}

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

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

Re: [Django] #29597: AttributeError when django.template.context_processors.debug is invoked with null request

[Django]

#29597: AttributeError when django.template.context_processors.debug is invoked
with null request
-+--
 Reporter:  eshellman|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+--
Changes (by eshellman):

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


Comment:

 Sorry, my bug

 this was caused by code that looked like this:

 {{{
 context = {a_dict}
 render_to_string(template_name, {another_dict}, context)
 }}}


 because the signature of the method is

 {{{
 def render_to_string(template_name, context=None, request=None,
 using=None)
 }}}
 I missed that request was getting another_dict.

 the code was originally targeted at the 1.5.12 signature

 {{{
 render_to_string(template_name, dictionary=None, context_instance=None)
 }}}
 but it worked in 1.8, and didn't break till 1.11.

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

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

Re: [Django] #29599: chunk_size for InMemoryUploadedFile is not used

[Django]

#29599: chunk_size for InMemoryUploadedFile is not used
-+-
 Reporter:  Ali Aliyev   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  File |  Version:  master
  uploads/storage|
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  chunks   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ali Aliyev):

 Thanks for the quick response!

 I have my own file storage class  where `_save` method is called:
 https://github.com/django/django/blob/master/django/core/files/storage.py#L49
 The problem is that I have to upload chunks (each chunks should not be
 more than 4mb) but `content` is instance of the `InMemoryUploadedFile` in
 which case I had to implement my own `chunks` method:

 {{{
 class AzureStorage(Storage):
 ...
 def _read_in_chunks(self, file_object, chunk_size=1024):
 while True:
 data = file_object.read(chunk_size)
 if not data:
 break
 yield data

 def _save(self, name, content):
 if hasattr(content.file, 'content_type'):
 content_type = content.file.content_type
 else:
 content_type = mimetypes.guess_type(name)[0]

 chunks = self._read_in_chunks(
 content,
 settings.AZURE_CHUNK_SIZE * 1024 * 1024
 )

 blocks_list = []

 for chunk in chunks:
 block_id = uuid.uuid4()
 self.connection.put_block(self.azure_container, name, chunk,
 block_id)
 blocks_list.append(str(block_id))

 self.connection.put_block_list(
 self.azure_container,
 name,
 blocks_list,
 x_ms_blob_content_type=content_type
 )

 return name
 }}}

 so `content.cunks` will not work here

 Replying to [comment:1 Carlton Gibson]:
 > > is it okay...
 >
 > Yes.
 >
 > In general, why do you handle a file in chunks? So that you can control
 how much is in memory at one time.
 >
 > With `InMemoryUploadedFile` you already decided you'd handle the whole
 thing in memory at once.
 > So the idea of handling it in `chunks` doesn't really make sense.
 >
 > (See
 
[https://github.com/django/django/blob/1c05fe65f280cedaddf5e5f308e5e45449b02e93/django/core/files/uploadedfile.py#L95
 the comment a few lines below].)

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

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

Re: [Django] #29600: Remove usage of django.utils.datetime_safe where possible

[Django]

#29600: Remove usage of django.utils.datetime_safe where possible
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"2ac7cd52b466e5090c0479de02c4765b4c483fa3" 2ac7cd5]:
 {{{
 #!CommitTicketReference repository=""
 revision="2ac7cd52b466e5090c0479de02c4765b4c483fa3"
 Refs #29600 -- Removed datetime_safe usage in feedgenerator.

 The only effect would be if items in Atom feeds had a published date
 year of < 1000 (ensuring those years are padded with leading zeros).
 }}}

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

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

Re: [Django] #3373: verbose_name_plural and internationalization

[Django]

#3373: verbose_name_plural and internationalization
-+-
 Reporter:  Vitek|Owner:  hugo
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  pluralization i18n   | Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Dylan, feel free to write to the DevelopersMailingList with your proposal.

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

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

Re: [Django] #29595: Allow using timedelta in migrations questioner

[Django]

#29595: Allow using timedelta in migrations questioner
---+
 Reporter:  Bas ten Berge  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  Version:  2.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 Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/10230 PR]

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

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

Re: [Django] #3373: verbose_name_plural and internationalization

[Django]

#3373: verbose_name_plural and internationalization
-+-
 Reporter:  Vitek|Owner:  hugo
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  pluralization i18n   | Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Dylan Young):

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


Comment:

 I would reopen this.  The reasons for closing are kind of absurd (consider
 a similat statement: we don't use annotations in our contrib packages, so
 we should ex the QuerySet.annotate method: huh?).

 Aside form that, it simplifies application code: verbose_name and
 verbose_name_plural are collapsed into just verbose_name.

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

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

Re: [Django] #29573: Add link from per-item aggregation topic discussion to `annotate()` ref.

[Django]

#29573: Add link from per-item aggregation topic discussion to `annotate()` ref.
-+-
 Reporter:  Thomas Güttler   |Owner:  Sunitha
 Type:   |  Selvan
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  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 Sunitha Selvan):

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

Re: [Django] #29600: Remove usage of django.utils.datetime_safe where possible

[Django]

#29600: Remove usage of django.utils.datetime_safe where possible
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 Type:   |  Graham
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Tim Graham:

Old description:

> `django.utils.datetime_safe` was added in #1443 to overcome limitations
> in Python 2.7 where `strftime()` doesn't support dates with year < 1900.
> That issue is fixed in Python 3, but an issue remains where the result of
> `strftime('%Y')` [https://bugs.python.org/issue13305 isn't consistent]
> across all platforms. That issue was worked around in #12524.
>
> `strftime()` is no longer used in the JSON serializer as of
> 9b1cb755a28f020e27d4268c214b25315d4de42e, so using `datetime_safe()` is
> obsolete there.
>
> If we remove `dateteime_safe` usage in migrations (it's need is
> questionable), that would fix #29595.

New description:

 `django.utils.datetime_safe` was added in #1443 to overcome limitations in
 Python 2.7 where `strftime()` doesn't support dates with year < 1900. That
 issue is fixed in Python 3, but an issue remains where the result of
 `strftime('%Y')` [https://bugs.python.org/issue13305 isn't consistent]
 across all platforms. That issue was worked around in #12524.

 `strftime()` and `datetime_safe` are no longer used in the JSON serializer
 as of 9b1cb755a28f020e27d4268c214b25315d4de42e but the fix from
 03924929ba212368240bd7a26b14208fba965cb9 may still be useful in the other
 places that `datetime_safe` is used.

 If we remove `dateteime_safe` usage in migrations (its need there is
 questionable, I think), that would fix #29595.

--

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

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

Re: [Django] #29601: Segfault while rendering a template

[Django]

#29601: Segfault while rendering a template
-+-
 Reporter:  Veli-Matti Helke |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  2.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  segfault, template,  | Triage Stage:
  rendering  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Generally a segfault would be blamed on Python or elsewhere as Django
 doesn't contain any C code. Feel free to reopen if you can explain why
 Django is at fault.

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

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

[Django] #29601: Segfault while rendering a template

[Django]

#29601: Segfault while rendering a template
-+-
   Reporter:  Veli-  |  Owner:  nobody
  Matti Helke|
   Type:  Bug| Status:  new
  Component:  Template   |Version:  2.0
  system |   Keywords:  segfault, template,
   Severity:  Normal |  rendering
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have found a segfault in Django 2.0 while rendering a template.

 Detailed info here, and instructions of how to reproduce the fault:
 https://github.com/vhelke/django-cas-crash

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

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

[Django] #29600: Remove usage of django.utils.datetime_safe where possible

[Django]

#29600: Remove usage of django.utils.datetime_safe where possible
-+-
   Reporter:  Tim|  Owner:  Tim Graham
  Graham |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component:  Core   |Version:  master
  (Other)|
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `django.utils.datetime_safe` was added in #1443 to overcome limitations in
 Python 2.7 where `strftime()` doesn't support dates with year < 1900. That
 issue is fixed in Python 3, but an issue remains where the result of
 `strftime('%Y')` [https://bugs.python.org/issue13305 isn't consistent]
 across all platforms. That issue was worked around in #12524.

 `strftime()` is no longer used in the JSON serializer as of
 9b1cb755a28f020e27d4268c214b25315d4de42e, so using `datetime_safe()` is
 obsolete there.

 If we remove `dateteime_safe` usage in migrations (it's need is
 questionable), that would fix #29595.

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

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

Re: [Django] #29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page

[Django]

#29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page
-+-
 Reporter:  Ryan Verner  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  2.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"5180015051f262b73559bb55a8e3fe6f551f8b68" 51800150]:
 {{{
 #!CommitTicketReference repository=""
 revision="5180015051f262b73559bb55a8e3fe6f551f8b68"
 Fixed #29593 -- Added QUERY_TERMS removal to 2.1 release notes.

 Removed in 244cc401559e924355cf943b6b8e66ccf2f6da3a.
 }}}

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

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

Re: [Django] #29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page

[Django]

#29593: Removal of QUERY_TERMS is not in 2.1 "features removed" page
-+-
 Reporter:  Ryan Verner  |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  Documentation|  Version:  2.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"a67ebcb1cbd37e1fc9eddd2da1dda7f319c5ac1d" a67ebcb1]:
 {{{
 #!CommitTicketReference repository=""
 revision="a67ebcb1cbd37e1fc9eddd2da1dda7f319c5ac1d"
 Refs #29593, #26891 -- Doc'd RegisterLookupMixin.get_lookups().
 }}}

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

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

Re: [Django] #26891: ForeignObject/ForeignKey does not obey lookup registration API

[Django]

#26891: ForeignObject/ForeignKey does not obey lookup registration API
-+-
 Reporter:  Ryan P Kilby |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"a67ebcb1cbd37e1fc9eddd2da1dda7f319c5ac1d" a67ebcb1]:
 {{{
 #!CommitTicketReference repository=""
 revision="a67ebcb1cbd37e1fc9eddd2da1dda7f319c5ac1d"
 Refs #29593, #26891 -- Doc'd RegisterLookupMixin.get_lookups().
 }}}

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

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

Re: [Django] #29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField

[Django]

#29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField
--+
 Reporter:  Simon Charette|Owner:  Rowan
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  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
--+

Comment (by Tim Graham):

 See [https://docs.djangoproject.com/en/dev/internals/contributing/writing-
 code/submitting-patches/#deprecating-a-feature Deprecating a feature] for
 a checklist of tasks.

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

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

Re: [Django] #29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField

[Django]

#29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField
--+
 Reporter:  Simon Charette|Owner:  Rowan
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  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
--+

Comment (by Simon Charette):

 Rowan, I think a note mentioning it would be useful.

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

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

Re: [Django] #29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField

[Django]

#29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField
--+
 Reporter:  Simon Charette|Owner:  Rowan
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  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 Rowan):

 * owner:  (none) => Rowan
 * status:  new => assigned


Comment:

 I'd like to help out with this ticket. Should the docs reference the fact
 that the field used to be called `FloatRangeField`, as well?

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

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

Re: [Django] #28668: Add ON CONFLICT support to QuerySet.bulk_create()

[Django]

#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Дилян Палаузов):

 The contributor does not work currently with Django.  To expedite the
 process you can follow what was stated in the last comment.

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

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

Re: [Django] #28668: Add ON CONFLICT support to QuerySet.bulk_create()

[Django]

#28668: Add ON CONFLICT support to QuerySet.bulk_create()
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by shlomoa):

 Replying to [comment:15 Tom Forbes]:
 > Hey, please create a branch on Github and submit a Pull Request with
 these changes if you want them to be reviewed and tested.

 Anyway to contact the contributor to expedite this?

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

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

Re: [Django] #29589: Insert a new method part_page_range for class Page in django.core.paginator.py

[Django]

#29589: Insert a new method part_page_range for class Page in
django.core.paginator.py
--+--
 Reporter:  BobDu |Owner:  BobDu
 Type:  New feature   |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 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
--+--

Comment (by Carlton Gibson):

 The idea here is to generate a subset of page links for a navigation aid
 right?

 Something like (in HTML links):

 {{{

 1, 2, ... 498, 499, 500, 501, 502, 503, ... , 1000
 }}}

 Rather than just outputting all 1000 links at once.

 First question is, is this something we should add in core? (Maybe. Not
 immediately sure what to say.)

 But more, are there already community solutions that do this.

 Django REST Framework provides utilities that do just this for the
 pagination of it's Browsable API templates.
 (See methods called from [https://github.com/encode/django-rest-
 
framework/blob/f404fda29c3c88e344db20f85cab7c51ef44ccdf/rest_framework/pagination.py#L255-L273
 `PageNumberPagination.get_html_context()`].)

 I imagine there will be other solutions also built around Django's
 `Paginator`. Before doing anything in core it would be good to consider
 what those are(?) (Even if that's only for implementation ideas.)

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

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

Re: [Django] #29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField

[Django]

#29598: contrib.postgres.FloatRangeField should be renamed DecimalRangeField
--+
 Reporter:  Simon Charette|Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  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 Carlton Gibson):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #29599: chunk_size for InMemoryUploadedFile is not used

[Django]

#29599: chunk_size for InMemoryUploadedFile is not used
-+-
 Reporter:  Ali Aliyev   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  File |  Version:  master
  uploads/storage|
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  chunks   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 > is it okay...

 Yes.

 In general, why do you handle a file in chunks? So that you can control
 how much is in memory at one time.

 With `InMemoryUploadedFile` you already decided you'd handle the whole
 thing in memory at once.
 So the idea of handling it in `chunks` doesn't really make sense.

 (See
 
[https://github.com/django/django/blob/1c05fe65f280cedaddf5e5f308e5e45449b02e93/django/core/files/uploadedfile.py#L95
 the comment a few lines below].)

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

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

[Django] #29599: chunk_size for InMemoryUploadedFile is not used

[Django]

#29599: chunk_size for InMemoryUploadedFile is not used
+
   Reporter:  Ali Aliyev|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  File uploads/storage  |Version:  master
   Severity:  Normal|   Keywords:  chunks
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Hello,

 is it okay that the `chunk_size` is not used for `InMemoryUploadedFile.
 chunks`?

 Examples to compare:

 
https://github.com/django/django/blob/master/django/core/files/uploadedfile.py#L92
 https://github.com/django/django/blob/master/django/core/files/base.py#L48

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

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