Python PEP for more convenient HTML generation

2021-06-11 Thread guettli
Hi,

Since I use the html-fragments-over-the-wire pattern (htmx) I create
small function based views returning small html fragments.

Up to now I use format_html().

I am tired of passing in the variables like `foo=foo, bar=bar` into
format_html().

I created a Python PEP to introduce a new way.

The goal is to have something like the convenient f-string syntax
combined with conditional_escape().

The draft is here: 

Template Literals: https://github.com/guettli/peps/blob/master/pep-.rst

I am looking for feedback. Either here or on python-ideas.

If Python would implement this PEP, would you accept patches
to Django to support Template Literals?

Background: I don't like the JS-Frontend madness. Django can
do more than just provide an http API.

Regards,
  Thomas

-- 
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/39137657-4b16-42ad-a2ea-4d97ba9382d4n%40googlegroups.com.


Re: Python PEP for more convenient HTML generation

2021-06-11 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)
Hi Thomas

As I understand there wouldn't be much required by Django to support this -
just one function. So if it came to Python, I think we'd like to see a
working snippet, maybe in a third party package, before merging support.

In terms of the PEP, - there are already "too many" ways to template a
string in Python, so I'm not sure it will be very popular. A few
alternatives spring to mind, beyond those discussed in your related forum
thread (
https://forum.djangoproject.com/t/rethinking-how-to-create-html-f-string-like-with-conditional-escape/8212
).

First, there's syntactic macros in PEP 638 (
https://www.python.org/dev/peps/pep-0638/ ). They would provide some
extensibility to Python's grammar, so features like your HTML string would
not need to go through PEP's and Python releases. They could just be
installable packages. Definitely check that out - it seems like it's still
in draft phase though.

Second, a related way to emulate such macros currently is with a codec.
Check out the future-fstrings package, which backported f-strings to older
versions of Python: https://github.com/asottile/future-fstrings . As a
"wrapper" text codec, it gets to pre-process the source code before passing
it on to Python to execute. You could do your template string
transformation with the current version of Python like this.

Third, stack inspection would also allow you to emulate template strings.
Take this example:

import inspect

from django.utils.html import format_html


def html(string):
locals_ = inspect.currentframe().f_back.f_locals
return format_html(string, **locals_)


def main():
name = "Adam"
statement = "I'm < 120 years old"
print(html("{name} says {statement}"))


if __name__ == "__main__":
main()


Running it:

$ python ex.py
Adam says I'm < 120 years old


On Fri, 11 Jun 2021 at 08:52, guettli 
wrote:

> Hi,
>
> Since I use the html-fragments-over-the-wire pattern (htmx) I create
> small function based views returning small html fragments.
>
> Up to now I use format_html().
>
> I am tired of passing in the variables like `foo=foo, bar=bar` into
> format_html().
>
> I created a Python PEP to introduce a new way.
>
> The goal is to have something like the convenient f-string syntax
> combined with conditional_escape().
>
> The draft is here:
>
> Template Literals:
> https://github.com/guettli/peps/blob/master/pep-.rst
>
> I am looking for feedback. Either here or on python-ideas.
>
> If Python would implement this PEP, would you accept patches
> to Django to support Template Literals?
>
> Background: I don't like the JS-Frontend madness. Django can
> do more than just provide an http API.
>
> Regards,
>   Thomas
>
> --
> 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/39137657-4b16-42ad-a2ea-4d97ba9382d4n%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/CAMyDDM1uYWyJpSPZtO2B87kpE5Yt1X2wyWGMZ9HoobhvEtjaeg%40mail.gmail.com.


Re: Python PEP for more convenient HTML generation

2021-06-11 Thread guettli


Adam Johnson schrieb am Freitag, 11. Juni 2021 um 10:17:02 UTC+2:

> Hi Thomas
>
> As I understand there wouldn't be much required by Django to support this 
> - just one function. So if it came to Python, I think we'd like to see a 
> working snippet, maybe in a third party package, before merging support.
>
>
Thank you Adam. The change in Django would be tiny. I think only 
HttpResponse and conditional_escape would need a change. I will provide the 
PR if the PEP gets accepted.

 

> In terms of the PEP, - there are already "too many" ways to template a 
> string in Python, so I'm not sure it will be very popular. A few 
> alternatives spring to mind, beyond those discussed in your related forum 
> thread ( 
> https://forum.djangoproject.com/t/rethinking-how-to-create-html-f-string-like-with-conditional-escape/8212
>  
> ).
>
> First, there's syntactic macros in PEP 638 ( 
> https://www.python.org/dev/peps/pep-0638/ ). They would provide some 
> extensibility to Python's grammar, so features like your HTML string would 
> not need to go through PEP's and Python releases. They could just be 
> installable packages. Definitely check that out - it seems like it's still 
> in draft phase though.
>
>
I will have a look at PEP 638.

 

> Second, a related way to emulate such macros currently is with a codec. 
> Check out the future-fstrings package, which backported f-strings to older 
> versions of Python: https://github.com/asottile/future-fstrings . As a 
> "wrapper" text codec, it gets to pre-process the source code before passing 
> it on to Python to execute. You could do your template string 
> transformation with the current version of Python like this.
>
>
I will  have a loot at this. I would be happy if no PEP would be needed.

But one thing is important for me: IDE and linters should understand it.

 

> Third, stack inspection would also allow you to emulate template strings. 
> Take this example:
>
> import inspect
>
> from django.utils.html import format_html
>
>
> def html(string):
> locals_ = inspect.currentframe().f_back.f_locals
> return format_html(string, **locals_)
>
>
> def main():
> name = "Adam"
> statement = "I'm < 120 years old"
> print(html("{name} says {statement}"))
>
>
> if __name__ == "__main__":
> main()
>
>
Because of the lack of IDE/linters support I added this to the "Rejected 
Ideas".

Thank you for your feedback, I will look into your hints.

Regards,
  Thomas

-- 
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/10b8b00e-e213-48e2-a9a7-7aa8479aefc5n%40googlegroups.com.


Removal of USE_L10N setting

2021-06-11 Thread Claude Paroz

Hi,

I eventually took some time to try implementing an idea I had since some 
time: remove the USE_L10N setting.

The draft PR is here:
https://github.com/django/django/pull/14519

My motivations are:
 - one less setting
 - simplication of the code and logic regarding USE_18N/USE_L10N/USE_TZ 
settings

 - a user-friendly default behavior

As usual, the main drawback is backwards compatibility. The possibly 
affected projects are those having USE_L10N = False, along with multiple 
LANGUAGES.


Is this a good idea?
I would also like to get opinions here about the compatibility issues.
Are they acceptable?
Is there a possible deprecation path?

Regards,

Claude
--
www.2xlibre.net

--
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/8cb0c69a-1900-30b4-51de-e61d6cd66a8a%402xlibre.net.


Add feature request for django permissions.

2021-06-11 Thread wael muhammed

could this 

 
want feature request.

-- 
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/5ad8fc90-d676-4f71-a228-697617cd4e8dn%40googlegroups.com.