4 ms·

> > We may be looking too deep into this but it seems like many developers think when string concatenation occurs it’s enough to declare the first string as an

> > We may be looking too deep into this but it seems like many developers think when string concatenation occurs it’s enough to declare the first string as an f-string and the other strings are turned into f-strings by osmosis. It doesn’t. We’re not suggesting this is the case for all developers that accidentally did this error, but interesting nonetheless. I highly doubt that people believed that f-strings worked this way. Far more likely is that, for example, the expression started as one line, then got split onto two, or some such similar scenario.

_8j50 5y ago
You'd be surprised, people who expect python to be "smart" and "figure it out" might think that way.
- groestl 5y ago
  Well, it's not completely unlogical. 'a' is str b'a' is bytes f'something' might be a separate f-str-type too? 1 is an int 1.2 is a float (1.2 + 1) is a float
  - GeorgeTirebiter 5y ago
    Indeed, if "{value} is bad" can be automatically f-stringed by an external program automatically --- then why can't Python do this automatically -- so we can get rid of the f-string type as a required explicit declaration? After all, we don't specifically add a type to a number like 42 or 3.14159 --- those are implicitly 'int' and 'float' types. I would use such a feature, as I always use f-strings when formatting.
    - masklinn 5y ago
      > Indeed, if "{value} is bad" can be automatically f-stringed by an external program automatically --- then why can't Python do this automatically -- so we can get rid of the f-string type as a required explicit declaration? Because it would break existing strings containing braces, such as those used with `str.format`, or string.Template, or literal Jinja templates, ...
      - GeorgeTirebiter 5y ago
        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.
        chrisshroba 5y 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.
        GeorgeTirebiter 5y 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.
    - ArchOversight 5y ago
      Because in some cases it is not desired, if for example the string is used in something that expands it further down the line (think SQL injection potential).
    - bagels 5y ago
      Backwards compatibility for one. Code existed before fstrings that may use curly braces, and you can currently use curly braces in non fstrings without escaping them. Might also be a performance penalty for always having to run the fstring parser.
    - dragonwriter 5y ago
      If all strings with what looks like format specs are implicitly f-strings, how do you use reusable template strings, which use the same basic internal syntax, for formatting? f-strings, like r-strings, have uses, but, like r-strings, I wouldn't want to replace plain strings with them.
- HL33tibCe7 5y ago
  As a beginner, maybe. But this is code in some of the biggest open-source Python repos in existence. Probably written by someone with a reasonable level of Python expertise.
  - genewitch 4y ago
    ... and yet?
groestl 5y ago
I think what's happening is that people assume there's type coercion going on here.
johnny_castaway 5y ago
This may be also caused by confusing syntax highlighting in some editors, for example in VSCode [1] The variable in the second string gets highlighted (with slightly different color, but still) because it would still work with `str.format()`. GitHub doesn't seem to do this. [1] https://imgur.com/a/9KGWVG0 https://imgur.com/a/9KGWVG0
- totony 5y ago
  Yeah I got bitten by the same-color syntax highlighting a few times.
jldugger 5y ago
I wonder if an autoformatter like black is at play here.
- saila 5y ago
  Black doesn't split strings, and I doubt they'd choose to use concatenation if they did.
  - hathawsh 5y ago
    I kind of wish Black would split and join literal strings. I've seen several times when Black converted code like this: raise SomeError( "Explanation... " "yet more explanation" ) To this: raise SomeError( "Explanation... " "yet more explanation" ) That just looks odd. Black is fantastic, but not perfect.
  - d0mine 4y ago
    Black does split strings if configured and it does use implicit concatenation of Python string literals.
    - saila 4y ago
      There's an experimental option for splitting long strings using the --preview flag, but it still seems to have some potential issues. That seems like it would be extremely hard to solve correctly.
- xigoi 4y ago
  Black doesn't change the semantics of code.

_8j50 5y ago

You'd be surprised, people who expect python to be "smart" and "figure it out" might think that way.

groestl 5y ago
Well, it's not completely unlogical. 'a' is str b'a' is bytes f'something' might be a separate f-str-type too? 1 is an int 1.2 is a float (1.2 + 1) is a float
- GeorgeTirebiter 5y ago
  Indeed, if "{value} is bad" can be automatically f-stringed by an external program automatically --- then why can't Python do this automatically -- so we can get rid of the f-string type as a required explicit declaration? After all, we don't specifically add a type to a number like 42 or 3.14159 --- those are implicitly 'int' and 'float' types. I would use such a feature, as I always use f-strings when formatting.
  - masklinn 5y ago
    > Indeed, if "{value} is bad" can be automatically f-stringed by an external program automatically --- then why can't Python do this automatically -- so we can get rid of the f-string type as a required explicit declaration? Because it would break existing strings containing braces, such as those used with `str.format`, or string.Template, or literal Jinja templates, ...
    - GeorgeTirebiter 5y ago
      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.
      - chrisshroba 5y 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.
        GeorgeTirebiter 5y 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.
  - ArchOversight 5y ago
    Because in some cases it is not desired, if for example the string is used in something that expands it further down the line (think SQL injection potential).
  - bagels 5y ago
    Backwards compatibility for one. Code existed before fstrings that may use curly braces, and you can currently use curly braces in non fstrings without escaping them. Might also be a performance penalty for always having to run the fstring parser.
  - dragonwriter 5y ago
    If all strings with what looks like format specs are implicitly f-strings, how do you use reusable template strings, which use the same basic internal syntax, for formatting? f-strings, like r-strings, have uses, but, like r-strings, I wouldn't want to replace plain strings with them.
HL33tibCe7 5y ago
As a beginner, maybe. But this is code in some of the biggest open-source Python repos in existence. Probably written by someone with a reasonable level of Python expertise.
- genewitch 4y ago
  ... and yet?

groestl 5y ago

I think what's happening is that people assume there's type coercion going on here.

johnny_castaway 5y ago

This may be also caused by confusing syntax highlighting in some editors, for example in VSCode [1] The variable in the second string gets highlighted (with slightly different color, but still) because it would still work with `str.format()`. GitHub doesn't seem to do this. [1] https://imgur.com/a/9KGWVG0 https://imgur.com/a/9KGWVG0

totony 5y ago
Yeah I got bitten by the same-color syntax highlighting a few times.

jldugger 5y ago

I wonder if an autoformatter like black is at play here.

saila 5y ago
Black doesn't split strings, and I doubt they'd choose to use concatenation if they did.
- hathawsh 5y ago
  I kind of wish Black would split and join literal strings. I've seen several times when Black converted code like this: raise SomeError( "Explanation... " "yet more explanation" ) To this: raise SomeError( "Explanation... " "yet more explanation" ) That just looks odd. Black is fantastic, but not perfect.
- d0mine 4y ago
  Black does split strings if configured and it does use implicit concatenation of Python string literals.
  - saila 4y ago
    There's an experimental option for splitting long strings using the --preview flag, but it still seems to have some potential issues. That seems like it would be extremely hard to solve correctly.
xigoi 4y ago
Black doesn't change the semantics of code.