On Thu, Jul 8, 2021 at 6:25 PM Nick Coghlan wrote:
> On Tue, 6 Jul 2021, 7:56 am Jim Baker, wrote:
>
>>
>>
>> On Mon, Jul 5, 2021, 2:40 PM Guido van Rossum wrote:
>>
>>> FWIW, we could make f-strings properly nest too, like you are proposing
>>> for backticks. It's just that we'd have to
On Tue, 6 Jul 2021, 7:56 am Jim Baker, wrote:
>
>
> On Mon, Jul 5, 2021, 2:40 PM Guido van Rossum wrote:
>
>> FWIW, we could make f-strings properly nest too, like you are proposing
>> for backticks. It's just that we'd have to change the lexer. But it would
>> not be any harder than would be
On Mon, Jul 5, 2021 at 5:05 PM Chris Angelico wrote:
> On Tue, Jul 6, 2021 at 9:39 AM Greg Ewing
> wrote:
> >
> > On 6/07/21 9:56 am, Jim Baker wrote:
> > >
> > > d = deferred_tag"Some expr: {:(x*2)}"
> > >
> > > All that is happening here is that this being wrapped in a lambda,
> which
> > >
On Tue, Jul 6, 2021 at 10:44 AM Guido van Rossum wrote:
>
> On Mon, Jul 5, 2021 at 5:05 PM Chris Angelico wrote:
>>
>> On Tue, Jul 6, 2021 at 9:39 AM Greg Ewing
>> wrote:
>> >
>> > On 6/07/21 9:56 am, Jim Baker wrote:
>> > >
>> > > d = deferred_tag"Some expr: {:(x*2)}"
>> > >
>> > > All that
On Tue, Jul 6, 2021 at 9:39 AM Greg Ewing wrote:
>
> On 6/07/21 9:56 am, Jim Baker wrote:
> >
> > d = deferred_tag"Some expr: {:(x*2)}"
> >
> > All that is happening here is that this being wrapped in a lambda, which
> > captures any scope lexically as usual.
>
> Is there reason to think this
On 6/07/21 9:56 am, Jim Baker wrote:
d = deferred_tag"Some expr: {:(x*2)}"
All that is happening here is that this being wrapped in a lambda, which
captures any scope lexically as usual.
Is there reason to think this will be a common enough requirement
to justify having an abbreviated
On 6/07/21 8:39 am, Guido van Rossum wrote:
FWIW, we could make f-strings properly nest too... So this is
not an argument for backticks.
An argument might be that single and double quotes currently do
not nest and never have done, so having them start to nest but only
in the context of
On Mon, Jul 5, 2021, 2:40 PM Guido van Rossum wrote:
> FWIW, we could make f-strings properly nest too, like you are proposing
> for backticks. It's just that we'd have to change the lexer. But it would
> not be any harder than would be for backticks (since it would be the same
> algorithm),
FWIW, we could make f-strings properly nest too, like you are proposing
for backticks. It's just that we'd have to change the lexer. But it would
not be any harder than would be for backticks (since it would be the same
algorithm), nor would it be backward incompatible. So this is not an
argument
On Mon, Jul 5, 2021 at 4:12 PM Jim Baker wrote:
> in the same way that we don't use l (that's the lower-case letter L if
> you're not reading this email with the numeric codepoints) as a variable
>
Speaking of grit on one's screen, I first thought that was a lowercase "i"
because I had actual
On Tue, Jul 6, 2021 at 6:10 AM Jim Baker wrote:
>
> On Mon, Jul 5, 2021, 12:56 PM Barry Scott wrote:
>>
>>
>>
>> On 5 Jul 2021, at 08:07, Thomas Güttler wrote:
>>
>> This means backticks, but without the dollar sign.
>>
>>
>> In bash the backtick was so often a problem that $(cmd) was added.
>>
On Mon, Jul 5, 2021, 12:56 PM Barry Scott wrote:
>
>
> On 5 Jul 2021, at 08:07, Thomas Güttler wrote:
>
> This means backticks, but without the dollar sign.
>
>
> In bash the backtick was so often a problem that $(cmd) was added.
>
> Having removes the grit-on-Tim's-screen backtick in python 3
> On 5 Jul 2021, at 08:07, Thomas Güttler wrote:
>
> This means backticks, but without the dollar sign.
In bash the backtick was so often a problem that $(cmd) was added.
Having removes the grit-on-Tim's-screen backtick in python 3 I would
not like to see it return with its issue of being
JavaScript's tagged template literals do provide nice ergonomics. These
should work well with some variation on PEP
501's types.InterpolationTemplate as the backend implementation. Some
thoughts on what that should look like:
* I also increasingly prefer the idea of using backticks to define such
Am Fr., 2. Juli 2021 um 12:06 Uhr schrieb Nick Coghlan :
>
>
> On Fri, 2 Jul 2021, 5:12 pm Thomas Güttler,
> wrote:
>
>> Hi Nick and all other Python ideas friends,
>>
>> yes, you are right. There is not much difference between PEP-501 or my
>> proposal.
>>
>> One argument why I would like to
On 02/07/2021 08:12, Thomas Güttler wrote:
Hi Nick and all other Python ideas friends,
yes, you are right. There is not much difference between PEP-501 or my
proposal.
One argument why I would like to prefer backticks:
Some IDEs detect that you want to use a f-string automatically:
You
On Fri, 2 Jul 2021, 5:12 pm Thomas Güttler, wrote:
> Hi Nick and all other Python ideas friends,
>
> yes, you are right. There is not much difference between PEP-501 or my
> proposal.
>
> One argument why I would like to prefer backticks:
>
> Some IDEs detect that you want to use a f-string
Hi Nick and all other Python ideas friends,
yes, you are right. There is not much difference between PEP-501 or my
proposal.
One argument why I would like to prefer backticks:
Some IDEs detect that you want to use a f-string automatically:
You type:
name = 'Peter'
print('Hello {name...
and
Stephen J. Turnbull wrote:
> 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
Am Mo., 14. Juni 2021 um 01:25 Uhr schrieb Chris Angelico :
>
> I'd love to have some sort of generic interpolation construct, but the
> use-cases all seem really weak...
>
>
It depends on your daily work. If you create many small methods returning
small HTML fragments,
then it really helps if
Am Mo., 14. Juni 2021 um 11:12 Uhr schrieb J. Pic :
> On Thu, Jun 10, 2021 at 8:34 AM Thomas Güttler
> wrote:
>
>>
>> This solution has two drawbacks:
>>
>>1. It is too verbose. Typing "conditional_escape(...)" again and
>>again is cumbersome.
>>
>> from django import conditional_espace
>
>
>>1. It is too verbose. Typing "conditional_escape(...)" again and
>> again is cumbersome.
>>
>> from django import conditional_espace as esc
> f'Hi {esc(name)}'
>
It's too bad that ␛ U+251B isn't a valid Python identifier. Then we could
do it in one character :-)
But as I keep
My bad, I had missed nesting template literals support in the PEP, it makes
it interesting then!
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
On Thu, Jun 10, 2021 at 4:07 PM Chris Angelico wrote:
>
> What's the advantage of htmx? When I want to build a good interactive
> web site, my general pattern is a back end with a well-defined API,
> and a front end in JavaScript that makes use of this API. That API is
> usually going to be
On Thu, Jun 10, 2021 at 8:34 AM Thomas Güttler
wrote:
>
> This solution has two drawbacks:
>
>1. It is too verbose. Typing "conditional_escape(...)" again and again
>is cumbersome.
>
> from django import conditional_espace as esc
f'''
Hi {esc(name)}
Your messages: {esc(messages)}
'''
>
On 6/13/2021 7:24 PM, Chris Angelico wrote:
On Mon, Jun 14, 2021 at 8:58 AM Jim Baker wrote:
* Logging strings which don't have to format their expressions - so similar to
current logging when not using f-strings, but with the easy interface of
f-strings, including desired formatting of
On Mon, Jun 14, 2021 at 8:58 AM Jim Baker wrote:
>
> * Logging strings which don't have to format their expressions - so similar
> to current logging when not using f-strings, but with the easy interface of
> f-strings, including desired formatting of expressions in simple logger
> scenarios
>
Supporting JavaScript-style template literals, specifically tagged
templates, could be generally useful. If we look at
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates,
it's a really simple idea:
The tag function is called with the following
On 10/06/2021 15:46, Ricky Teachey wrote:
Makes me wonder if stepping back and thinking, instead, about a way to
automatically (optionally?) put the current calling context
dictionary(ies) somewhere that a called function can get at it/them,
so it can do what it wants with the context.
I
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
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
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__
>>
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 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:
>>>
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
> > >
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
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.
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,
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
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
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
On Thu, Jun 10, 2021 at 10:12 AM Stestagg wrote:
>
> On Thu, Jun 10, 2021 at 2:58 PM Ricky Teachey wrote:
>
>> Something I don't understand is whether there is anything about this
>> proposed feature that can't be accomplished with a simple function...
>>
>
>
>
>>
>> And use it like this:
On Thu, Jun 10, 2021 at 7:31 AM Thomas Güttler
wrote:
> Thank you Guido, Chris, Matt and Richard for your feedback to my last
> email.
>
> Here is an updated version called "Template Literals".
>
>
I much prefer:
Alternative Ideas
Instead of backticks for example t'...' could be used.
instead
On Thu, Jun 10, 2021 at 2:58 PM Ricky Teachey wrote:
> Something I don't understand is whether there is anything about this
> proposed feature that can't be accomplished with a simple function...
>
>
> And use it like this:
>
> >>> templify("Here, have some {foo}.")
>
On Thu, Jun 10, 2021 at 11:58 PM Ricky Teachey wrote:
>
> Something I don't understand is whether there is anything about this proposed
> feature that can't be accomplished with a simple function.
>
> IIUC, the proposal turns this:
>
> foo = "spam & eggs"
> `Here, have some {foo}.`
>
> ...into
On Thu, Jun 10, 2021 at 11:50 PM Thomas Güttler wrote:
>
>
>
> Am Do., 10. Juni 2021 um 15:33 Uhr schrieb David Mertz :
>>
>> Strong -1
>>
>> As others noted in prior discussion, even if this existed, it works be an
>> anti-pattern for SQL. So basically, it's just baking in an HTML-only
>>
Something I don't understand is whether there is anything about this
proposed feature that can't be accomplished with a simple function.
IIUC, the proposal turns this:
foo = "spam & eggs"
`Here, have some {foo}.`
...into something like this (I am making up a more readable repr):
On Thu, Jun 10, 2021 at 2:35 PM David Mertz wrote:
> Strong -1
>
> As others noted in prior discussion, even if this existed, it works be an
> anti-pattern for SQL. So basically, it's just baking in an HTML-only
> template language into the language syntax.
>
> The discussion I could find on the
Well, I share Rob's concern but I do see the point of this:
> Template Literals only make sense if you want to escape values like in
HTML, XML or SQL templates.
Maybe they should have a name to better reflect this intended use case?
Safe Templates, Escaped Strings, I don't know, I'm terrible at
Am Do., 10. Juni 2021 um 15:33 Uhr schrieb David Mertz :
> Strong -1
>
> As others noted in prior discussion, even if this existed, it works be an
> anti-pattern for SQL. So basically, it's just baking in an HTML-only
> template language into the language syntax.
>
> Python already had excellent
Strong -1
As others noted in prior discussion, even if this existed, it works be an
anti-pattern for SQL. So basically, it's just baking in an HTML-only
template language into the language syntax.
Python already had excellent HTML templating in libraries. The fact Django
has a function with a
Am Do., 10. Juni 2021 um 14:42 Uhr schrieb Rob Cliffe via Python-ideas <
python-ideas@python.org>:
> I am concerned that we have too many string formatting methods:
> % formatting
> .format()
> f-strings
> string templates
> (are there others I've missed?).
> And now we have
I am concerned that we have too many string formatting methods:
% formatting
.format()
f-strings
string templates
(are there others I've missed?).
And now we have another proposed one.
It's all getting a bit much. And IMO a turnoff for people learning
Python (which one should I
53 matches
Mail list logo
