Re: [Django] #27119: full_clean() called too many times during formset validation

[Django]

#27119: full_clean() called too many times during formset validation
-+-
 Reporter:  claudep  |Owner:  DavidFozo
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by DavidFozo):

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


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

Re: [Django] #27183: JSONField improperly escaped in admin interface during normal usage (was: JSONField escaped in admin interface during normal usage)

[Django]

#27183: JSONField improperly escaped in admin interface during normal usage
---+--
 Reporter:  sjuxax |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by sjuxax):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.7393f88b176f37fc9c097daefadcd766%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27183: JSONField escaped in admin interface during normal usage

[Django]

#27183: JSONField escaped in admin interface during normal usage
---+
 Reporter:  sjuxax |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The line of code at
 
https://github.com/django/django/blob/68de48c96328e13d5dbdb1f3006e4a1ca74f3c34/django/contrib/postgres/forms/jsonb.py#L45
 results in the escaping of a plain JSON string. That's because the string
 is already in valid JSON when run through json.dumps. This is user-facing
 and visible in the Django admin interface when a JSONField is edited.

 With the current code, the line in the admin looks like this:
 http://imgur.com/fw29t1c.jpg

 If we just return value instead of json.dumps(value), we get this:
 http://imgur.com/msBT1tI.jpg

 (Someone may want to attach those jpgs directly to this report for
 posterity; I don't know what the convention is on this bug tracker)

 In fact, looking at the code now, I wonder if we just need to swap lines
 44 and 45. It would seem that if a value is invalid JSON, as the check on
 line 43 implies, that we *should* be dumping it through the json
 serializer, whereas if it's valid JSON, we shouldn't. Maybe the logic just
 got swapped there.

 #25532 deals with a similar topic.

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

Re: [Django] #27182: Some import statement use backslashes instead of parentheses

[Django]

#27182: Some import statement use backslashes instead of parentheses
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 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
-+-
Changes (by timgraham):

 * stage:  Accepted => Someday/Maybe


Comment:

 Bumping to Someday/Maybe as it's not actionable until the isort issue
 fixed. I explained in #27173 why changing isort's `max_line_length` isn't
 desired.

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

Re: [Django] #27173: Permit import statements to be longer than 80 characters

[Django]

#27173: Permit import statements to be longer than 80 characters
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I don't think longer import lengths will help readability except for the
 backslashes case. I don't mind changing those instances if the
 [https://github.com/timothycrosley/isort/issues/466 isort issue] you
 created is fixed but rewriting all imports in Django to a new length is a
 no go for me. Maybe you don't realize that if we changed to `[isort]
 line_length = 119`, that would create a 6K line patch for Django.

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

Re: [Django] #27179: Bug: error when trying to filter using regex/iregex on a key in a django.contrib.postgres.fields.JSONField

[Django]

#27179: Bug: error when trying to filter using regex/iregex on a key in a
django.contrib.postgres.fields.JSONField
--+
 Reporter:  jrhouston |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.10
 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 charettes):

 * stage:  Unreviewed => Accepted


Comment:

 While working on #26511 I also noticed we should wrap the key access
 expression
 [https://github.com/django/django/compare/django:9a2a525...charettes:05b5792
 #diff-57ceaae67721b3f8d5729222c032af8eR85 in parentheses].

 @jrhouston you might be interested to know  that `(field -> key)::text` is
 going to get you the text representation of the JSON key you're accessing
 (`'(('{"foo": "bar"}'::jsonb) -> 'bar')::text` will get you `'"bar"'`.
 What you want to use here is the `->>` operator (`('{"foo":
 "bar"}'::jsonb) ->> 'bar'` == `'bar'`).

 I'm not sure how we can teach the ORM to use `->>` in a backward
 compatible way at this point, we might have to introduce a new expression
 for this purpose like I suggested in  #26511.

 In the mean time I propose [https://github.com/django/django/pull/7210 we
 add these parentheses] but it would be great to have regression tests not
 relying on built-in lookups meant to be only available on `CharField` or
 `TextField` as their removal or replacement are tracked in another ticket
 if I'm not mistaken.

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

Re: [Django] #27182: Some import statement use backslashes instead of parentheses

[Django]

#27182: Some import statement use backslashes instead of parentheses
--+
 Reporter:  cjerdonek |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  1.10
 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 cjerdonek):

 For the record, most (or perhaps all, I haven't checked) of these
 occurrences would also go away if Django's `line_length` isort setting
 (direct link
 
[https://github.com/django/django/blob/9a2a52558e080f109a27d40a033a135c9d0e7e50/setup.cfg#L15
 here]) were increased from 79 to something longer like 119. Even though
 Django's coding style permits up to 119 characters, the isort
 configuration setting has the effect of making 79 a hard limit instead of
 a soft one in the case of import statements.

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

Re: [Django] #27182: Some import statement use backslashes instead of parentheses

[Django]

#27182: Some import statement use backslashes instead of parentheses
--+
 Reporter:  cjerdonek |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  1.10
 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 aaugustin):

 * component:  Uncategorized => Core (Other)
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 That would indeed be nice to fix. We have always been at war with
 backslashes.

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

Re: [Django] #24865: Add a management command to remove stale content types

[Django]

#24865: Add a management command to remove stale content types
-+-
 Reporter:  Protosac |Owner:
 Type:  New feature  |   Status:  new
Component:   |  Version:  master
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  stale contenttypes   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by charettes):

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

Re: [Django] #26170: ModelAdmin add/change/delete views always run transaction on default database

[Django]

#26170: ModelAdmin add/change/delete views always run transaction on default
database
--+
 Reporter:  juntatalor|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  admin multi database  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by charettes):

 * needs_better_patch:  0 => 1
 * version:  1.9 => master
 * needs_tests:  1 => 0


Comment:

 The new [https://github.com/django/django/pull/7143 PR] includes tests but
 doesn't deal with the `django/contrib/auth/admin.py` instance yet.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/068.ec7743952f999850fb1d6a71e55aea87%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27173: Permit import statements to be longer than 80 characters

[Django]

#27173: Permit import statements to be longer than 80 characters
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by cjerdonek):

 My main concern is that it will make it difficult to sort imports manually
 as people who have a right margin at 80 characters would need to change it
 just for this.

 I'm not sure I understand this argument. It seems like this just shifts
 the problem from "people who have a right margin at 80 characters" to
 "everyone" since now the lines that need to be sorted always get broken
 across more than one line, regardless of how one's right margin is set.
 Here is one example from the code base (in `sessions_tests.tests`):

 {{{#!python
 from django.contrib.sessions.backends.cache import SessionStore as
 CacheSession
 from django.contrib.sessions.backends.cached_db import \
 SessionStore as CacheDBSession
 from django.contrib.sessions.backends.db import SessionStore as
 DatabaseSession
 from django.contrib.sessions.backends.file import SessionStore as
 FileSession
 from django.contrib.sessions.backends.signed_cookies import \
 SessionStore as CookieSession
 from django.contrib.sessions.exceptions import InvalidSessionKey
 from django.contrib.sessions.middleware import SessionMiddleware
 from django.contrib.sessions.models import Session
 from django.contrib.sessions.serializers import (
 JSONSerializer, PickleSerializer,
 )
 from django.core import management
 }}}

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

Re: [Django] #27182: Some import statement use backslashes instead of parentheses

[Django]

#27182: Some import statement use backslashes instead of parentheses
---+--
 Reporter:  cjerdonek  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by cjerdonek):

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


Old description:

> Some import statements in Django's code base use backslashes to break
> long lines instead of parentheses (at least 21 occurrences if you search
> the code base for "`import \`"). Here is one example (direct link
> [https://github.com/django/django/blob/9a2a52558e080f109a27d40a033a135c9d0e7e50/django/contrib/gis/db/backends/mysql/base.py#L1
> here]):
>
> {{{#!python
> from django.db.backends.mysql.base import \
> DatabaseWrapper as MySQLDatabaseWrapper
> }}}
>
> These go against Django's coding style standards, which
> [https://docs.djangoproject.com/en/dev/internals/contributing/writing-
> code/coding-style/#imports say in the "Imports" section to use
> parentheses]:
>
>  Break long lines using parentheses and indent continuation lines by 4
> spaces.
>
> Django's coding style also says to follow PEP 8, which says this:
>
>  The preferred way of wrapping long lines is by using Python's implied
> line continuation inside parentheses, brackets and braces. Long lines can
> be broken over multiple lines by wrapping expressions in parentheses.
> These should be used in preference to using a backslash for line
> continuation.
>
> I believe this issue is caused by a bug in isort, since the isort section
> of Django's `setup.cfg`
> [https://github.com/django/django/blob/9a2a52558e080f109a27d40a033a135c9d0e7e50/setup.cfg#L16
> already sets] `multi_line_output=5` (which means to use parentheses). I
> tried filing an issue about this
> [https://github.com/timothycrosley/isort/issues/466 here].

New description:

 Some import statements in Django's code base use backslashes to break long
 lines instead of parentheses (at least 21 occurrences if you search the
 code base for "`import \`"). Here is one example (direct link
 
[https://github.com/django/django/blob/9a2a52558e080f109a27d40a033a135c9d0e7e50/django/contrib/gis/db/backends/mysql/base.py#L1
 here]):

 {{{#!python
 from django.db.backends.mysql.base import \
 DatabaseWrapper as MySQLDatabaseWrapper
 }}}

 These go against Django's coding style standards, which say in the
 "Imports" section
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /coding-style/#imports to use parentheses]:

  Break long lines using parentheses and indent continuation lines by 4
 spaces.

 Django's coding style also says to follow PEP 8, which says this:

  The preferred way of wrapping long lines is by using Python's implied
 line continuation inside parentheses, brackets and braces. Long lines can
 be broken over multiple lines by wrapping expressions in parentheses.
 These should be used in preference to using a backslash for line
 continuation.

 I believe this issue is caused by a bug in isort, since the isort section
 of Django's `setup.cfg`
 
[https://github.com/django/django/blob/9a2a52558e080f109a27d40a033a135c9d0e7e50/setup.cfg#L16
 already sets] `multi_line_output=5` (which means to use parentheses). I
 tried filing an issue about this
 [https://github.com/timothycrosley/isort/issues/466 here].

--

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.fe04dd022a20c7f45679d3d14255f85f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27182: Some import statement use backslashes instead of parentheses

[Django]

#27182: Some import statement use backslashes instead of parentheses
---+
 Reporter:  cjerdonek  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Some import statements in Django's code base use backslashes to break long
 lines instead of parentheses (at least 21 occurrences if you search the
 code base for "`import \`"). Here is one example (direct link
 
[https://github.com/django/django/blob/9a2a52558e080f109a27d40a033a135c9d0e7e50/django/contrib/gis/db/backends/mysql/base.py#L1
 here]):

 {{{#!python
 from django.db.backends.mysql.base import \
 DatabaseWrapper as MySQLDatabaseWrapper
 }}}

 These go against Django's coding style standards, which
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /coding-style/#imports say in the "Imports" section to use parentheses]:

  Break long lines using parentheses and indent continuation lines by 4
 spaces.

 Django's coding style also says to follow PEP 8, which says this:

  The preferred way of wrapping long lines is by using Python's implied
 line continuation inside parentheses, brackets and braces. Long lines can
 be broken over multiple lines by wrapping expressions in parentheses.
 These should be used in preference to using a backslash for line
 continuation.

 I believe this issue is caused by a bug in isort, since the isort section
 of Django's `setup.cfg`
 
[https://github.com/django/django/blob/9a2a52558e080f109a27d40a033a135c9d0e7e50/setup.cfg#L16
 already sets] `multi_line_output=5` (which means to use parentheses). I
 tried filing an issue about this
 [https://github.com/timothycrosley/isort/issues/466 here].

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.7dbdbc15301853f74893064176b191b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27179: Bug: error when trying to filter using regex/iregex on a key in a django.contrib.postgres.fields.JSONField

[Django]

#27179: Bug: error when trying to filter using regex/iregex on a key in a
django.contrib.postgres.fields.JSONField
--+--
 Reporter:  jrhouston |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by jrhouston):

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

[Django] #27181: Sites framework does not normalize domains with trailing "."

[Django]

#27181: Sites framework does not normalize domains with trailing "."
---+
 Reporter:  bluetech   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.sites  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have a Django project which uses the sites framework. The site is picked
 by the {{{Host}}} and not by setting {{{SITE_ID}}}. Suppose one of the
 domains is "mysite.com". In DNS, this is equivalent to "mysite.com." (note
 the trailing dot). The nginx webserver, uwsgi, and Django's own
 {{{ALLOWED_HOSTS}}} accept "mysite.com." where "mysite.com" is specified.
 For example, the {{{validate_host()}}} function in http/request.py has
 this line:

 {{{
 host = host[:-1] if host.endswith('.') else host
 }}}

 which strips the trailing dot if it exists, before matching (this code is
 not ideal BTW, I think it will not work as intended if the host has a
 port).

 However, the sites framework (in contrib/sites/models.py,
 {{{SiteManager._get_site_by_request}}}) fails to match in this case. This
 causes 500 when {{{get_current_site()}}} is called whenever a user
 requests some URL like "http://mysite.com./;.

 It would be nice if the sites framework was fixed to match trailing dot as
 well, similar to how https://code.djangoproject.com/ticket/24834 was fixed
 to deal with a {{{Host}}} like "mysite.com:80".

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

[Django] #27180: Check for sql_mode fails during migration with special database connections

[Django]

#27180: Check for sql_mode fails during migration with special database 
connections
+
 Reporter:  gerricom|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.10
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I believe I found again a bug regarding some special database connections
 (like #26991):

 Running `migrate` raises this error:


 {{{
 Traceback (most recent call last):
   File "manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 359, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 294, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 342, in execute
 self.check()
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 374, in check
 include_deployment_checks=include_deployment_checks,
   File "/usr/local/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py", line 61, in
 _run_checks
 issues = run_checks(tags=[Tags.database])
   File "/usr/local/lib/python2.7/site-
 packages/django/core/checks/registry.py", line 81, in run_checks
 new_errors = check(app_configs=app_configs)
   File "/usr/local/lib/python2.7/site-
 packages/django/core/checks/database.py", line 10, in
 check_database_backends
 issues.extend(conn.validation.check(**kwargs))
   File "/usr/local/lib/python2.7/site-
 packages/django/db/backends/mysql/validation.py", line 9, in check
 issues.extend(self._check_sql_mode(**kwargs))
   File "/usr/local/lib/python2.7/site-
 packages/django/db/backends/mysql/validation.py", line 16, in
 _check_sql_mode
 modes = set(sql_mode[0].split(','))
 TypeError: 'NoneType' object has no attribute '__getitem__'
 }}}

 The reason is, that `SELECT @@sql_mode` returns no results in my special
 case.

 Just a little side note: `migrate` runs database checks against all
 database connections, no matter if a database is selected via the
 `--database` parameter or if migrations are not allowed because of a
 database router. I'm not quite sure if this works as intended.

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

Re: [Django] #27179: Bug: error when trying to filter using regex/iregex on a key in a django.contrib.postgres.fields.JSONField

[Django]

#27179: Bug: error when trying to filter using regex/iregex on a key in a
django.contrib.postgres.fields.JSONField
--+--
 Reporter:  jrhouston |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:
 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 DavidFozo):

 * owner:  DavidFozo =>
 * status:  assigned => new


Comment:

 Someone wrote a patch, before I did.

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

Re: [Django] #27159: Pickling query from queryset causes unintended queryset evaluation

[Django]

#27159: Pickling query from queryset causes unintended queryset evaluation
-+-
 Reporter:  jtiai|Owner:  DavidFozo
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (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
-+-
Changes (by DavidFozo):

 * owner:  nobody => DavidFozo
 * 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/063.1169ff6dd121b02da214cc2f162ce04a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27179: Bug: error when trying to filter using regex/iregex on a key in a django.contrib.postgres.fields.JSONField

[Django]

#27179: Bug: error when trying to filter using regex/iregex on a key in a
django.contrib.postgres.fields.JSONField
--+--
 Reporter:  jrhouston |Owner:  DavidFozo
 Type:  Bug   |   Status:  assigned
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:
 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 DavidFozo):

 * owner:   => DavidFozo
 * needs_better_patch:   => 0
 * status:  new => assigned
 * 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 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.434f767cab8af7a28d998b8b09e6c4e2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27179: Bug: error when trying to filter using regex/iregex on a key in a django.contrib.postgres.fields.JSONField

[Django]

#27179: Bug: error when trying to filter using regex/iregex on a key in a
django.contrib.postgres.fields.JSONField
--+--
 Reporter:  jrhouston |  Owner:
 Type:  Bug   | Status:  new
Component:  contrib.postgres  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  1 |  UI/UX:  0
--+--
 When trying use regex to query on a key within a postgres JSONField.

 {{{
 TestModel.objects.filter(field__subkey__regex=r'test')
 }}}

 Generates SQL which produces the following error:

 {{{
 LINE 1: ...WHERE "test_testmodel"."field" -> 'subkey'::text ~ 'test'
 ^
 HINT:  No operator matches the given name and argument type(s). You might
 need to add explicit type casts.
 }}}

 This seems to be a precedence issue, and adding parenthesis before the
 extracted key is cast to `::text` allows the query to run successfully.
 i.e:

 {{{
 WHERE ("test_testmodel"."field" -> 'subkey')::text ~ 'test'
 }}}

 Adding the parenthesis here seems to fix the issue:
 
https://github.com/django/django/blob/master/django/contrib/postgres/fields/jsonb.py#L109

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

Re: [Django] #27172: Close cursor in custom SQL example

[Django]

#27172: Close cursor in custom SQL example
--+
 Reporter:  cjerdonek |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
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:  0 |UI/UX:  0
--+
Changes (by timgraham):

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


Comment:

 Is there any advantage to also updating the `PollManager` example in
 topics/db/managers.txt?

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

Re: [Django] #27178: ImageField when default provided in model, it's impossible to change the value.

[Django]

#27178: ImageField when default provided in model, it's impossible to change the
value.
---+--
 Reporter:  phonkee|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by phonkee):

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


Old description:

> When I set model with ImageField that has default value set, it's
> impossible to change this value.
>
> class TestModel(models.Model)
> image = ImageField(default="default.jpg")
>
> Now it's impossible to change the value from ModelForm's and/or admin.

New description:

 When I set model with ImageField that has default value set, it's
 impossible to change this value.

 class TestModel(models.Model)
 image = ImageField(default="default.jpg")

 Now it's impossible to change the value from ModelForm's and/or admin.

--

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

[Django] #27178: ImageField when default provided in model, it's impossible to change the value.

[Django]

#27178: ImageField when default provided in model, it's impossible to change the
value.
---+
 Reporter:  phonkee|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When I set model with ImageField that has default value set, it's
 impossible to change this value.

 class TestModel(models.Model)
 image = ImageField(default="default.jpg")

 Now it's impossible to change the value from ModelForm's and/or admin.

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

Re: [Django] #27176: django.setup() should raise an exception instead of hanging on re-entrant calls

[Django]

#27176: django.setup() should raise an exception instead of hanging on 
re-entrant
calls
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  app-loading   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

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

Re: [Django] #27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2 (was: Explicitly define where string comes from)

[Django]

#27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2
-+-
 Reporter:  hckrtst  |Owner:  ankur0493
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  docs | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_docs:  1 => 0
 * 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/065.cadd1821610dff9475784562359928e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27175: Deprecate silencing exceptions raised while rendering the {% include %} template tag

[Django]

#27175: Deprecate silencing exceptions raised while rendering the {% include %}
template tag
--+
 Reporter:  jdufresne |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  master
 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 timgraham):

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

Re: [Django] #27173: Permit import statements to be longer than 80 characters

[Django]

#27173: Permit import statements to be longer than 80 characters
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Uncategorized => Core (Other)
 * type:  Uncategorized => Cleanup/optimization


Comment:

 We discussed import line length when adding the isort configuration. My
 main concern is that it will make it difficult to sort imports manually as
 people who have a right margin at 80 characters would need to change it
 just for this. We prefer longer lines "when it helps readability". I don't
 think there's much difference in readability of imports, so I prefer to
 keep things simple.

 You could mark those lines with `# isort:skip` to use a longer length but
 I don't see much advantage.

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

Re: [Django] #25788: Enable the cached template loader when DEBUG=False if no loaders are explicitly configured

[Django]

#25788: Enable the cached template loader when DEBUG=False if no loaders are
explicitly configured
-+-
 Reporter:  jaap3|Owner:
 |  harrislapiroff
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | 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 jaap3):

 Thanks Harris/Tim! Just one question, how does this impact #25791?

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

Re: [Django] #27174: Explicitly define where string comes from

[Django]

#27174: Explicitly define where string comes from
-+-
 Reporter:  hckrtst  |Owner:  ankur0493
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  docs | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by ankur0493):

 Does someone reviews this or should I just make the 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 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.1415762073e90a611ed5bfb08814c4be%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.