[Python-Dev] PEP 498 f-string: please remove the special case for spaces

[Steven D'Aprano]

On Tue, Aug 11, 2015 at 09:51:56PM +1000, Chris Angelico wrote:
> On Tue, Aug 11, 2015 at 5:08 PM, Cameron Simpson <cs at zip.com.au> wrote:
> > On 11Aug2015 18:07, Greg Ewing <greg.ewing at canterbury.ac.nz> 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