Re: Feature Request: get_default_backend() in django.template.Engine

[Carlton Gibson]

Hi Peter. 

I agree with you that the documentation isn't that clear here. *"Why are 
there two template classes?", "Why does one take a dict and the other a 
Context?"* — that comes up. 🙂

I don't think your suggestion itself it that unreasonable, but I'm wary 
about expanding the API here, at least before exploring other options. 

The current get_default() behaviour was only added to allow folks manually 
creating `Template("My String")` instances to continue to operate with 
multiple Django backends defined (#27359 
) — the initial assumption 
there was that anonymous backend usage wouldn't be supported, i.e. that 
folks would do `engines["django"]` to get a specific backend.  Could you 
use that? 

If you've got a traditional Template (expecting a Context) can't you just 
provide one, via the make_context helper if needed? 
You already know here that you want a DjangoTemplate backend, we know we 
get that, so why the need for backend-neutral dict-taking Template? 
(It doesn't look like we need that?)

I guess, can you explain more about how the use-case comes up here? #27359 
was a while back now so we might exposing a new hook to have come up more 
quickly. 

Thanks. 

Kind Regards,

Carlton



On Thursday, 11 August 2022 at 20:44:06 UTC+2 homa...@gmail.com wrote:

> Hi,
>
> We're trying to create a template from string using 
> DjangoTemplates.from_string() of the default template backend, which wraps 
> the result of Engine.from_string() to construct an instance of the Template 
> class defined in the backend definition file: 
> django/template/backends/django.py#30
>
> This Template class differs from the Engine-delivered Template in that it 
> accepts a dictionary as the context, see 
> https://docs.djangoproject.com/en/4.0/topics/templates/#django.template.backends.base.Template.render
> .
>
> The default backend's engine is easily retrieved via 
> django.template.Engine.get_default(). This function identifies the first 
> configured DjangoTemplates backend, and then returns its .engine attribute. 
> As a result, when from_string() is called, it will be called on the engine 
> and not on the backend, thus the wrapping Template() call is missing.
>
> I would like to propose adding a get_default_backend() function to 
> django.template.Engine, which is like get_default(), but returns the 
> backend itself (and not its .engine attribute). get_default() can then be 
> adjusted to simply return get_default_backend().engine.
>
> While trying to solve the issue (context argument type mismatch: dict vs 
> Context), I found the docs not very helpful, as they are not very accurate 
> in the distinction between a backend and its engine. I've also added a 
> commit that clarifies that language.
>
> I have submitted a patch here: https://github.com/django/django/pull/15944
>
>
> FWIW, the problem can also be solved on the application layer, like:
>
> def get_default_template_backend():
> # Ad-hoc implementation of https://github.com/django/django/pull/15944
> from django.template import engines
> for backend in engines.all():
> if isinstance(backend, DjangoTemplates):
> return backend
> raise ImproperlyConfigured("No DjangoTemplates backend is configured.")
>
> However and IMHO, this needlessly duplicates the logic from get_default() 
> and adds undue complication to the app (like having to know about and 
> looping over the .all() iterable; raising the exception), whereas that 
> complexity already is in the core.
>
>
> Please let me know what you think!
>
> Thanks,
> Peter
>
> -- 
> https://desec.io/
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/815e0c04-ae16-4502-8792-6a3551d7d260n%40googlegroups.com.

transaction.on_commit() proposal

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi

I just wrote a blog post on a late-binding bug that can occur with using
transaction.on_commit() with a function or lambda within a loop. THe post
shows how using functools.partial() solves this. See the post here:
https://adamj.eu/tech/2022/08/22/use-partial-with-djangos-transaction-on-commit/

I propose that transaction.on_commit() be modified to take args and kwargs
to pass to the callback function. This would mean it effectively constructs
a partial() "under the hood":

transaction.on_commit(send_mail, subject=f"...",
recipient_list=[user.email], ...)

I think this would be simpler than asking developers to beware of the
late-binding problem and use partial(), always or when appropriate.

This change would make transaction.on_commit() similar to Python's
atexit.register(), which also takes a callback to run at a later point, and
optional args/kwargs to pass it:
https://docs.python.org/3.10/library/atexit.html#atexit.register

The only backwards-compatibility concern I can see is the `using` argument,
which would not be passed to the underlying function. I don't see this as a
huge concern, since it would be the only argument that isn't passed
through, and there doesn't seem to be any reason to add further arguments.
Users who need to pass a kwarg called 'using' could always construct a
partial() themselves.

Thoughts?

Adam

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2OQoj3mV4pHuo8OB%2BLM6xpZdLQdSTyaGR%2B1m5oPg-C7Q%40mail.gmail.com.

Re: transaction.on_commit() proposal

[Carlton Gibson]

Related ticket from this weekend, suggesting a docs change:
https://code.djangoproject.com/ticket/33939

On Mon, 22 Aug 2022 at 14:11, 'Adam Johnson' via Django developers
(Contributions to Django itself)  wrote:

> Hi
>
> I just wrote a blog post on a late-binding bug that can occur with using
> transaction.on_commit() with a function or lambda within a loop. THe post
> shows how using functools.partial() solves this. See the post here:
> https://adamj.eu/tech/2022/08/22/use-partial-with-djangos-transaction-on-commit/
>
> I propose that transaction.on_commit() be modified to take args and kwargs
> to pass to the callback function. This would mean it effectively constructs
> a partial() "under the hood":
>
> transaction.on_commit(send_mail, subject=f"...",
> recipient_list=[user.email], ...)
>
> I think this would be simpler than asking developers to beware of the
> late-binding problem and use partial(), always or when appropriate.
>
> This change would make transaction.on_commit() similar to Python's
> atexit.register(), which also takes a callback to run at a later point, and
> optional args/kwargs to pass it:
> https://docs.python.org/3.10/library/atexit.html#atexit.register
>
> The only backwards-compatibility concern I can see is the `using`
> argument, which would not be passed to the underlying function. I don't see
> this as a huge concern, since it would be the only argument that isn't
> passed through, and there doesn't seem to be any reason to add further
> arguments. Users who need to pass a kwarg called 'using' could always
> construct a partial() themselves.
>
> Thoughts?
>
> Adam
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2OQoj3mV4pHuo8OB%2BLM6xpZdLQdSTyaGR%2B1m5oPg-C7Q%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyTBmLTR8cLbOMWFmm-y47jH1Jki48BF57cvM%3DKPpjNGHw%40mail.gmail.com.

Make timeout property for PasswordResetTokenGenerator

[Alexander Voloshchenko]

During project development our team needs to create several types of 
tokens. One of them will be used in case of account reset password. The 
second one is for account activation. Django itself has a good class for 
token generation called PasswordResetTokenGenerator. And now for account 
activation, we are using our own class called ActivationTokenGenerator, a 
subclass of PasswordResetTokenGenerator with overridden _make_hash_value 
method. 
And it works, but there is one problem. And this problem is called 
"timeout". For now, every token created with PasswordResetTokenGenerator will 
have timeout from settings.PASSWORD_RESET_TIMEOUT variable and can be 
changed only by changing this variable value. But what if we need different 
timeouts for different tokens? And I don't think we want changing timeout 
for *activation* token using a variable which is screaming about *password 
reset* (PASSWORD_RESET_TIMEOUT), we would like to use smth called 
ACTIVATION_TOKEN_TIMEOUT
So there is a solution: why not create a timeout property for 
PasswordResetTokenGenerator class? Almost in the same way as it was done 
with _secret and algorithm fields.So our development team come up with an 
idea to create a PR which will add this functionality to the Django 
project. But before this we decided to search similar solutions in django 
PRs. And we found them! Ticket 30423 
https://code.djangoproject.com/ticket/30423 sounds good enough, but it was 
closed with wontfix label.So the question is: why not to add this fine 
feature to the PasswordResetTokenGenerator ? And if people find this useful 
- why not to merge one o the existing PRs?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4f810acc-f2b4-4931-a84e-a59332a825f1n%40googlegroups.com.

RE: Make timeout property for PasswordResetTokenGenerator

[Danilov Maxim]

Hi Alexander.

 

You can simply override ‘check_token’ to avoide this harcoded 
settings.PASSWORD_RESET_TIMEOUT on the 57 line.

 

And for yours task it can be with super call  and after add additional check.

 

It is only some additional lines:

 

MyСlassFromPasswordResetTokenGenerator(…):

 

MY_OWN_TIMEOUT = your_timeout

 

def check_token(self, *args, **kwargs):

return super().check_token(*args, **kwargs) or 
self._my_check_token_function_with_other_timeout(*args, **kwargs))

 

_my_check_token_function_with_other_timeout – should check if super returns 
false not from last ‘if’ in PasswordResetTokenGenerator.check_token

 

For us it works without any problem.

 

Mit freundlichen Grüßen,

DI Mag. Maxim Danilov

 

+43(681)207 447 76

  ma...@wpsoft.at

 

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Alexander Voloshchenko
Sent: Monday, August 22, 2022 3:40 PM
To: Django developers (Contributions to Django itself) 

Subject: Make timeout property for PasswordResetTokenGenerator

 

During project development our team needs to create several types of tokens. 
One of them will be used in case of account reset password. The second one is 
for account activation. Django itself has a good class for token generation 
called PasswordResetTokenGenerator. And now for account activation, we are 
using our own class called ActivationTokenGenerator, a subclass of 
PasswordResetTokenGenerator with overridden _make_hash_value method. And it 
works, but there is one problem. And this problem is called "timeout". For now, 
every token created with PasswordResetTokenGenerator will have timeout from 
settings.PASSWORD_RESET_TIMEOUT variable and can be changed only by changing 
this variable value. But what if we need different timeouts for different 
tokens? And I don't think we want changing timeout for activation token using a 
variable which is screaming about password reset (PASSWORD_RESET_TIMEOUT), we 
would like to use smth called ACTIVATION_TOKEN_TIMEOUT
So there is a solution: why not create a timeout property for 
PasswordResetTokenGenerator class? Almost in the same way as it was done with 
_secret and algorithm fields.So our development team come up with an idea to 
create a PR which will add this functionality to the Django project. But before 
this we decided to search similar solutions in django PRs. And we found them! 
Ticket 30423   
https://code.djangoproject.com/ticket/30423 sounds good enough, but it was 
closed with wontfix label.So the question is: why not to add this fine feature 
to the PasswordResetTokenGenerator ? And if people find this useful - why not 
to merge one o the existing PRs? 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4f810acc-f2b4-4931-a84e-a59332a825f1n%40googlegroups.com
 

 .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/01d8b645%2451b33f90%24f519beb0%24%40wpsoft.at.

Easy Pickings: admin change_form label does not use mark_safe

[Caram]

I've just opened a ticket for this issue. The problem is that the label is 
not escape. There is no such issue with change_list.html.

https://code.djangoproject.com/ticket/33946#ticket

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bd289257-bf12-49f6-b8d7-14ea559861aen%40googlegroups.com.

Re: transaction.on_commit() proposal

['Adam Johnson' via Django developers (Contributions to Django itself)]

I'd also be okay with a docs change, although this wouldn't help avoid
late-binding bugs quite so much.

On Mon, Aug 22, 2022 at 1:51 PM Carlton Gibson 
wrote:

> Related ticket from this weekend, suggesting a docs change:
> https://code.djangoproject.com/ticket/33939
>
> On Mon, 22 Aug 2022 at 14:11, 'Adam Johnson' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> Hi
>>
>> I just wrote a blog post on a late-binding bug that can occur with using
>> transaction.on_commit() with a function or lambda within a loop. THe post
>> shows how using functools.partial() solves this. See the post here:
>> https://adamj.eu/tech/2022/08/22/use-partial-with-djangos-transaction-on-commit/
>>
>> I propose that transaction.on_commit() be modified to take args and
>> kwargs to pass to the callback function. This would mean it effectively
>> constructs a partial() "under the hood":
>>
>> transaction.on_commit(send_mail, subject=f"...",
>> recipient_list=[user.email], ...)
>>
>> I think this would be simpler than asking developers to beware of the
>> late-binding problem and use partial(), always or when appropriate.
>>
>> This change would make transaction.on_commit() similar to Python's
>> atexit.register(), which also takes a callback to run at a later point, and
>> optional args/kwargs to pass it:
>> https://docs.python.org/3.10/library/atexit.html#atexit.register
>>
>> The only backwards-compatibility concern I can see is the `using`
>> argument, which would not be passed to the underlying function. I don't see
>> this as a huge concern, since it would be the only argument that isn't
>> passed through, and there doesn't seem to be any reason to add further
>> arguments. Users who need to pass a kwarg called 'using' could always
>> construct a partial() themselves.
>>
>> Thoughts?
>>
>> Adam
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAMyDDM2OQoj3mV4pHuo8OB%2BLM6xpZdLQdSTyaGR%2B1m5oPg-C7Q%40mail.gmail.com
>> 
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAJwKpyTBmLTR8cLbOMWFmm-y47jH1Jki48BF57cvM%3DKPpjNGHw%40mail.gmail.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM354E0mQg8KAnrmzoJe7nZ7JyHGXgjppGXde-5mMfzqUg%40mail.gmail.com.