Re: [Django] #29554: Allow loading apps dynamically at runtime

[Django]

#29554: Allow loading apps dynamically at runtime
+--
 Reporter:  Christian González  |Owner:  nobody
 Type:  New feature |   Status:  new
Component:  Core (Other)|  Version:  2.0
 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
+--

Comment (by Aymeric Augustin):

 This proposal removes the guarantees of deterministic behavior that the
 app-loading refactor brought. One example among many: if two apps override
 the same template, which app wins? The order of `INSTALLED_APPS` defines
 this. What happens in the scenario you're proposing?

 I'd like to see a thorough discussion of the pros and cons before making
 this decision as well as an analysis of which caches need to be
 invalidated and how this could happen.

 I wrote extensively about this topic on the django-developers mailing-list
 during the app-loading refactor. As far as I can tell, all this material
 is still relevant, so you should be able to get the list of topics to
 discuss from there. You can also check out my conference talks about app-
 loading.

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

[Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
   Reporter:  obayemi|  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component: |Version:  master
  Uncategorized  |   Keywords:  transaction
   Severity:  Normal |  on_commit decorator
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I recently had to add on_commit hooks with lambdas to some functions
 (mainly email notifications in post_save signals handler)
 That was a lot of boilerplate so I wrote a simple decorator for making a
 function call only trigger on transaction commit

 {{{
 def call_on_commit(f):
 """
 only call the decorated function at transaction commit
 warning the return value will be ignored
 """
 def handle(*args, **kwargs):
 transaction.on_commit(lambda: f(*args, **kwargs))
 return handle
 }}}

 leading to

 {{{
 @call_on_commit
 def send_message(user, context):
 # send message
 }}}
 instead of
 {{{
 def send_message(user, context):
 def _send_message():
 # send message
 on_commit(do_stuff)
 }}}

 I made a PR on github to implement this feature
 https://github.com/django/django/pull/10167

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

Re: [Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
 Reporter:  obayemi  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  transaction  | Triage Stage:
  on_commit decorator|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by obayemi:

Old description:

> I recently had to add on_commit hooks with lambdas to some functions
> (mainly email notifications in post_save signals handler)
> That was a lot of boilerplate so I wrote a simple decorator for making a
> function call only trigger on transaction commit
>
> {{{
> def call_on_commit(f):
> """
> only call the decorated function at transaction commit
> warning the return value will be ignored
> """
> def handle(*args, **kwargs):
> transaction.on_commit(lambda: f(*args, **kwargs))
> return handle
> }}}
>
> leading to
>
> {{{
> @call_on_commit
> def send_message(user, context):
> # send message
> }}}
> instead of
> {{{
> def send_message(user, context):
> def _send_message():
> # send message
> on_commit(do_stuff)
> }}}
>
> I made a PR on github to implement this feature
> https://github.com/django/django/pull/10167

New description:

 I recently had to add on_commit hooks with lambdas to some functions
 (mainly email notifications in post_save signals handler)
 That was a lot of boilerplate so I wrote a simple decorator for making a
 function call only trigger on transaction commit

 {{{
 def call_on_commit(f):
 """
 only call the decorated function at transaction commit
 warning the return value will be ignored
 """
 def handle(*args, **kwargs):
 transaction.on_commit(lambda: f(*args, **kwargs))
 return handle
 }}}

 leading to

 {{{
 @call_on_commit
 def send_message(user, context):
 # send message
 }}}
 instead of
 {{{
 def send_message(user, context):
 def _send_message():
 # send message
 on_commit(do_stuff)
 }}}

 I made a PR on github to implement this feature if it seems relevant
 https://github.com/django/django/pull/10167

--

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

Re: [Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
 Reporter:  obayemi  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  transaction  | Triage Stage:
  on_commit decorator|  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by obayemi):

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

Re: [Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
 Reporter:  obayemi  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  transaction  | Triage Stage:
  on_commit decorator|  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Sergei Maertens):

 * needs_docs:  0 => 1
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:  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/065.a3e5bbd748ea36fa8c278bbec992787e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29129: Child model updates parent model with empty fields making an extra query in multi-inheritance when parent model has custom PK

[Django]

#29129: Child model updates parent model with empty fields making an extra 
query in
multi-inheritance when parent model has custom PK
-+-
 Reporter:  user0007 |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (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 Ashaba John):

 * owner:  Ashaba John => (none)
 * status:  assigned => new


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

Re: [Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
 Reporter:  obayemi  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  transaction  | Triage Stage:
  on_commit decorator|  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: Carlton Gibson (added)


Comment:

 I think you need to explain the usage more fully here.

 I'm expecting this sort of thing:

 {{{
 def send_mail()
 ...

 with transaction.atomic():
 Thing.objects.create(num=num)
 transaction.on_commit(send_mail)
 }}}

 You need to explain how the decorator would work.

 From the docs:

 > If you call on_commit() while there isn’t an active transaction, the
 callback will be executed immediately.

 So you can't just decorate `send_mail()` at the point of declaration here.
 So what would your code look like?

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

Re: [Django] #29556: remove_stale_contenttypes --noinput should delete stale content types (was: remove_stale_contenttypes --noinput should non-interactively delete stale content types)

[Django]

#29556: remove_stale_contenttypes --noinput should delete stale content types
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 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
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Ready for checkin
 * type:  New feature => Bug


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

Re: [Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
 Reporter:  obayemi  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  transaction  | Triage Stage:
  on_commit decorator|  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by obayemi):

 Replying to [comment:4 Carlton Gibson]:
 > I think you need to explain the usage more fully here.
 >
 > I'm expecting this sort of thing:
 >
 > {{{
 > def send_mail()
 > ...
 >
 > with transaction.atomic():
 > Thing.objects.create(...)
 > transaction.on_commit(send_mail)
 > }}}
 >
 > You need to explain how the decorator would work.
 >
 > From the docs:
 >
 > > If you call on_commit() while there isn’t an active transaction, the
 callback will be executed immediately.
 >
 > So you can't just decorate `send_mail()` at the point of declaration
 here. So what would your code look like?

 The decorator don't run the function at the declaration, it only makes
 every usage run at transaction commit, and it would be completely
 transparent for the user as even if no transaction is active it would
 onlybe run synchronously as you stated from the doc
 Manually calling on_commit(function) can work, but it adds some
 boilerplate if your function should always be run at the end of
 transaction, and it is easy to forget

 The decorator would be usefull in two cases
 1) when you have to automatically add every invocation of the function to
 the commit hook instead of running it instantly
 2) when your function is ran by django e.g. post_save on creation when you
 did not finshed filling all the items in a m2m field

 for example, one my actual use case is that I have callbacks that get
 called in post_save in a complex objects that needs a lot of data in
 related objects that with foreignkeys to the objects that was created
 like if you wanted to send a message at every user in a group at creation
 with a post_save signal
 {{{
 with transaction.atomic():
 group = Group.objects.create()
 group.users.add(Users.objects.all()
 }}}
 You would have to do
 {{{
 @receiver(post_save, sender=Group)
 def notify_users(sender, instance, created, *args, **kwargs):
 def _notify_users():  # defining inner function to remove the need to
 pass parameters from context since they can't be used in on_commit hook
 if created:
 for user in group.users.all():
 user.notify_group_creation(group)

 # without on_commit, there wouldn't be any users in the group yet
 on_commit(_notify_users)
 }}}

 where the goal of my decorator is to remove the need to declare an inner
 function and call it in the on_commit hook explicitely which is useless
 boilerplate and indent the whole function one step more if the whole
 function should be ran after the commit
 using this decorator would allow only writing the receiver as
 {{{
 @receiver(post_save, sender=Group)
 @call_on_commit
 def notify_users(sender, instance, created, *args, **kwargs):
 if created:
 for user in group.users.all():
 user.notify_group_creation(group)
 }}}

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

Re: [Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
 Reporter:  obayemi  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  transaction  | Triage Stage:
  on_commit decorator|  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 Hmmm. OK. I see. My immediate thought there is that you would be MUCH
 better avoiding the post save signal and just using the on_commit hook
 straight-forwardly. The control flow would be significantly clearer.

 I'm inclined towards closing this as `wontfix` on that basis. I'll leave
 some time for others to comment though.

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

Re: [Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
 Reporter:  obayemi  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  transaction  | Triage Stage:
  on_commit decorator|  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by obayemi):

 I agree that the workflow could be better without the post_save, but it
 ease the dev a lot IMHO
 that way we can't forget to call the handler everywhere the Models can be
 created and it is simpler to think, (these will be always be called at
 creation, don't need to think about it (isn't this why signals are
 implemented anyway?))

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

Re: [Django] #29557: add on_commit decorator

[Django]

#29557: add on_commit decorator
-+-
 Reporter:  obayemi  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  transaction  | Triage Stage:
  on_commit decorator|  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 > isn't this why signals are implemented anyway?

 Not really. There's a good article on it here:
 [https://lincolnloop.com/blog/django-anti-patterns-signals/ Django Anti-
 Patterns: Signals]

 You really are better off explicitly calling the handler in the places you
 need it. (They'll be few in reality.)

 However, that's an off-topic discussion for 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/065.6026713722ceb3c5258a934b4edee399%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26227: Unicode attachment filename displays incorrectly in some clients

[Django]

#26227: Unicode attachment filename displays incorrectly in some clients
-+-
 Reporter:  Sergey Gornostaev|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  email attachment,| Triage Stage:
  filenames, i18n|  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:

 What are the steps to reproduce the issue? I tried the steps in the ticket
 description and the attachment name looks fine. Also, please test with
 Django master (or at least Django 2.1 beta)  rather than Django 1.11 which
 is quite old at this point.

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

Re: [Django] #29556: remove_stale_contenttypes --noinput should delete stale content types

[Django]

#29556: remove_stale_contenttypes --noinput should delete stale content types
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  master
  contrib.contenttypes   |
 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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"08ebed5e7975b2b735ab8ec0384ccb8e31b76056" 08ebed5e]:
 {{{
 #!CommitTicketReference repository=""
 revision="08ebed5e7975b2b735ab8ec0384ccb8e31b76056"
 Fixed #29556 -- Made 'remove_stale_contenttypes --noinput' delete content
 types.
 }}}

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

Re: [Django] #29554: Allow loading apps dynamically at runtime

[Django]

#29554: Allow loading apps dynamically at runtime
+--
 Reporter:  Christian González  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  Core (Other)|  Version:  2.0
 Severity:  Normal  |   Resolution:  needsinfo
 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 Tim Graham):

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


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

Re: [Django] #29045: admin CSS overrides Select/SelectMultiple size attribute

[Django]

#29045: admin CSS overrides Select/SelectMultiple size attribute
---+
 Reporter:  Jonah Bishop   |Owner:  Jonah Bishop
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.11
 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 Jonah Bishop):

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

Re: [Django] #26227: Unicode attachment filename displays incorrectly in some clients

[Django]

#26227: Unicode attachment filename displays incorrectly in some clients
-+-
 Reporter:  Sergey Gornostaev|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  email attachment,| Triage Stage:
  filenames, i18n|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 I managed to reproduce by sending an email to a @gmail.com address with an
 attachment containing non-ASCII characters on master.

 {{{#!python
 msg = EmailMultiAlternatives('Subject', 'Body', '...@gmail.com', [
 '...@gmail.com'])
 msg.attach(u'Имя файла', BytesIO(b'hello word'), 'text/plain')
 msg.send()
 }}}

 The issue seems to be that GMail ignores RFC2231 header parameters (e.g.
 `filename*=`) and only accepts RFC2047 ones (`filename=?UTF...`).

 The code changes suggested by Thomi include both parameters if the
 attachment name is not ASCII encodable.

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

Re: [Django] #29045: admin CSS overrides Select/SelectMultiple size attribute

[Django]

#29045: admin CSS overrides Select/SelectMultiple size attribute
---+
 Reporter:  Jonah Bishop   |Owner:  Jonah Bishop
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.11
 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 Jonah Bishop):

 * has_patch:  0 => 1


Comment:

 I've added a pull request (https://github.com/django/django/pull/10169)
 with a small patch to fix this issue. The fix was quite simple: a new
 "height: auto;" rule for the select[multiple] style 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/066.4a000ba7ec5c98311dfa21582a363cff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29554: Allow loading apps dynamically at runtime

[Django]

#29554: Allow loading apps dynamically at runtime
+--
 Reporter:  Christian González  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  Core (Other)|  Version:  2.0
 Severity:  Normal  |   Resolution:  needsinfo
 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 Christian González):

 Should I discuss this on the mailing list then, or here?

 Just to answer your questions:
 * regarding the INSTALLED_APPS order: Sure, if you have a stati
 application, this order makes sense. If you have an application that uses
 plugins, the application itself is responsible for the order the plugins
 are loaded. To make this deterministic, would be nonsense IMHO, as
 different applications use different plugin methods (Django provides
 None). So It could be that there is a "plugin resolution order" where
 dependendant plugins are loaded after their dependencies - which makes
 sense, or the app could decide that plugins define an integer "weight"
 (which is no good practice IMHO), etc. So, that's the sense of "dynamic"
 apps.

 * Regarding templates, and which app wins - I always fount the templating
 system a bit difficult - IMHO app templates should have implicit
 namespaces. But that would break virtually any existing Django install -
 so forget it. But: Same as before: The loading order decides, like in
 {{{INSTALLED_APPS}}}. Let the application decide in which order the
 plugins should be loaded.
 In my simple mind, I call {{{apps.populate([myfirstapp_plugin,
 other_plugin, last_plugin_app])}}} like setup.py calls it with
 {{{settings.INSTALLED_APPS}}}. And populate works through all he apps **in
 this order** and merges them into the system.

 I wrote a Django application that merely consists of the plugin system.
 The "real" main application is already a "Core" plugin (with a version
 etc) which is listed in INSTALLED_APPS as app, because it is always loaded
 and part of the base system. And all other plugins are loaded dynamically.
 So they can have dependencies like "core>=1.5.2" and it won't load it when
 the core version is below that. It's pre-alpha, just look here for the
 extension system
 [https://gitlab.com/nerdocs/medux/MedUX/tree/develop/medux/extensionsystem]
 (e.g. the PluginManager, is in development. I'm no professional software
 engineer, so please look away if you see horrible coding style ;-) - or
 better tell me)

 I tried really many ways to accomplish that, and some of the first ones
 were plugins that are no django apps. But I came across some issues, and
 had to rewrite much of the stuff Django does already perfectly, like
 loading models, migrations, etc. So in the sense of DRY, I wanted to have
 plugins being Django apps. But there the problem I describe here starts: I
 have to restart the server, rewriting the settings.py - which is nonsense
 in my eyes.

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

[Django] #29558: Request for more information on past versions of Python

[Django]

#29558: Request for more information on past versions of Python
-+
   Reporter:  Gurmeet Kaur   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |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  |
-+
 Hi Team,

 Me and my team will be developing our first application in Python and we
 will be using SQL Server as backend. I wanted to ask one query regarding
 the versions of Python that have been developed and the ones that are in
 development.

 If we use the current available version of the Python and DJango like -
 Django version - 2.0.7 and Python version - 3.7.0 and Django-msssql - 1.8
 version.

 My first question is : Will they work with Sql Server 2012 and will they
 be compatible working on Windows server?

 My second question(and the most important one) is: If all goes well and we
 deploy application and because of some new feature or for some technical
 reason, we need to update Python but that updation breaks some existing
 issue then what could be the possible solution? In other words, if the
 older version (on which our website is working) is not compatible then
 what can be done in that case?

 Please suggest. It would be of great help if you could help me with the
 response ASAP.

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

Re: [Django] #29558: Request for more information on past versions of Python

[Django]

#29558: Request for more information on past versions of Python
---+--
 Reporter:  Gurmeet Kaur   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  2.0
 Severity:  Normal |   Resolution:  invalid
 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 Carlton Gibson):

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


Comment:

 This channel is for bug reports on Django itself. For a question such as
 your please use the Django Users mailing list.

 https://groups.google.com/forum/m/#!forum/django-users

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

Re: [Django] #11964: Add the ability to use database-level CHECK CONSTRAINTS

[Django]

#11964: Add the ability to use database-level CHECK CONSTRAINTS
-+-
 Reporter:  Matthew Schinckel|Owner:  Ian Foote
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  check constraint | 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 Tim Graham ):

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


Comment:

 In [changeset:"952f05a6db2665d83c04075119285f2164b03432" 952f05a6]:
 {{{
 #!CommitTicketReference repository=""
 revision="952f05a6db2665d83c04075119285f2164b03432"
 Fixed #11964 -- Added support for database check constraints.
 }}}

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

Re: [Django] #29045: admin CSS overrides Select/SelectMultiple size attribute

[Django]

#29045: admin CSS overrides Select/SelectMultiple size attribute
---+
 Reporter:  Jonah Bishop   |Owner:  Jonah Bishop
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.11
 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
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"263e03941187f4ffdd09b7e7ecee442717064083" 263e0394]:
 {{{
 #!CommitTicketReference repository=""
 revision="263e03941187f4ffdd09b7e7ecee442717064083"
 Fixed #29045 -- Fixed admin CSS so that select multiple elements honor the
 HTML size attribute.
 }}}

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

Re: [Django] #22875: "ValueError: Lookup failed for model referenced by field app.Model.m2mfield: app.ThroghModel" in simple-self contained M2M setup

[Django]

#22875: "ValueError: Lookup failed for model referenced by field
app.Model.m2mfield: app.ThroghModel" in simple-self contained M2M setup
-+--
 Reporter:  Ramiro Morales   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7-beta-2
 Severity:  Release blocker  |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"e4c0878b30cf1fc29212185c55614fc463393af1" e4c0878b]:
 {{{
 #!CommitTicketReference repository=""
 revision="e4c0878b30cf1fc29212185c55614fc463393af1"
 Refs #22875 -- Fixed an optimizer test to use a valid scenario.

 An explicit intermediary many-to-many relationship must declare forward
 and
 reverse foreign keys. The original issue was in the autodetector as these
 operations shouldn't have been generated in this order in the first place
 which is tested by AutodetectorTests.test_create_with_through_model.
 }}}

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

Re: [Django] #26227: Unicode attachment filename displays incorrectly in some clients

[Django]

#26227: Unicode attachment filename displays incorrectly in some clients
-+-
 Reporter:  Sergey Gornostaev|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  email attachment,| Triage Stage:
  filenames, i18n|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 The name appears fine on the web version of gmail I'm using. I'll attach a
 screenshot with what I see.

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

Re: [Django] #26227: Unicode attachment filename displays incorrectly in some clients

[Django]

#26227: Unicode attachment filename displays incorrectly in some clients
-+-
 Reporter:  Sergey Gornostaev|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  email attachment,| Triage Stage:
  filenames, i18n|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * Attachment "gmail-screenshot.png" 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/068.28e30cb8d1059d24f20f2a7df80b087d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26227: Unicode attachment filename displays incorrectly in some clients

[Django]

#26227: Unicode attachment filename displays incorrectly in some clients
-+-
 Reporter:  Sergey Gornostaev|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Mail)  |  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  email attachment,| Triage Stage:
  filenames, i18n|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 It looks like I can't reproduce against master anymore as the issue
 manifests itself on Python 2, sorry for the false alarm Tim.

 Here's how the attachment is sent on Python 2

 {{{
 MIME-Version: 1.0
 Content-Type: text/plain; charset="utf-8"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename*="utf-8''%D0%98%D0%BC%D1%8F%20%D1%84%D0%B0%D0%B9%D0%BB%D0%B0"

 data
 }}}

 And on Python 3

 {{{
 Content-Type: text/plain; charset="utf-8"
 MIME-Version: 1.0
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename*=utf-8''%D0%98%D0%BC%D1%8F%20%D1%84%D0%B0%D0%B9%D0%BB%D0%B0

 data
 }}}

 Notice that both use a RFC 2231 `filename*=` parameter but the value is
 within double quotes on Python 2 while it isn't on Python 3. That seems to
 be the reason why GMail rejects the encoded value.

 This was changed in Python 3.1
 
[https://github.com/python/cpython/commit/dfd7eb0ba2f3296f28028970e395e38f3ae9eedc
 dfd7eb] and detailed in [https://bugs.python.org/issue1693546
 CPython#1693546]

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