Mailman 3 PEP 498 f-string: please remove the special case for spaces - Python-Dev

PEP 498 f-string: please remove the special case for spaces

Victor Stinner

11 Aug 2015 11 Aug '15

12:54 a.m.

PEP 498: """ Leading whitespace in expressions is skipped https://www.python.org/dev/peps/pep-0498/#id28 Because expressions may begin with a left brace ('{'), there is a problem when parsing such expressions. For example:

...

...
...
f'{{k:v for k, v in [(1, 2), (3, 4)]}}' '{k:v for k, v in [(1, 2), (3, 4)]}'

""" For me, this example is crazy. You should not add a special case (ignore spaces) just to support a corner case. This example can easily be rewritten using a temporary variable and it makes the code simpler. items={k:v for k, v in [(1, 2), (3, 4)]; f'{items}' Seriously, a dict-comprehension inside a f-string should be considered as an abuse of the feature. Don't you think so? Victor

Attachments:

attachment.htm (text/html — 2.9 KB)

Show replies by thread

Victor Stinner

11 Aug 11 Aug

1 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

By the way, I don't think that fu'...' syntax should be allowed. IMHO u'...' was only reintroduced to Python 3.3 to ease transition from Python 2 to Python 3 of the existing u'...' Syntax. Since f'...' is a new syntax, backward compatibility doesn't matter here. Victor

Eric V. Smith

1:04 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 6:54 PM, Victor Stinner wrote:

...

PEP 498:

"""

Leading whitespace in expressions is skipped https://www.python.org/dev/peps/pep-0498/#id28

Because expressions may begin with a left brace ('{'), there is a problem when parsing such expressions. For example:

...
...
...
f'{{k:v for k, v in [(1, 2), (3, 4)]}}' '{k:v for k, v in [(1, 2), (3, 4)]}'

"""

For me, this example is crazy. You should not add a special case (ignore spaces) just to support a corner case.

This example can easily be rewritten using a temporary variable and it makes the code simpler.

items={k:v for k, v in [(1, 2), (3, 4)]; f'{items}'

Seriously, a dict-comprehension inside a f-string should be considered as an abuse of the feature. Don't you think so?

Yes, it's absolutely an abuse and should never be written. But if the only "cost" to allowing it is skipping leading spaces, I don't see the harm. It sounds like you want to disallow leading spaces just to disallow this one type of expression. My other use case for spaces, which I've not added to the PEP yet, is for alignment, like: f' x={ x:15}' f'xx={xx:15}' Eric.

MRAB

1:17 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On 2015-08-10 23:54, Victor Stinner wrote:

...

PEP 498:

"""

Leading whitespace in expressions is skipped https://www.python.org/dev/peps/pep-0498/#id28

Because expressions may begin with a left brace ('{'), there is a problem when parsing such expressions. For example:

...
...
...
f'{{k:v for k, v in [(1, 2), (3, 4)]}}' '{k:v for k, v in [(1, 2), (3, 4)]}'

"""

For me, this example is crazy. You should not add a special case (ignore spaces) just to support a corner case.

Is it a special case? Don't we already ignore leading spaces in bracketed expressions?

...

This example can easily be rewritten using a temporary variable and it makes the code simpler.

items={k:v for k, v in [(1, 2), (3, 4)]; f'{items}'

Seriously, a dict-comprehension inside a f-string should be considered as an abuse of the feature. Don't you think so?

True. Or we can wrap it in parentheses. :-)

Victor Stinner

1:26 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

Le mardi 11 août 2015, Eric V. Smith a écrit :

...

It sounds like you want to disallow leading spaces just to disallow this one type of expression.

I would like to reduce the number of subtle differences between f-string and str.format(). Victor

Eric V. Smith

1:31 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 7:26 PM, Victor Stinner wrote:

...

Le mardi 11 août 2015, Eric V. Smith mailto:eric@trueblade.com> a écrit :

It sounds like you want to disallow leading spaces just to disallow this one type of expression.

I would like to reduce the number of subtle differences between f-string and str.format().

The expressions supported are so vastly different that I don't think the whitespace issue matters. Eric.

Cameron Simpson

1:58 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On 11Aug2015 01:00, Victor Stinner wrote:

...

By the way, I don't think that fu'...' syntax should be allowed. IMHO u'...' was only reintroduced to Python 3.3 to ease transition from Python 2 to Python 3 of the existing u'...' Syntax. Since f'...' is a new syntax, backward compatibility doesn't matter here.

There's another reason to resist the fu'...' prefix: political correctness. To illustrate, there's a consumer rights TV snow here with a segment called "F.U. Tube", where members of the public describe ripoffs and other product failures in video form. While a phonetic play on the name "YouTube", the abbreviation also colloquially means just what you think it might. I can just imagine reciting one of these new strings out loud... Cheers, Cameron Simpson People shouldn't be allowed to build overpasses ... - Dianne "I know what's best for you" Feinstein after the '94 LA quake.

MRAB

2 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On 2015-08-11 00:26, Victor Stinner wrote:

...

Le mardi 11 août 2015, Eric V. Smith mailto:eric@trueblade.com> a écrit :

It sounds like you want to disallow leading spaces just to disallow this one type of expression.

I would like to reduce the number of subtle differences between f-string and str.format().

I'm a little bit surprised at seeing this:

...

...
...
'{0}'.format('foo') 'foo' '{ 0}'.format('foo') Traceback (most recent call last): File "<stdin>", line 1, in <module> KeyError: ' 0' '{a}'.format(a='foo') 'foo' '{ a}'.format(a='foo') Traceback (most recent call last): File "<stdin>", line 1, in <module> KeyError: ' a'

In some other cases, leading and trailing spaces are ignored:

...

...
...
int(' 0 ') 0

Outside string literals, they're also ignored. But, then:

...

...
...
'{-1}'.format('foo') Traceback (most recent call last): File "<stdin>", line 1, in <module> KeyError: '-1'

It's a string key, even though it looks like an int position.

Victor Stinner

2:04 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

Le mardi 11 août 2015, MRAB a écrit :

...

I'm a little bit surprised at seeing this: (...)

We may modify str.format to ignore leading spaces, but IMHO it should not be motivated by the PEP. Victor

Eric V. Smith

2:04 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 8:00 PM, MRAB wrote:

...

On 2015-08-11 00:26, Victor Stinner wrote:

...
Le mardi 11 août 2015, Eric V. Smith mailto:eric@trueblade.com> a écrit :

It sounds like you want to disallow leading spaces just to disallow this one type of expression.

I would like to reduce the number of subtle differences between f-string and str.format().

I'm a little bit surprised at seeing this:

...
...
...
'{0}'.format('foo') 'foo' '{ 0}'.format('foo') Traceback (most recent call last): File "<stdin>", line 1, in <module> KeyError: ' 0' '{a}'.format(a='foo') 'foo' '{ a}'.format(a='foo') Traceback (most recent call last): File "<stdin>", line 1, in <module> KeyError: ' a'

In some other cases, leading and trailing spaces are ignored:

...
...
...
int(' 0 ') 0

Outside string literals, they're also ignored.

But, then:

...
...
...
'{-1}'.format('foo') Traceback (most recent call last): File "<stdin>", line 1, in <module> KeyError: '-1'

It's a string key, even though it looks like an int position.

I think there are bug tracker issues for both of these. I think the argument against changing them is that people might be depending on this behavior. I'll grant you it seems unlikely, but you never know. Eric.

Eric V. Smith

2:07 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On 8/10/2015 8:04 PM, Victor Stinner wrote:

...

Le mardi 11 août 2015, MRAB mailto:python@mrabarnett.plus.com> a écrit :

I'm a little bit surprised at seeing this: (...)

We may modify str.format to ignore leading spaces, but IMHO it should not be motivated by the PEP.

Agreed. Eric.

Greg Ewing

8:07 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

Cameron Simpson wrote:

...

To illustrate, there's a consumer rights TV snow here with a segment called "F.U. Tube", where members of the public describe ripoffs and other product failures in video form. While a phonetic play on the name "YouTube", the abbreviation also colloquially means just what you think it might. I can just imagine reciting one of these new strings out loud...

We could require it to be spelled "uf" unless "from __future__ import billy_connolly_as_FLUFL" is in effect. -- Greg

Cameron Simpson

9:08 a.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On 11Aug2015 18:07, Greg Ewing wrote:

...

Cameron Simpson wrote:

...
To illustrate, there's a consumer rights TV snow here with a segment called "F.U. Tube", where members of the public describe ripoffs and other product failures in video form. While a phonetic play on the name "YouTube", the abbreviation also colloquially means just what you think it might. I can just imagine reciting one of these new strings out loud...

We could require it to be spelled "uf" unless "from __future__ import billy_connolly_as_FLUFL" is in effect.

That seems like a reasoned and measured response. Cheers, Cameron Simpson For those who understand, NO explanation is needed, for those who don't understand, NO explanation will be given! - Davey D

Chris Angelico

1:51 p.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On Tue, Aug 11, 2015 at 5:08 PM, Cameron Simpson wrote:

...

On 11Aug2015 18:07, Greg Ewing wrote:

...
Cameron Simpson wrote:

...
To illustrate, there's a consumer rights TV snow here with a segment called "F.U. Tube", where members of the public describe ripoffs and other product failures in video form. While a phonetic play on the name "YouTube", the abbreviation also colloquially means just what you think it might. I can just imagine reciting one of these new strings out loud...

We could require it to be spelled "uf" unless "from __future__ import billy_connolly_as_FLUFL" is in effect.

That seems like a reasoned and measured response.

Given the levels of profanity that are not disallowed in identifier names, I think blocking off a two-letter prefix is pretty pointless. It'd be different if the specification _required_ it (though even then, it's not that big a deal...), but merely permitting it? Not Python's fault. ChrisA

Steven D'Aprano

2:47 p.m.

New subject: PEP 498 f-string: please remove the special case for spaces

On Tue, Aug 11, 2015 at 09:51:56PM +1000, Chris Angelico wrote:

...

On Tue, Aug 11, 2015 at 5:08 PM, Cameron Simpson wrote:

...
On 11Aug2015 18:07, Greg Ewing wrote:

...
Cameron Simpson wrote:

...
To illustrate, there's a consumer rights TV snow here with a segment called "F.U. Tube", where members of the public describe ripoffs and other product failures in video form. While a phonetic play on the name "YouTube", the abbreviation also colloquially means just what you think it might. I can just imagine reciting one of these new strings out loud...

We could require it to be spelled "uf" unless "from __future__ import billy_connolly_as_FLUFL" is in effect.

That seems like a reasoned and measured response.

Given the levels of profanity that are not disallowed in identifier names, I think blocking off a two-letter prefix is pretty pointless. It'd be different if the specification _required_ it (though even then, it's not that big a deal...), but merely permitting it? Not Python's fault.

Er, if it's not Python's doing, whose doing is it? There's a difference between not censoring identifiers written by the user, and creating syntax. I don't think anyone would blame the language if I created an identifier "poop", say, but if the language included a keyword "poop" or a syntax feature, say, poop-lists: poop[a, b, c, d] then one might wonder what the language designers were thinking. I've already seen a bit of sniggering on Reddit about fu strings. In the grand scheme of things, worrying about fu strings is pretty low on the list of priorities. But if there is no need to allow fu as a prefix, or if there is another equally good prefix to use instead of f, then there's no harm done by disappointing the 14 year olds. -- Steve

3179

Age (days ago)

3180

Last active (days ago)

List overview

Download

14 comments

7 participants

participants (7)

Cameron Simpson
Chris Angelico
Eric V. Smith
Greg Ewing
MRAB
Steven D'Aprano
Victor Stinner

PEP 498 f-string: please remove the special case for spaces

Cameron Simpson

Cameron Simpson

tags

participants (7)