When Zed was trying to embed a print function and another format string inside a format string they didn’t seem to work but the problem was not using the opposite type of quotes (i.e. if the outer format string uses double quotes, the inner format string or bracketed expression needs to use single quotes and vice versa).
For instance, this works:
surprise = “Yay!”
print(f"This is a {surprise}")
print(f"This is a {f’{surprise}’}")
print(f"This is a {print(f’{surprise}’)}")
The second print will provide the same output as the first print.
The third print will not throw an error but it will give you a unexpected result. It will output the result of the inner print on a separate line and then it will do the outer print but will put the string “None” in place of the outer {} since it is printing the return code of the print function.
Yeah it works but it only seems to work two levels deep. I tried to make it work with an f-string in an f-string in an f-string and I got SyntaxErrors. But then again it get’s pretty confusing to do it that way and would be very hard to read and maintain. So not everything possible is a good idea
My takeaway from things like these is not so much whether it is practical or good to do but why it does what it does. Using f-format in these various ways might help me understand the logic within. I missed this video on the way through so haven’t spent time on this particular example to comment more.
Well, honestly trying to cram several levels of code inside and f-string is probably not great form. What it does though is teaches you that python is orthogonal. If you can print, then you can print inside print. Now if python were totally orthogonal then you could do this infinitely down, but at some point they probably have to give up or else totally redesign f-strings. It also sort of teaches you that you can learn two topics in a programming language, and then just try to combine them in weird ways to see if you get something useful or new.
Zed,
The reason I went ahead and tried to solve the issue was to test orthogonality of the language so I’m glad you mentioned it. I don’t know if you mention this concept further in this book or in your other books but its a very important concept. And as you suggest, in language design there are always trade-offs. Even in Turing’s Machine there can only be an infinite tape in theory. I’ve learned something like 300 languages in my 43 years of programming and I always find the design decisions to be more interesting then the language as a tool. But then I’m kind of strange that way.
Yep, I talk about it a lot in the https://learncodethehardway.org/more-python-book/ book, and demonstrate it quite often. It does come up later in the Python 3 book, but it’s not as heavily demonstrated.
Cool I bought that book last night and am looking forward to going through it as well. So before I look at your definition of orthogonal the shortest working definition I use is that the orthogonality of a language is a measure of its capability without the need for special cases. This implies that a language needs fewer keywords which can be combined in a smaller number of ways to get most of the funtionality a language has to offer. Does that sound reasonable?
Hmm, yeah I guess a good working definition for programming could be “concepts can be combined without special cases”. Or, “concepts can be used together or separate without exceptions or special cases”. I think my favorite example is the dot (period, .) for accessing stuff. There really isn’t a reason why I have to treat a dict, class, or object differently in Python. Classes and objects are implemented with a dict under the hood. But, I have to use a . with an object and [] with a dict even though they’re the same thing. JavaScript and Lua have the right idea to treat these the same, which makes them more orthogonal than Python.
I bought that book last night and am looking forward to going through it as well. So before I look at your definition of orthogonal the shortest working definition I use is that the orthogonality of a language is a measure of its capability without the need for special cases. This implies that a language needs fewer keywords which can be combined in a smaller number of ways to get most of the funtionality a language has to offer. Does that sound reasonable? 