undefined | Better HN

0 pointsenriquto6y ago0 comments

I meant for inline strings (i.e., typed by the programmer). This is an inoffensive change. The only possible ``accident'' is when the programmer wants to write "{x}" instead of the value of x. This is such and exceptional case that it may be best treated by forcing to escape the curly brackets.

If anything, user-input strings must be treated as tainted whatever the case.

0 comments

4 comments · 4 top-level

eesmith6y ago

A quick look at the Python stdlib gives shows some of the breakage that would occur:

1) existing uses of .format() would break:

   aifc.py: raise Error('marker {0!r} does not exist'.format(id))

2) existing uses of "%" formatting would break:

    argparse.py: result = '{%s}' % ','.join(choice_strs)

3) many regular expressions would break:

    uuid.py: if re.fullmatch('(?:[0-9a-f][0-9a-f]-){5}[0-9a-f][0-9a-f]', value):

4) existing strings which contain uuids would break:

    uuid.py: >>> x = uuid.UUID('{00010203-0405-0607-0809-0a0b0c0d0e0f}')

ptx6y ago

Then you would run into the same problem Kotlin has with its raw strings – the brackets need to be escaped, but raw strings disable escaping, so you'd have to write r"{}" as r"{'\{\}'}" which is quite ugly and not very raw at all.

Grue36y ago

It's not an exceptional use case at all. f-strings are pretty much useless for any non-trivial formatting:

1) customizable templates (can't allow the user to access arbitrary variables)

2) i18n (can't allow the translator to access arbitrary variables)

3) complex values being passed to .format() instead of some variable

duckerude6y ago

That would break any existing strings that use curly braces, including most legacy use of str.format and docstrings that include code examples with dictionaries. It would be a big backward compatibility issue.

j / k navigate · click thread line to collapse