5 ms·
> I am against it, because it allows arbitrary Python expressions inside format strings. As well it should. Programming language features should be orthogonal
by Camillo 11y ago
> I am against it, because it allows arbitrary Python expressions inside format strings.
As well it should. Programming language features should be orthogonal as much as possible.
> It's too complicated and lets user have two different ways of doing things (not Pythonic) - one to calculate expression inside string and the other to calculate it outside (which should IMHO be preferred).
You must hate expression nesting, then. Look at all these ways of doing the same thing:
x = a + b * (c - d)
e = c - d
x = a + b * e
f = b * (c - d)
x = a + f
e = c - d
f = b * e
x = a + f
Clearly, expressions should be restricted to no more than one binary operator. That reduces the number of different ways of computing the expression, and forces the programmer to give a name to each sub-step, which enhances readability, clarity, and debugging-friendliness.
I feel dirty just for having written that.
- asgard1024 11y agoThis 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 agoI'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 agoI 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 agoFor 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 agoAh, 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.
- gbog 11y agoYou're pushing it too far. Having one logical step per line is better for readability, clarity, and debugging-friendliness. > Programming language features should be orthogonal as much as possible. True, and that's why string building and string formatting should be two things. By the way, I am not sure about how would this PEP should handle something like a = 'A1' b = f'{a}' a = 'A2' s = f'{a}' + b Said otherwise, is it possible to create at run-time an f-string?
- baq 11y agoA2A1 would be my expectation, according to code equivalnce rules from the PEP. as to your question, it shouldn't be. it's just syntax sugar.