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 pre
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
> 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 co
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 I
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 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 li
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, 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), nor
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 f-strin
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 syntax
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 will
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 is
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
> > > ca
13 matches
Mail list logo
