3 ms·

This is a straw man. If you want to evaluate expressions inside a long string, you can as easily write: "The sum of a and b is " + (a+b) + "!" This is complet

This is a straw man. If you want to evaluate expressions inside a long string, you can as easily write: "The sum of a and b is " + (a+b) + "!" This is completely analogous to your examples. The only disadvantage of this method is the extra quotes, but that's just syntax. You could think that having the literal string split is a disadvantage, but it really isn't - since in the proposal the string has to be literal anyway, so in either case it cannot be a variable. In general, in what I would consider good language design (syntactic-wise), you either interpret expressions by default and then quote string literals (like most languages do), or you interpret literals by default and then quote expressions (this is the method regular expressions language, or templating languages, use). But you shouldn't do both, it's just a can of worms, especially for code highlighting tools (although in a language with Lisp-like design philosophy - which Python is not - why not, you can do it today with reader macros and whatnot).

sanderjd 11y ago
I'm curious if you've ever spent a lot of time using a language that has a solution similar to the proposal, for instance Ruby, or the newer JavaScript versions. All of the theoretical stuff about good syntax design and code highlighting cans of worms rings incredibly hollow to me in the face of how fundamentally nicer this sort of syntax is. It's the first thing I forget Python doesn't have after not using it for awhile, which I then go looking for, and once again find myself surprised at its absence. I also find the "un-Pythonic to have more than one way to do it" argument interesting, as there seem to be three approaches to string formatting in idiomatic use in Python (`.format`, `%`, and string concatenation), whereas in Ruby, the direct interpolation approach is used nearly exclusively. You do lose type-checking capabilities by giving up format specifiers (which, for instance, Rust checks at compile-time), but Python can't take much advantage of that to begin with.
- brazzledazzle 11y ago
  I agree. Regardless of the technical merits it's a much nicer experience with languages like Ruby. I like the idea of keeping cognitive overhead at a minimum by reducing the number of methods to accomplish something but at the end of the day practicality should win.
- asgard1024 11y ago
  For all the (little) work I have done with JS I used the same technique of string concatenation, and I don't really see an issue with writing "+ instead of { (respectively +" instead of }). Ruby has a different philosophy than Python, was originally intended to be Perl replacement, and is more open to cryptic shortcuts like this. While in Python, the presumably better format() syntax was a step to actually longer code, character-wise, than old C-style % interpolation. Python simply tries to be more explicit, because it is used in more domains than just text processing; similar arguments can be raised against Python's treatment of regular expressions.
  - sanderjd 11y ago
    Ah, well, I guess all I can really say then is that it seems like you're knocking it before you've tried it. It's not any more or less cryptic or explicit than the alternatives, it's just a different, and quite convenient, way of expressing the same thing.

sanderjd 11y ago

I'm curious if you've ever spent a lot of time using a language that has a solution similar to the proposal, for instance Ruby, or the newer JavaScript versions. All of the theoretical stuff about good syntax design and code highlighting cans of worms rings incredibly hollow to me in the face of how fundamentally nicer this sort of syntax is. It's the first thing I forget Python doesn't have after not using it for awhile, which I then go looking for, and once again find myself surprised at its absence. I also find the "un-Pythonic to have more than one way to do it" argument interesting, as there seem to be three approaches to string formatting in idiomatic use in Python (`.format`, `%`, and string concatenation), whereas in Ruby, the direct interpolation approach is used nearly exclusively. You do lose type-checking capabilities by giving up format specifiers (which, for instance, Rust checks at compile-time), but Python can't take much advantage of that to begin with.

brazzledazzle 11y ago
I agree. Regardless of the technical merits it's a much nicer experience with languages like Ruby. I like the idea of keeping cognitive overhead at a minimum by reducing the number of methods to accomplish something but at the end of the day practicality should win.
asgard1024 11y ago
For all the (little) work I have done with JS I used the same technique of string concatenation, and I don't really see an issue with writing "+ instead of { (respectively +" instead of }). Ruby has a different philosophy than Python, was originally intended to be Perl replacement, and is more open to cryptic shortcuts like this. While in Python, the presumably better format() syntax was a step to actually longer code, character-wise, than old C-style % interpolation. Python simply tries to be more explicit, because it is used in more domains than just text processing; similar arguments can be raised against Python's treatment of regular expressions.
- sanderjd 11y ago
  Ah, well, I guess all I can really say then is that it seems like you're knocking it before you've tried it. It's not any more or less cryptic or explicit than the alternatives, it's just a different, and quite convenient, way of expressing the same thing.