Re: [Django] #23406: Allow migrations to be loaded from .pyc files (e.g. in a frozen environment)

[Django]

#23406: Allow migrations to be loaded from .pyc files (e.g. in a frozen
environment)
-+-
 Reporter:  Daniel Menzel|Owner:  Dan
 |  Watson
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migrations, .pyc,| Triage Stage:  Ready for
  frozen, cx_Freeze  |  checkin
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:"29150d5da880ac1db15e47052330790cf1b802d2" 29150d5d]:
 {{{
 #!CommitTicketReference repository=""
 revision="29150d5da880ac1db15e47052330790cf1b802d2"
 Fixed #23406 -- Allowed migrations to be loaded from .pyc files.
 }}}

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

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

Re: [Django] #28643: Complete the ORM Function Library

[Django]

#28643: Complete the ORM Function Library
-+-
 Reporter:  Matthew Pava |Owner:  JunyiJ
 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
-+-
Description changed by felixxm:

Old description:

> I was surprised to learn that we didn't have a StrIndex function until
> version 2, and yet we had Substr since at least version 1.8.  I wonder
> how users were using Substr without also finding a use for StrIndex this
> whole time.  Anyway, since we seem to be adding these functions one at a
> time, why don't we work on trying to get the built-ins implemented in one
> sweep instead?
>
> We may even want to split the documentation page
> (https://docs.djangoproject.com/en/dev/ref/models/database-functions/)
> into further categories with String functions and Numeric functions.
>
> This is just a sample checklist, with corresponding attributes to which
> backend has them available.
>
> = **Comparison** =||
> ||**Django**||**SQL**||**Description**||**PostgreSQL**||**Oracle**||**MySQL**||**SQLite**||**PR**||
> ||{{{NullIf}}}||{{{NULLIF}}}||Returns {{{NULL}}} if the first argument
> equals the
> second.||‎✔||‎✔||‎✔||‎✔||[https://github.com/django/django/pull/9543
> 9543]||
> = **Math** =||
> ||**Django**||**SQL**||**Description**||**PostgreSQL**||**Oracle**||**MySQL**||**SQLite**||**PR**||
> ||{{{Abs}}}||{{{ABS}}}||Returns the absolute
> value.||‎✔||‎✔||‎✔||‎✔||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{ACos}}}||{{{ACOS}}}||Returns the
> arccosine.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{ASin}}}||{{{ASIN}}}||Returns the
> arcsine.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{ATan}}}||{{{ATAN}}}||Returns the
> arctangent.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{ATan2}}}||{{{ATAN2}}}||Returns the arctangent of the two variables
> passed to
> it.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Ceil}}}||{{{CEILING}}}||Returns the smallest integer value that is
> not less than a numeric
> expression||‎✔||{{{CEIL}}}||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Cos}}}||{{{COS}}}||Returns the cosine expressed in
> radians.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Cot}}}||{{{COT}}}||Returns the
> cotangent.||‎✔||‎✔**^5^**||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Degrees}}}||{{{DEGREES}}}||Returns a numeric expression converted
> from radians to
> degrees.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Exp}}}||{{{EXP}}}||Returns the base of the natural logarithm (e)
> raised to the power of a numeric
> expression.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Floor}}}||{{{FLOOR}}}||Returns the largest integer value that is not
> greater than a numeric
> expression.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Ln}}}||{{{LN}}}||Returns the natural logarithm of a numeric
> expression.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Log}}}||{{{LOG(B, X)}}}||Returns the logarithm of a numeric
> expression.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Mod}}}||{{{MOD}}}||Returns the remainder of one expression by diving
> by another
> expression.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Pi}}}||{{{PI}}}||Returns the value of
> π||‎✔||✔**^4^**||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Power}}}||{{{POWER}}}||Returns the value of one expression raised to
> the power of another
> expression||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Radians}}}||{{{RADIANS}}}||Returns the value of an expression
> converted from degrees to
> radians.||‎✔||‎✔||‎✔||✔**^1^**||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Round}}}||{{{ROUND}}}||Returns a numeric expression rounded to an
> integer.\\Can be used to round an expression to a number of decimal
> points||‎✔||‎✔||‎✔||‎✔||[https://github.com/django/django/pull/9622
> 9622]||
> ||{{{Sin}}}||{{{SIN}}}||Returns the sine given in
> 

Re: [Django] #29249: Add option to dumpdata with unicode JSON

[Django]

#29249: Add option to dumpdata with unicode JSON
-+-
 Reporter:  hakib|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  2.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dumpdata, unicode| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by hakib):

 The JSON serializer has a `ensure_ascii` attribute and the YAML serializer
 has a `allow_unicode` attribute. I already sumitted a
 [PR](https://github.com/django/django/pull/9818#issuecomment-375694612)
 implemeting the flag in both serializers.

 I haven't looked at the XML serializer yet but i'm sure it will be
 possible there as well.

 As someone who works with unicode as the primary language for most apps
 (as i'm sure a lot of other developers do) it's a very a usefull feature
 to be able to dump fixtures directly from local db in a readbale format.

-- 
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.339235936f8dd9394f0e74dbc4ff0d51%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29253: method_decorator() with list argument doesn't copy over attributes of the decorator function (was: method_decorator behaves differently with list argument)

[Django]

#29253: method_decorator() with list argument doesn't copy over attributes of 
the
decorator function
+
 Reporter:  Chris Jerdonek  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Utilities   |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  decorators  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Tim Graham):

 * 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.34084e1b6de8424e5f6111fc61a1e4e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29069: Static file serving does not call request_finished signal

[Django]

#29069: Static file serving does not call request_finished signal
-+-
 Reporter:  André Cruz   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  streamingresponse| Triage Stage:  Accepted
  request_finished   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom Forbes):

 * has_patch:  0 => 1


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

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

Re: [Django] #29069: Static file serving does not call request_finished signal

[Django]

#29069: Static file serving does not call request_finished signal
-+-
 Reporter:  André Cruz   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  streamingresponse| Triage Stage:  Accepted
  request_finished   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Matt Hoskins):

 * cc: Matt Hoskins (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/064.c119c755524d6fa454616359ffebf639%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29069: Static file serving does not call request_finished signal

[Django]

#29069: Static file serving does not call request_finished signal
-+-
 Reporter:  André Cruz   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  streamingresponse| Triage Stage:  Accepted
  request_finished   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Matt Hoskins):

 I just hit this as well - on my dev server, with quite a few test
 instances running under runserver, I hit a postgres server connection
 limit. I noticed that if I did multiple static file requests in a row
 (without accessing a normal django view) I would get a new idle connection
 left after each static connection. If I then did a normal django view
 access it would seem to clear out most of those idle connections.

 In trying to figure out what was going on I also discovered (like Tom)
 that the issue was that request_finished wasn't being triggered for static
 file serving because of the reasons set out by Tom
 (wsgiref.util.FileWrapper being returned) and thus
 django.db.close_old_connections isn't being triggered at the end of
 handling a static file request.

 (I'm not sure why the normal django view access clears up the idle
 connections - perhaps it's just as a result of some python garbage
 collection going off which isn't otherwise happening just when static file
 requests are being processed).

 The suggested PR only helps when using the django provided http server. If
 you use a third party web server that provides wsgi.file_wrapper then
 you'll still have the issue that for FileResponse responses they'll get
 converted to file_wrapper from that third party web server and thus the
 standard django response close handling won't be called.

 One solution is of course to not do that conversion to wsgi.file_wrapper
 at all - however the downside of that is of course that you're not taking
 advantage of the web server's offered performance option of
 wsgi.file_wrapper. Would it be a workable option to wrap
 response.file_to_stream to pass into wsgi.file_wrapper in a way that means
 the standard django response close handling can be hooked (the PEP on
 wsgi.file_wrapper does talk about the requirement for close methods on the
 passed object and its iterable)? If it's not viable, then it may just need
 to be the case that when WSGIHandler makes use of wsgi.file_wrapper it at
 least then calls django.db.close_old_connections after doing the wrapping
 to try clear up connections.

-- 
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.89fe586bc4f99c6535426fa6dfa6675d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29252: Add CSRF protection to LogoutView

[Django]

#29252: Add CSRF protection to LogoutView
-+-
 Reporter:  Filip Dimitrovski|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  denial of| Triage Stage:
  service,csrf   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Duplicate of #15619.

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

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

Re: [Django] #18468: Add the ability to define comments in table / columns

[Django]

#18468: Add the ability to define comments in table / columns
-+-
 Reporter:  Marc Rechté  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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):

 I'm not sure what you mean by "comment for django admin". There isn't an
 existing option with that name.

 As for the implementation, the second approach sounds better.

-- 
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.e2247499242813d15891c6458a5d80c3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29253: method_decorator behaves differently with list argument

[Django]

#29253: method_decorator behaves differently with list argument
+--
 Reporter:  Chris Jerdonek  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Utilities   |  Version:  2.0
 Severity:  Normal  |   Resolution:
 Keywords:  decorators  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Chris Jerdonek):

 The behavior difference described in this ticket is actually noted in the
 discussion of the patch
 [https://github.com/django/django/pull/5136#discussion_r37068407 here],
 but it was thought not important. I do think it's important though
 because, for example, it can cause decorators to have or not have an
 effect depending on which invocation style is used.

-- 
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.90c3fa25b315abd8b67311cd387a570b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25269: Allow method_decorator() to accept a list/tuple of decorators

[Django]

#25269: Allow method_decorator() to accept a list/tuple of decorators
-+-
 Reporter:  zauddelig|Owner:  Tim Graham
 Type:  New feature  |   Status:  closed
Component:  Utilities|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  1.9  | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 FYI, I filed ticket #29253 about the implementation of this feature.

-- 
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.2a0c0c82f03555c0255012b1320444e7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #29253: method_decorator behaves differently with list argument

[Django]

#29253: method_decorator behaves differently with list argument
--+
   Reporter:  Chris Jerdonek  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Utilities   |Version:  2.0
   Severity:  Normal  |   Keywords:  decorators
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 The [https://docs.djangoproject.com/en/2.0/topics/class-based-views/intro
 /#decorating-the-class docs say] that the "list" form of
 `@method_decorator` is equivalent to invoking it multiple times:

 {{{#!python
 decorators = [never_cache, login_required]

 @method_decorator(decorators, name='dispatch')
 class ProtectedView(TemplateView):
 template_name = 'secret.html'

 @method_decorator(never_cache, name='dispatch')
 @method_decorator(login_required, name='dispatch')
 class ProtectedView(TemplateView):
 template_name = 'secret.html'
 }}}

 However, it appears there is a slight difference in behavior. For example:

 {{{#!python
 from django.utils.decorators import method_decorator
 from django.views.decorators.csrf import csrf_exempt

 def my_decorator(func):
 def new_func(*args, **kwargs):
 func(*args, **kwargs)

 return new_func

 @method_decorator(my_decorator, name='dispatch')
 @method_decorator(csrf_exempt, name='dispatch')
 class View1:

 def dispatch(self):
 pass

 @method_decorator([my_decorator, csrf_exempt], name='dispatch')
 class View2:

 def dispatch(self):
 pass

 print(hasattr(View1.dispatch, 'csrf_exempt'))
 print(hasattr(View2.dispatch, 'csrf_exempt'))
 }}}

 results in the output--

 {{{
 True
 False
 }}}

 It appears this is because `method_decorator()` takes a
 
[https://github.com/django/django/blob/ee7f51c66dfc1700ff065dfeb5fe2388cc2e9619/django/utils/decorators.py#L51
 short cut] when processing a list. It doesn't carry over the attributes of
 the decorated function like it does in the normal case.

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

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

Re: [Django] #18468: Add the ability to define comments in table / columns

[Django]

#18468: Add the ability to define comments in table / columns
-+-
 Reporter:  Marc Rechté  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 Ivan Chernoff):

 Anyone?

-- 
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.61729c960770dfd50107f051160a7395%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.