[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[David Mertz]

On Fri, Jun 11, 2021 at 2:37 AM Thomas Güttler 
wrote:

> If you don't create HTML with Python daily, then you might not feel the
> pain.
>
If you create many HTML strings daily, then you will be typing `foo=foo,
> bar=bar` (to pass the variables
> into the template) over and over again.
> My goal is to have a super reduced syntax, so that developers need only a
> few characters
> to create save (properly escaped) html with Python.
>

This is exactly why I oppose this.  I, like many, many other developers,
simply do not do that.  Like basically not ever.  In the very rare cases I
do, f-strings are more than enough.

This is trying to turn Python into PHP, a language dedicated to HTML
processing.

We simply do not need dedicated syntax that is ONLY relevant to making HTML
strings, saving a small number of characters for that one single task.

... and no, there isn't any other non-fanciful usage.  It is specifically
harmful to performance in SQL queries, so is an anti-pattern.  Maybe,
conceivably, once in a blue moon, someone will come across some other
domain where the new syntax could be useful (LaTeX templating?), but far,
far, less than to make it worth changing the language and imposing the
burden on 10s or 100s of millions of people who use Python.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VRYEBPYEOCJTS3FATOHZEW7HIGKVAWYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Stephen J. Turnbull]

Thomas Güttler writes:

 > I don't understand what you mean with "pragma
 > %conditional_escape_everything".
 > Could you please elaborate?

"Pragma" just means it's a way to switch on conditional_escape for all
template variable accesses for the rest of the file.

The main point is that Django already can conditional_escape all the
template variable accesses if it wants to, but it doesn't.  It can
provide a way for the template author to conditional_escape all the
template variable accesses if the author wants to, but apparently it
doesn't do that either.  I have to wonder why not.

 > That "safe" attribute is outside the scope of the PEP.

But it's not outside the scope of the PEP, because by using
conditional_escape in the template_literal_to_safestring() example,
you used the assumption that it's accessible.  But that's only true if
you pass "safe strings" straight through to the tokens in the
TemplateLiteral.  If you don't, conditional_escape in your example
would escape a safe string.  I don't see how you can guarantee that it
won't if you allow full f-string syntax.

 > In Django this is solved via mark_safe(), conditional_escape() and
 > fomat_html().

This isn't an explanation though.  The question is if you are
implementing a web framework that depends on returning something that
is not a str in the tokens, how do you do that and still retain the
power of f-string format expression syntax?  Or are you proposing that
a template literal be restricted to plain variables -- no expressions
and maybe no format specs that involve constructing strs -- in the {}?

 > Please provide an example how to simplify
 > `template_literal_to_safestring()` of
 > the draft:
 > https://github.com/guettli/peps/blob/master/pep-.rst#specification

That's not my problem.  I do not want this PEP, but if you want to
push it to completion, I want to be sure that it works well for the
proposed applications.  For the reasons above, so far I don't see how
it can be a big win for the web templating application.

I'm not clear on how it's a win for the logging application, either.
Note that as proposed in your PEP, template literal syntax would be
forbidden by Google for the same reasons that f-strings are: (1) the
logging implementation can theoretically collect the patterns from
.template as queryable strs, but that seems to be just wasted effort
because they are just strs and not usable as TemplateLiterals, and
(2) it always gets rendered (to TemplateLiteral), which is also wasted
effort if the logging function has no logs to send it to.

PEP 501 is intended to address both issues.  Note that in this example
(a slight extension of your example):

while (theres_work_to_do_matey):
if load > max_load:
logging.warn(f'Load is too high: {load}')

the f-string works because it is evaluated when 'warn' is called.  The
logging problem that PEP 501 addresses is this:

load_warning = f'Load is too high: {load}'
while (theres_work_to_do_matey):
if load > max_load:
logging.warn(load_warning)

Here the f-string does *not* work because it's evaluated at the
binding to 'load_warning', not at 'warn' time.  Template literal
syntax as in your PEP also fails, for the same reason.  This works:

load_warning = 'Load is too high: {load}'
while (theres_work_to_do_matey):
if load > max_load:
logging.warn(load_warning.format(load=load))

but for some reason ;-) people hate that, and Google recommends

load_warning = 'Load is too high: {load}'
while (theres_work_to_do_matey):
if load > max_load:
logging.warn(load_warning, load=load)

if the logging package supports it, which is still kinda ugly.  But a
PEP 501 i-string "just works" nicely:

load_warning = i'Load is too high: {load}'
while (theres_work_to_do_matey):
if load > max_load:
logging.warn(load_warning)

(This assumes a future version of logging.warn that calls str() on the
first argument if it is an InterpolationTemplate.)

 > He/she will see: `Hello {name}` is the way to create
 > a HTML fragment and he/she will do so.

That's not interesting, though.  The interesting question is what is
an author of a consumer of TemplateLiteral going to do.  I'll
guarantee you she/he will see this

fragment = ''.join([x for x, _ in template_literal])

somewhere.  I hope she/he doesn't copy it!

The problem here is that frameworks like Django, or even templating
languages like Jinja, are quite heavy.  People looking for more
lightweight approaches are likely to grab on to template literals and
implement a stripped-down "vocabulary" directly as Python functions
and methods.  If this is going to be implemented, I want this to work
naturally for them, and not be more restricted (especially not if the
restrictions are "don't do this or you'll be sorry" conventions like
Google's Logging Style Guide!) than f-strings are.

I'm NOT saying it won't "just work" in any of the 

[Python-ideas] Re: Define functions without parentheses (if no parameters given)

[Guido van Rossum]

On Fri, Jun 11, 2021 at 7:47 AM Jelle Zijlstra 
wrote:

>
> El jue, 10 jun 2021 a las 19:30, Cameron Simpson ()
> escribió:
>
>> On 11Jun2021 10:01, Cameron Simpson  wrote:
>>
>> It also struck me: functions with _no_ parameters are pretty rare.
>>
>> [...]
>>
> I got curious so I checked a large codebase I have access to. Out of 85540
> functions, 8244 take no arguments. Many of them are test functions.
>

I'm sure the idea is dead now, but it reminds me of an amusing anecdote I
heard in college.

You may not have heard of a language named Algol-68, but it was a big thing
when I learned programming in Amsterdam in the late '70s. Like its
predecessor, Algol-60, it had a feature where parameter-less functions
could both be *defined* and *called* without parentheses.

Now, in Algol-60, this was easy, because there were no function pointers,
so whenever the compiler saw the name of a parameter-less function, it
would generate the code to call it. (Example: "x := random*2".) But
Algol-68 *did* have function pointers, so the language design committee had
to introduce a complicated wrinkle into the type system so that you could
write things like "f := random" (interpreting it as a function pointer) but
also "x := 2*random" (calling it). The distinguishing property was the type
of the receiving end (i.e., f had to be declared as a parameterless
function pointer, and x had to be a number).

So one of the classes I took near the end of my studies was taught by the
lead author of Algol-68 (Adriaan van Wijngaarden). He was well respected
and near retirement age, so he could do what he wanted in class, and
sometimes he just told anecdotes from the past (I'd love such a job :-).
One day the issue with parameter-less functions came up, and by then a new
language named C had gained some notoriety. C, of course, has function
pointers and parameter-less functions, but both the declaration and the
call must use an empty pair of parentheses (i.e, "x = 2*random()", like
Python). Van Wijngaarden told us, somewhat ruefully, that, had the design
committee known that programmers would be happy to write that empty pair of
parentheses, they would have been able to simplify a significant corner of
Algol-68's type system.

This was one of the seminal ideas that went into Python's design.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DQGLY3ZLFMGVOC4JE7E2TLMWDROK2PAE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Define functions without parentheses (if no parameters given)

[Jelle Zijlstra]

El jue, 10 jun 2021 a las 19:30, Cameron Simpson () escribió:

> On 11Jun2021 10:01, Cameron Simpson  wrote:
> >So your idea does not suck. But it may not motivate anyone to implement
> >it, or even to agreed that it should be implemented.
>
> It also struck me: functions with _no_ parameters are pretty rare.
>
> I had a glance through my own code and aside from some closures
> (functions within a running function, getting their variables from the
> enclosing scope) I've got a few which either access state from some
> global or which generate something standalone, eg a primes() function
> which just generates the primes starting from 2, a function I maybe even
> don't use. They are very few.
>
I got curious so I checked a large codebase I have access to. Out of 85540
functions, 8244 take no arguments. Many of them are test functions.


>
> So these seem pretty rare. Just how often do you write such a function
> yourself? Got a real world example?
>
> I'm making an argument that this is already a pretty niche situation
> here.
>
> Cheers,
> Cameron Simpson 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UXDUUDLJT4JASMBOM7TJXL36MGD3BYI2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OX73FEXG5LOGGMBWBIEVU443P55Y3VBA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Ricky Teachey]

On Fri, Jun 11, 2021 at 10:12 AM Thomas Güttler 
wrote:

>
>
> Am Fr., 11. Juni 2021 um 14:51 Uhr schrieb Ricky Teachey <
> ri...@teachey.org>:
>
>> I think this idea is promising but instead of doing it by adding new
>> syntax and a totally different object, why not attach a __templates__
>> dunder member to every string but only OPTIONALLY populate it when a string
>> is formatted?
>>
>>
> I am very happy that you think this is promising.
>
> Changing the interface of every string in Python feels much too big for
> me. I don't dare to think about it.
> I have concerns that it could have negative impacts on parts which I am
> not aware of.
>


I'm not a python internals expert, but i am imagining it wouldn't be a very
significant performance hog for anyone not interested in the feature...
seems like all that would be added is the equivalent of a __slot__ to the
str class object, and a reference to None inside it. so the memory
footprint of every string object would not have to grow. the class just
grows a new dunder.

the templated string objects themselves would have to have a bigger memory
footprint of course. but the user/developer is choosing to do that by using
templated strings.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OKIQ6SQHY7A7SLE4CMPSO7LM66BPUVVI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Fr., 11. Juni 2021 um 14:51 Uhr schrieb Ricky Teachey :

> I think this idea is promising but instead of doing it by adding new
> syntax and a totally different object, why not attach a __templates__
> dunder member to every string but only OPTIONALLY populate it when a string
> is formatted?
>
>
I am very happy that you think this is promising.

Changing the interface of every string in Python feels much too big for me.
I don't dare to think about it.
I have concerns that it could have negative impacts on parts which I am not
aware of.



> For every regular string it would just be None:
>
>  >>> "".__template__
>  >>>
>
> But if you create a string using an f string, you can provide a directive,
> as part of the format specification mini language, to store it:
>
>  >>> s = f"{foo!t}"
>
> ...or a directive at the front of the string to store all the f string
> arguments:
>
>  >>> s = ft"{foo}"
>
> This would save the values marked for storage as a tuple of Template
> arguments in the __templates__ member for later. It may also be desirable
> for the Template object to store the name foo and the position in the
> string the foo object was formatted.
>
>
The "t" prefix makes sense.

I would reduce it from ft'...' to t'...'. But it looks good. This is in the
"alternatives":
https://github.com/guettli/peps/blob/master/pep-.rst#alternative-ideas

I am happy with backticks and/or t'...'. Backticks look a bit "cleaner" to
my eyes, but I
am fine with the "t" prefix, too.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XYGGM6O5YMFLNOY4ADCTNFUJIUCQN5PV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Define functions without parentheses (if no parameters given)

[Johnathan Irvin]

non sequitur

Route functions as seen in flask or fastapi.

These functions are often decorated by a route, and may not apply here but
are often found with routes that return a page that doesn't take parameters
such as a home page or a contact page.

On Thu, Jun 10, 2021, 10:30 PM Cameron Simpson  wrote:

> On 11Jun2021 10:01, Cameron Simpson  wrote:
> >So your idea does not suck. But it may not motivate anyone to implement
> >it, or even to agreed that it should be implemented.
>
> It also struck me: functions with _no_ parameters are pretty rare.
>
> I had a glance through my own code and aside from some closures
> (functions within a running function, getting their variables from the
> enclosing scope) I've got a few which either access state from some
> global or which generate something standalone, eg a primes() function
> which just generates the primes starting from 2, a function I maybe even
> don't use. They are very few.
>
> So these seem pretty rare. Just how often do you write such a function
> yourself? Got a real world example?
>
> I'm making an argument that this is already a pretty niche situation
> here.
>
> Cheers,
> Cameron Simpson 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/UXDUUDLJT4JASMBOM7TJXL36MGD3BYI2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DNDJHT3BYQGFV6ZF56U5KGQQVKXBBZVM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] copy-paste code snippets to the python console

[Raymond Bisdorff]

Dear Python developers,

It would be helpful, if the following issue with copy-pasting python 
code-snippets into the standard shell console, could be investigated and 
corrected.


https://stackoverflow.com/questions/2501208/copying-and-pasting-code-into-the-python-interpreter

In particular, copying and pasting from sphinx python and pycon 
code-blocks with copy button (only >>> and ... lines), is at present not 
generally working due to the  "the shell-s de-indent cmd" need for empty 
lines.


See https://digraph3.readthedocs.io/en/latest/index.html

Thank you in advance for you attention,

Best Regards,

Raymond Bisdorff

--
Raymond Bisdorff
Emeritus Professor of Computer Science and Applied Mathematics
University of Luxembourg
http://rbisdorff.github.io/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6X6G52BYEDQYTZPX2FV5JJ4P4JH4VIL3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Ricky Teachey]

I think this idea is promising but instead of doing it by adding new syntax
and a totally different object, why not attach a __templates__ dunder
member to every string but only OPTIONALLY populate it when a string is
formatted?

For every regular string it would just be None:

 >>> "".__template__
 >>>

But if you create a string using an f string, you can provide a directive,
as part of the format specification mini language, to store it:

 >>> s = f"{foo!t}"

...or a directive at the front of the string to store all the f string
arguments:

 >>> s = ft"{foo}"

This would save the values marked for storage as a tuple of Template
arguments in the __templates__ member for later. It may also be desirable
for the Template object to store the name foo and the position in the
string the foo object was formatted.

So:

 >>> foo = "spam"
 >>> s = f"{foo!t}"

Now instead of being None, s.__template__ would store an object recording
the name foo, what was passed to foo, and the position:

 >>> s.__templates___
(
Template (name="foo", value="spam", position=(0,4)),
)

You could do the same with positional f string arguments, but using an
integer as the name.

An html or log function would later use, or discard, the template
information as it sees fit.


On Fri, Jun 11, 2021, 6:23 AM Thomas Güttler 
wrote:

>
>
> Am Fr., 11. Juni 2021 um 11:10 Uhr schrieb Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp>:
>
>> Thomas Güttler writes:
>>  > Am Fr., 11. Juni 2021 um 03:17 Uhr schrieb Stephan Hoyer <
>> sho...@gmail.com>:
>>
>>  > > Unevaluated f-strings is a nice way to think about this
>>  > > functionality.
>>
>> But they're not "unevaluated" in a lot of important ways.  A better
>> term might be "pre-assembled". :-)
>>
>>  > > Another use-case that comes to mind is logging. The Google Python
>> style
>>  > > guide says not to use f-strings, for example, because it wants to be
>> able
>>  > > to collect the unexpanded pattern strings and not waste time
>> rendering
>>  > > unlogged messages:
>>  > > https://google.github.io/styleguide/pyguide.html#3101-logging
>>  >
>>  > Thank you Stephan for this feedback. I added Logging to the draft:
>>  > https://github.com/guettli/peps/blob/master/pep-.rst#logging
>>
>> If this does solve the logging problem, it would be a killer app (but
>> that still might not be enough, given that PEP 501 couldn't clear the
>> bar and logging was a leading application for that PEP).  Perhaps you
>> should focus on that rather than the HTML escaping problem.
>>
>>
> Hi Stephen,
>
> I can't solve a problem which I don't know. Logging plays no big role
> in my development tasks any more. I use checks, metrics and sentry.
> In the past logging was important for me, but this changed.
>
> But I am sure that the proposal can be used to improve logging.
>
> Regards,
>   Thomas
>
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/YEYP2POOB5S5DULJKIQKB3O75RBWUM7Q/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CG3SJQ5O2NVTHYOIQROHKQ4MLV2G7X5K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Define functions without parentheses (if no parameters given)

[Steven D'Aprano]

On Fri, Jun 11, 2021 at 10:01:06AM +1000, Cameron Simpson wrote:

> Another thing to keep in mind with any syntax suggestion (not that it 
> applies well here, because really, what else can your suggestion mean?) 
> it that every addition syntax is a detour into the unused space of 
> possible token paths.

I'm not arguing for or against it, but parenthesis-free definitions 
"could" mean something rather different, such as (let's say) a function 
that uses dynamic scoping instead of lexical, and always gets its 
arguments from the calling scope.

def func:
return min(a, 10)

# first caller
a = 5
print(func())  # --> 5

# second caller
def my_function():
   a = 20
   print(func())
my_function()  # --> 10


If I wanted dynamic scopes, I wouldn't design the API that way. But we 
could.

Another possibility would be computed values (sort of like properties):

def now:
return strftime('%H:%M:%S')

print(now)  # --> 21:23:20
time.sleep(15)
print(now)  # --> 21:23:35

The point here is to agree with Cameron that every time we choose to use 
syntax for one thing, that precludes us from using that same syntax for 
a different thing.


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HJAFAC4XCHNMH3KFQLPPWX5AVQXHYCCI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Fr., 11. Juni 2021 um 11:10 Uhr schrieb Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp>:

> Thomas Güttler writes:
>  > Am Fr., 11. Juni 2021 um 03:17 Uhr schrieb Stephan Hoyer <
> sho...@gmail.com>:
>
>  > > Unevaluated f-strings is a nice way to think about this
>  > > functionality.
>
> But they're not "unevaluated" in a lot of important ways.  A better
> term might be "pre-assembled". :-)
>
>  > > Another use-case that comes to mind is logging. The Google Python
> style
>  > > guide says not to use f-strings, for example, because it wants to be
> able
>  > > to collect the unexpanded pattern strings and not waste time rendering
>  > > unlogged messages:
>  > > https://google.github.io/styleguide/pyguide.html#3101-logging
>  >
>  > Thank you Stephan for this feedback. I added Logging to the draft:
>  > https://github.com/guettli/peps/blob/master/pep-.rst#logging
>
> If this does solve the logging problem, it would be a killer app (but
> that still might not be enough, given that PEP 501 couldn't clear the
> bar and logging was a leading application for that PEP).  Perhaps you
> should focus on that rather than the HTML escaping problem.
>
>
Hi Stephen,

I can't solve a problem which I don't know. Logging plays no big role
in my development tasks any more. I use checks, metrics and sentry.
In the past logging was important for me, but this changed.

But I am sure that the proposal can be used to improve logging.

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YEYP2POOB5S5DULJKIQKB3O75RBWUM7Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Stephen J. Turnbull]

Thomas Güttler writes:
 > Am Fr., 11. Juni 2021 um 03:17 Uhr schrieb Stephan Hoyer :

 > > Unevaluated f-strings is a nice way to think about this
 > > functionality.

But they're not "unevaluated" in a lot of important ways.  A better
term might be "pre-assembled". :-)

 > > Another use-case that comes to mind is logging. The Google Python style
 > > guide says not to use f-strings, for example, because it wants to be able
 > > to collect the unexpanded pattern strings and not waste time rendering
 > > unlogged messages:
 > > https://google.github.io/styleguide/pyguide.html#3101-logging
 > 
 > Thank you Stephan for this feedback. I added Logging to the draft:
 > https://github.com/guettli/peps/blob/master/pep-.rst#logging

If this does solve the logging problem, it would be a killer app (but
that still might not be enough, given that PEP 501 couldn't clear the
bar and logging was a leading application for that PEP).  Perhaps you
should focus on that rather than the HTML escaping problem.

Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KSZP5BL26S37N4M6IINMV2JADCX6QAWC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Do., 10. Juni 2021 um 17:56 Uhr schrieb Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp>:

> Thomas Güttler writes:
>
>  > This really helps developers to avoid cross-site-scripting attacks
>  > by enabling a secure escaping of all strings which are not
>  > explicitly marked as safe.
>
> Frameworks can already do this by unconditionally applying a function
> like conditional_escape to all evaluated template variables.  (If
> that's too drastic for your taste, there could be a pragma
> %conditional_escape_everything to turn it on.)  Why don't they?  If
> it's not "they just didn't think of it", and there's a real reason,
> why doesn't that reason apply to your template literals?
>
>
I don't understand what you mean with "pragma
%conditional_escape_everything".
Could you please elaborate?




> Note that str has no "safe" attribute, and attributes defined by a
> framework are not known to Python.  You need to explain how you can
> Python-evaluate an expression to a str as your template literal does,
> and still preserve the "safe" mark that I presume is an attribute of a
> class defined by the framework.
>
>
That "safe" attribute is outside the scope of the PEP.

At least in Django there is a way to handle this.


I guess the problem of accessing the framework's attribute can be
> solved by delegating that to the __format__ method of the framework
> type, and maybe preserving it can be handled by having that __format__
> method return a subclass of str.
>
>



> But this reintroduces a strong possibility of programmer error,
> because any function that constructs and returns a new str will strip
> the "safe" mark.  This happens *before* the __format__ method can be
> invoked -- str's __format__ does not check for a safe mark -- so it's
> a real problem.


In Django this is solved via mark_safe(), conditional_escape() and
fomat_html().



> This might dramatically reduce the utility of these
> template literals because it's simply not safe to allow the full range
> of expressions that f-strings allow.  (That could be a YAGNI, but you
> need to explain and if possible document that.)  Also, this means that
> frameworks can no longer just inherit from str: they need to
> reimplement literally every method that returns str, or prohibit its
> use in templates.
>
> Note that 'is_literal' is not the same as "safe".  Based on the
> example, this is intentional: is_literal simply means that this isn't
> the value of an expression, simplifying implementation of the internal
> function that evaluates the template string to a TemplateLiteral.  But
> this means that the function joining a TemplateLiteral needs to
> consider both is_literal (which is safe but apparently unmarked) and
> the 'safe' attribute.  This seems more complicated than it needs to
> be.
>
>
conditional_escape() escapes everything which is not marked "safe".
The body of the template is considered safe.

Please provide an example how to simplify
`template_literal_to_safestring()` of
the draft:
https://github.com/guettli/peps/blob/master/pep-.rst#specification




> TemplateLiteral is not a good name for that type.  The backtick
> construct is a literal (except it's really not ;-), the
> TemplateLiteral is a constructed value.  TemplateValue or
> TemplateTokenSequence or something like that might be a better name.
> In any case it's a little confusing that both the syntax and the value
> are called "literal".  It's not impossible to understand, but at least
> for me I have to think "is this the syntax or is this an object?"
> every time I see it.
>
>
Thank you for the idea for alternative names. I added them
to the PEP. I am open, and think that finding the right name
is important.

I guess the average user won't notice the word "literal" at all.

He/she will see: `Hello {name}` is the way to create
a HTML fragment and he/she will do so.


Thank you for your feedback,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LJWBFYHK4GDF35C65YXLCBGC4QQDZCR7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Fr., 11. Juni 2021 um 03:17 Uhr schrieb Stephan Hoyer :

> On Thu, Jun 10, 2021 at 7:10 AM Chris Angelico  wrote:
>
>> This proposal is basically for a way to take an f-string-like
>> construct and, instead of calling format() on each of the values and
>> joining them together into a string, you do something else with it. Or
>> from a language perspective, you package it all up and hand it to a
>> custom function.
>>
>> So it's basically an f-string minus the final step - which is why PEP
>> 501 described f-strings in terms of interpolated strings.
>>
>
> Unevaluated f-strings is a nice way to think about this functionality.
>
> Another use-case that comes to mind is logging. The Google Python style
> guide says not to use f-strings, for example, because it wants to be able
> to collect the unexpanded pattern strings and not waste time rendering
> unlogged messages:
> https://google.github.io/styleguide/pyguide.html#3101-logging
>


Thank you Stephan for this feedback. I added Logging to the draft:
https://github.com/guettli/peps/blob/master/pep-.rst#logging

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SNVRBK645PHEVBPNZI4OULLWXP37C54P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Fr., 11. Juni 2021 um 00:10 Uhr schrieb Christopher Barker <
python...@gmail.com>:

> There may well be use cases for this, but one thing struck me. From the
> PEP:
>
> "Template Literals provide an easy way to access the local and global
> variables (like f-strings), so that passing a dictionary to the Template is
> not necessary."
>
> This seems to be crossing the line between "data" and "code" -- that's a
> line that can get pretty fuzzy in Python, but it's still a distinction I
> find helpful to think about.
>
> f-strings provide an easy way to build strings with stuff stored in code:
> local variables. This makes them very helpful for things like building
> Exception messages and the like, or showing the results of computation.
>
> But for the most part, populating a template is likely to be done from
> data, rather than code -- results of a database query, or what have you. So
> this kind of template building is usually very well suited to passing a
> dictionary around, rather than using the local namespace.
>
>
If you don't create HTML with Python daily, then you might not feel the
pain.

If you create many HTML strings daily, then you will be typing `foo=foo,
bar=bar` (to pass the variables
into the template) over and over again.

I would reduce cognitive load if you could avoid reading/writing `foo=foo,
bar=bar`.

My goal is to have a super reduced syntax, so that developers need only a
few characters
to create save (properly escaped) html with Python.

In the past people created whole HTML pages. There it made sense to use a
template language.

But if you use FrOW, then you will create many small methods returning
small fragments, and
then this small extra work of passing in variables gets  (please insert
your favorite negative  adjective).

Back your point "data vs code".

The new class types.TemplateLiteral is pure data. It is up to the consumer
to process the data.

Of course I am biased, since my main concern is creating HTML. But I guess
there are several other
use-cases where a TemplateLiteral could be used.



> Even if you are using Python objects to model your data (e.g. dataclasses
> and the like) -- you still have:
> a) one object to pass in to your template builder
> and/or
> b) an easy way to make a dict out of the object to pass into a template.
>
> I could be missing something, but I just don't see the benefits of having
> f-string like access to local variables in this context.
>
> -CHB
>
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3PFAMX2GDHUB4UUSXVNTBSGPUSHIVGPA/
Code of Conduct: http://python.org/psf/codeofconduct/