Signals - Need a signal after annotations are added

[Mike Brown]

I have a situation where I need a signal for when a model object is fully 
instantiated.

Currently, there are signals for pre_init and post_init. However, when 
post_init is fired, 
the object is not fully 'initialized' in the sense that annotations have 
not yet been added to the object.


In django.db.models.query there is class ModelIterable(BaseIterable)

In this class there is code to run a query and then apply annotations.

Should there be a new signal added to Django that is fired after the 
annotations are complete and the object is fully instantiated?

Maybe a signal called 'instantiation_complete'?


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bc4516df-71da-429f-af80-7c98a60ab91f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal for a new template tag to disable invoking callable variables

[Alex Epshteyn]

I recently posted #30205 , 
which proposes a new template tag to solve a template problem that has been 
bothering me (see #30197 ).

Requesting feedback from the community regarding both of these tickets.

If there is consensus, I'd be happy to take a shot at implementing it.

Thanks,

Alex
https://github.com/aepshteyn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0cabfd7c-01a1-470d-b2d1-22e2a4509b05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Tobias McNulty]

Hi all,

An implementation question has come up regarding cache lifetime (see this PR
). Right now, the
whole site (including docs) has the site-wide Django cache enabled
,
with a timeout of 5 minutes
.
A couple docs views (search_suggestions

and search_description
)
views have longer timeouts set (to 1 hour and 1 week, respectively).

Once released, the vast majority of Django docs won't change much, except
for the release notes section and any (likely minor) related updates to the
docs themselves. To get the most benefit out of a CDN, it would obviously
be desirable to set the timeout to something greater than 5 minutes.

At the same time, there are moments when a quick update to the docs *is*
desired, and waiting an hour or more for any cached pages to expire may
cause significant confusion, for example, in conjunction with a security
release for which stubbed (non-final) release notes may have already been
pushed out and cached.

I see two main options at this point (which could even be combined):

1) Invalidate the whole cache (or at least some key release notes URLs) any
time there's a docs build that has changes. It would be pretty easy to
piggyback off of the existing business logic for avoiding a rebuild

if the git checkout hasn't changed (in the update_docs management command).
2) Pick subsections of the docs (e.g., for anything matching
'///releases/*' and perhaps the development docs) that would
keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
requiring this special treatment would get a longer timeout, perhaps
somewhere between 1 and 24 hours.

So, some questions for the list:

* Are there sections of the docs besides '///releases/' and
'//dev/' that might update frequently and merit some combination of
invalidation and/or a shorter cache time? And what's a good cache timeout
for such pages?
* How long are we comfortable waiting for *other* (not frequently updated)
pages to timeout, in the event they do change?

Tobias

On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty 
wrote:

> Thanks for sharing the results.
>
> I did manage to get a domain set up with working SSL, in case you want to
> use it: https://django-docs.global.ssl.fastly.net/en/2.1/
>
> Tobias
>
> On Thu, Feb 14, 2019, 11:49 PM Cheng C 
>> Thanks for the test site, Tobias.
>>
>> Tested from Melbourne, Australia:
>>
>> https://docs.djangoproject.com/en/2.1/
>> Average Ping: 268ms
>>  Browser: 22 requests, 238KB transferred, Finish: 2.72s,
>> DOMContentLoaded: 1.37s, Load: 1.68s
>>
>> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
>> Average Ping: 28ms
>>  Browser: 22 requests, 240KB transferred, Finish: 947ms,
>> DOMContentLoaded: 627ms, Load: 910ms
>>
>> Tested on Chrome with "Disable cache" checked, and no render issue was
>> found.
>>
>> On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
>>>
>>> Adam, is there another provider you would recommend instead, that does
>>> not require changing DNS providers? FWIW, python.org does in fact use
>>> Fastly:
>>>
>>> $ host www.python.org
>>> www.python.org is an alias for dualstack.python.map.fastly.net.
>>> dualstack.python.map.fastly.net has address 151.101.248.223
>>> dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223
>>>
>>> Fastly did write back to say they're happy to help, though there's a
>>> contract which I guess the DSF would need to review and sign, if it's
>>> acceptable.
>>>
>>> In the meantime, feel free to give this a try and let me know if you see
>>> any issues:
>>> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for
>>> permanent use, obviously; you'll get a cert warning, and some pages will
>>> redirect you back to https://docs.djangoproject.com.)
>>>
>>> To keep this thread from getting too noisy, you can find me (tobias1) in
>>> #django-dev on FreeNode.
>>>
>>> Cheers,
>>> Tobias
>>>
>>> On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:
>>>
 I have not had great experience with Fastly in the past and would avoid
 them. They run an old fork of Varnish which is not fun to configure.

 On Thu, 14 Feb 2019 at 11:16, Josh Smeaton  wrote:

> Cloudflare have many SSL options, including fully encrypted and
> authenticated comms all the way through (terminate and reconnect).
> Typically done by having a “hidden” origin domain that also hosts a
> certificate. I’m unsure if it’s possible to have both origin and front
> hosting the same name

Re: Use CDN for djangoproject.com

[Tom Forbes]

Which CDN are we going to use? Fastly has awesome sub 100ms global
invalidation which we can trigger on every deploy, and cloudflare has
something similar.

On Sun, 24 Feb 2019, 00:00 Tobias McNulty,  wrote:

> Hi all,
>
> An implementation question has come up regarding cache lifetime (see this
> PR ). Right now,
> the whole site (including docs) has the site-wide Django cache enabled
> ,
> with a timeout of 5 minutes
> .
> A couple docs views (search_suggestions
> 
> and search_description
> )
> views have longer timeouts set (to 1 hour and 1 week, respectively).
>
> Once released, the vast majority of Django docs won't change much, except
> for the release notes section and any (likely minor) related updates to the
> docs themselves. To get the most benefit out of a CDN, it would obviously
> be desirable to set the timeout to something greater than 5 minutes.
>
> At the same time, there are moments when a quick update to the docs *is*
> desired, and waiting an hour or more for any cached pages to expire may
> cause significant confusion, for example, in conjunction with a security
> release for which stubbed (non-final) release notes may have already been
> pushed out and cached.
>
> I see two main options at this point (which could even be combined):
>
> 1) Invalidate the whole cache (or at least some key release notes URLs)
> any time there's a docs build that has changes. It would be pretty easy to
> piggyback off of the existing business logic for avoiding a rebuild
> 
> if the git checkout hasn't changed (in the update_docs management command).
> 2) Pick subsections of the docs (e.g., for anything matching
> '///releases/*' and perhaps the development docs) that would
> keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
> requiring this special treatment would get a longer timeout, perhaps
> somewhere between 1 and 24 hours.
>
> So, some questions for the list:
>
> * Are there sections of the docs besides '///releases/' and
> '//dev/' that might update frequently and merit some combination of
> invalidation and/or a shorter cache time? And what's a good cache timeout
> for such pages?
> * How long are we comfortable waiting for *other* (not frequently
> updated) pages to timeout, in the event they do change?
>
> Tobias
>
> On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty 
> wrote:
>
>> Thanks for sharing the results.
>>
>> I did manage to get a domain set up with working SSL, in case you want to
>> use it: https://django-docs.global.ssl.fastly.net/en/2.1/
>>
>> Tobias
>>
>> On Thu, Feb 14, 2019, 11:49 PM Cheng C >
>>> Thanks for the test site, Tobias.
>>>
>>> Tested from Melbourne, Australia:
>>>
>>> https://docs.djangoproject.com/en/2.1/
>>> Average Ping: 268ms
>>>  Browser: 22 requests, 238KB transferred, Finish: 2.72s,
>>> DOMContentLoaded: 1.37s, Load: 1.68s
>>>
>>> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
>>> Average Ping: 28ms
>>>  Browser: 22 requests, 240KB transferred, Finish: 947ms,
>>> DOMContentLoaded: 627ms, Load: 910ms
>>>
>>> Tested on Chrome with "Disable cache" checked, and no render issue was
>>> found.
>>>
>>> On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:

 Adam, is there another provider you would recommend instead, that does
 not require changing DNS providers? FWIW, python.org does in fact use
 Fastly:

 $ host www.python.org
 www.python.org is an alias for dualstack.python.map.fastly.net.
 dualstack.python.map.fastly.net has address 151.101.248.223
 dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

 Fastly did write back to say they're happy to help, though there's a
 contract which I guess the DSF would need to review and sign, if it's
 acceptable.

 In the meantime, feel free to give this a try and let me know if you
 see any issues:
 https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for
 permanent use, obviously; you'll get a cert warning, and some pages will
 redirect you back to https://docs.djangoproject.com.)

 To keep this thread from getting too noisy, you can find me (tobias1)
 in #django-dev on FreeNode.

 Cheers,
 Tobias

 On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:

> I have not had great experience with Fastly in the past and would
> avoid them. They run an old fork of Varnish which is not fun to configure.
>
> On Thu, 14 Feb 

Re: Use CDN for djangoproject.com

[Tom Forbes]

Sorry, I did not completely grok your message. I would be in favour of just
invalidating the whole cache if needed, it seems the simplest solution.
Invalidating most of the cache on every non-dev deploy would also be OK I
think.

On Sun, 24 Feb 2019, 00:10 Tom Forbes,  wrote:

> Which CDN are we going to use? Fastly has awesome sub 100ms global
> invalidation which we can trigger on every deploy, and cloudflare has
> something similar.
>
> On Sun, 24 Feb 2019, 00:00 Tobias McNulty,  wrote:
>
>> Hi all,
>>
>> An implementation question has come up regarding cache lifetime (see this
>> PR ). Right now,
>> the whole site (including docs) has the site-wide Django cache enabled
>> ,
>> with a timeout of 5 minutes
>> .
>> A couple docs views (search_suggestions
>> 
>> and search_description
>> )
>> views have longer timeouts set (to 1 hour and 1 week, respectively).
>>
>> Once released, the vast majority of Django docs won't change much, except
>> for the release notes section and any (likely minor) related updates to the
>> docs themselves. To get the most benefit out of a CDN, it would obviously
>> be desirable to set the timeout to something greater than 5 minutes.
>>
>> At the same time, there are moments when a quick update to the docs *is*
>> desired, and waiting an hour or more for any cached pages to expire may
>> cause significant confusion, for example, in conjunction with a security
>> release for which stubbed (non-final) release notes may have already been
>> pushed out and cached.
>>
>> I see two main options at this point (which could even be combined):
>>
>> 1) Invalidate the whole cache (or at least some key release notes URLs)
>> any time there's a docs build that has changes. It would be pretty easy to
>> piggyback off of the existing business logic for avoiding a rebuild
>> 
>> if the git checkout hasn't changed (in the update_docs management command).
>> 2) Pick subsections of the docs (e.g., for anything matching
>> '///releases/*' and perhaps the development docs) that would
>> keep a shorter cache timeout of 5-10 minutes. All URLs not specifically
>> requiring this special treatment would get a longer timeout, perhaps
>> somewhere between 1 and 24 hours.
>>
>> So, some questions for the list:
>>
>> * Are there sections of the docs besides '///releases/'
>> and '//dev/' that might update frequently and merit some combination
>> of invalidation and/or a shorter cache time? And what's a good cache
>> timeout for such pages?
>> * How long are we comfortable waiting for *other* (not frequently
>> updated) pages to timeout, in the event they do change?
>>
>> Tobias
>>
>> On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty 
>> wrote:
>>
>>> Thanks for sharing the results.
>>>
>>> I did manage to get a domain set up with working SSL, in case you want
>>> to use it: https://django-docs.global.ssl.fastly.net/en/2.1/
>>>
>>> Tobias
>>>
>>> On Thu, Feb 14, 2019, 11:49 PM Cheng C >>
 Thanks for the test site, Tobias.

 Tested from Melbourne, Australia:

 https://docs.djangoproject.com/en/2.1/
 Average Ping: 268ms
  Browser: 22 requests, 238KB transferred, Finish: 2.72s,
 DOMContentLoaded: 1.37s, Load: 1.68s

 https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
 Average Ping: 28ms
  Browser: 22 requests, 240KB transferred, Finish: 947ms,
 DOMContentLoaded: 627ms, Load: 910ms

 Tested on Chrome with "Disable cache" checked, and no render issue was
 found.

 On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:
>
> Adam, is there another provider you would recommend instead, that does
> not require changing DNS providers? FWIW, python.org does in fact use
> Fastly:
>
> $ host www.python.org
> www.python.org is an alias for dualstack.python.map.fastly.net.
> dualstack.python.map.fastly.net has address 151.101.248.223
> dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223
>
> Fastly did write back to say they're happy to help, though there's a
> contract which I guess the DSF would need to review and sign, if it's
> acceptable.
>
> In the meantime, feel free to give this a try and let me know if you
> see any issues:
> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not
> for permanent use, obviously; you'll get a cert warning, and some pages
> will redirect you back to https://docs.djangoproject.com.)
>

Re: Fellow Reports - February 2019

[Tim Graham]

Week ending February 23, 2019

I took a break for most of this week.

Reviewed/committed

--

https://github.com/django/django/pull/10995 -  Refs #19544 -- Ignored 
auto-created through additions conflicts if supported.
https://github.com/django/django/pull/10999 - Fixed #30141 -- Fixed 
parse_duration() for some negative durations.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/53395eb6-b0f8-4c71-a09c-e00b7ce392d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for a new template tag to disable invoking callable variables

[Alex Epshteyn]

The reason for this suggestion is over the years, while writing 
templates, I've had to spend a lot of time trying to figure out why I was 
getting an unexpected value (often an empty string) substituted for a 
template variable when that variable clearly had a different value.  

The reason that happens, of course, is that the 
​django.template.base.Variable._resolve_lookup 

 
method tries to invoke every callable value in a variable's resolution 
path, including the variable itself.  If that callable is a function with 
parameters, for example, the invocation raises an exception and you end up 
with an empty string (or whatever value you use for the string_if_invalid 
setting) as a result.  If it's a different kind of callable, like a class 
or a regular object that implements __call__ 
 for whatever reason, you just 
end up with something other than what you wanted.

While automatically invoking callables makes sense when the current "bit" 
in the resolution path is a method and the previous "bit" was an instance, 
it is very surprising when the "callable" value is not actually a method 
(e.g. it's a class or a standalone function), in which case I don't think 
it makes sense to call it automatically.  In fact, this goes against the 
fundamental Python (and Django) philosophy of *"Explicit is better than 
implicit".*

There are legitimate cases where you might want to pass something like a 
class object to a template and to not have it mysteriously replaced by an 
arbitrary instance of that class (see #30197 
). I also think that the 
existing workaround of setting a do_not_call_in_templates 
 attribute on such object is 
insufficient to cover all such cases (e.g. when the object is a class or 
function that comes from some library and you don't want to risk messing 
with it).

My comment on #30197  
suggested 
replacing this implicit behavior with an explicit tag like {% call foo %} 
instead 
of {{ foo }} (this example assumes that foo is callable).  Although that 
would be a breaking change, I think it might be worth considering because 
it would be in the spirit of upholding the *"Explicit is better than 
implicit"* principle, and prevent a frequently-occurring problem for 
template authors (which is evidenced by the prevalence of tickets and 
StackOverflow questions about this topic; e.g. 
https://stackoverflow.com/questions/6861601/cannot-resolve-callable-context-variable
)

However, in #30205 , I am 
proposing a *non-breaking *change to solve this problem -- a new template 
tag similar to autoescap 

e 
,
 
which could be used like this:

{% callables off %}
  The class name is {{ foo.bar|type_name }}{% endcallables %}


(in the above example foo is an object containing an attribute named "bar" 
whose value is a class, and |type_name is a user-defined filter that 
returns the "__name__" attribute of its argument)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/962bead6-e186-416b-a18a-3e0f2ad23da9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Signals - Need a signal after annotations are added

[Philip James]

Hi! I think I'm misunderstanding what you're asking for. I've looked at
every doc I can find on annotations to refresh my memory, and it looks like
annotations only apply to query sets, not to objects? Could you say a bit
more about your use case to help me grok what's going on?

Thanks,
Philip

PJJ
http://philipjohnjames.com


On Sat, Feb 23, 2019 at 12:08 PM Mike Brown  wrote:

> I have a situation where I need a signal for when a model object is fully
> instantiated.
>
> Currently, there are signals for pre_init and post_init. However, when
> post_init is fired,
> the object is not fully 'initialized' in the sense that annotations have
> not yet been added to the object.
>
>
> In django.db.models.query there is class ModelIterable(BaseIterable)
>
> In this class there is code to run a query and then apply annotations.
>
> Should there be a new signal added to Django that is fired after the
> annotations are complete and the object is fully instantiated?
>
> Maybe a signal called 'instantiation_complete'?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/bc4516df-71da-429f-af80-7c98a60ab91f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACXM1yFDmDRP%3D2aRpgrzk4PvgPSGbBSMQh%3D0D7XTmRES%2BQ99Tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Signals - Need a signal after annotations are added

[James Bennett]

On Sat, Feb 23, 2019 at 9:48 PM Philip James 
wrote:

> Hi! I think I'm misunderstanding what you're asking for. I've looked at
> every doc I can find on annotations to refresh my memory, and it looks like
> annotations only apply to query sets, not to objects? Could you say a bit
> more about your use case to help me grok what's going on?
>

When a QuerySet is annotated, each object in the results gets the
additional attribute(s) attached to it from the annotation. I think this is
a request for a signal that fires after those attributes have been added to
the model instances.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg-XRHTxB2roFBpoQGvwELS8Tj1E6XXqiodyPOxwpn8mtA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Signals - Need a signal after annotations are added

[Mike Brown]

>
>  I think this is a request for a signal that fires after those attributes 
> have been added to the model instances. 
>

Yes.
 

On Saturday, February 23, 2019 at 12:08:43 PM UTC-8, Mike Brown wrote:
>
> I have a situation where I need a signal for when a model object is fully 
> instantiated.
>
> Currently, there are signals for pre_init and post_init. However, when 
> post_init is fired, 
> the object is not fully 'initialized' in the sense that annotations have 
> not yet been added to the object.
>
>
> In django.db.models.query there is class ModelIterable(BaseIterable)
>
> In this class there is code to run a query and then apply annotations.
>
> Should there be a new signal added to Django that is fired after the 
> annotations are complete and the object is fully instantiated?
>
> Maybe a signal called 'instantiation_complete'?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8081596b-26c8-4380-b292-2ba1e77ae61a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.