undefined | Better HN

0 pointsGeorgeTirebiter3y ago0 comments

Yes, my use case was "I always use F-strings" so these other breakages could not occur, by definition.

I suppose it's not that much of a problem to run a program to preprocess source and add in the F

But.. Python has a history of introducing new features that break old ones. That seems to me a balance between backward compatibility and future goodness.

the "from future import auto-fstring" construct could do it...

And, as for having to run the f-string parser: yes, but only once on static strings, which are most of them.

0 comments

chrisshroba3y ago

It's not clear to me that folks would want this behavior globally - I personally would not, because sometimes I want to be able to include curly braces in my strings without it being interpolated, and I prefer the current syntax of having that just work. I'm very comfortable with having to add the 'f' to the string syntax to declare that this particular string should be interpolated.

There are other issues you'd have to deal with as well. Would you interpolate non-literal strings (e.g. in the code `print(input())`, if the user inputs the string "{1+1}", what would be printed?)? How would you propose dealing with jinja and other strings that typically contain curly braces that should not be interpolated? This could also be an issue with (potentially long) strings containing lots of random characters: if a '}' showed up in a string somewhere after a '{', even if separated by tens or hundreds of characters, then you'll run into errors. This could be a problem if you're dealing with pseudorandom or base-92 encoded strings, or even just strings representing code (imagine a python library that generates C++ or Java code which has lots of hard coded strings with braces).

I think overall, having to specify that a particular string should be interpolated is a better solution than having to specify that a string should not be interpolated.

GeorgeTirebiterOP3y ago

Well, you could put a N" your string with{} in it" to type-specify that you are not F-string. In fact, WHY are strings not fully specified every time? There is nothing wrong with F"This is also an f-string". After all, strings are just number sequences with special meanings assigned to some values in some circumstances.

Seems to me the problem is similar to wanting 1 be interpreted as an int --- if you want float, you change the syntax (and therefore semantics) to 1. or 1.0

It's always possible to conjure corner-case failure modes; but shouldn't the 'common case' be catered to, more than some base-92 encoded strings?

And, by the by, more 'smarts' can be applied to automatic f-string determination. If "{variable-that-exists} foobar" is seen it could plausibly be converted to an f-string.

This leads into a much longer discussion of how our compilers/interpreters are too stupid today, and need to up their game. But probably not here, not now.... and also, thank you for your observations & comments.

dragonwriter3y ago

> It's always possible to conjure corner-case failure modes; but shouldn't the 'common case' be catered to

It is: normal strings are the common case.

1 more reply

dumpsterdiver3y ago

> And, by the by, more 'smarts' can be applied to automatic f-string determination. If "{variable-that-exists} foobar" is seen it could plausibly be converted to an f-string.

One obvious and dangerous application of these "smarts" is when people expect curly braces to be treated as string literals. What if a string contained an example f-string that contained {sensitive-server-information}? It's reasonable to expect that code like that wouldn't later become vulnerable to injection attacks.

masklinn3y ago

> Yes, my use case was "I always use F-strings" so these other breakages could not occur, by definition.

Unless you're using any dependency at all, including the standard library.

> But.. Python has a history of introducing new features that break old ones.

It doesn't tho.

> That seems to me a balance between backward compatibility and future goodness.

That assumes "everything is an fstring" is considered "future goodness", which I'm not sure is a widely shared view.

> the "from future import auto-fstring" construct could do it...

That seems unlikely as the __future__ pseudo-package has generally been used to opt into hopefully future behaviour.

Given the Python 3 experience, somehow, I don't see "let's make all string literals into fstrings" happen any time soon, but hey feel free to create a PEP proposing that.

Alternatively, create your own import hook which does this swap before handing the module off of to the compiler.

j / k navigate · click thread line to collapse