Counterargument: "=" is YAMLization. It prioritizes concision and an abstracted ideal of "readability"[1] at the expense of mental model and ease of use. Every non-obvious feature like this has cost. Every user who sees this for the first time is going to be confused. Every time a language or syntax adds a "shorthand" feature like this it makes itself less accessible.
And in this case I think the value is really pretty low. That particular "=" syntax is really mostly just useful for dumping runtime state at debug time. And the world is filled with tools that can do that for you with even more concision.
[1] Which doesn't really correspond to general comprehension. It means something more like "readability for experts".
> It prioritizes concision and an abstracted ideal of "readability"[1] at the expense of mental model and ease of use.
That statement applies to all format strings, which are by necessity a small internal DSL. For the = syntax, the input is copied directly to the output with the value of the variable appended. Within the realm of language features, sure it's one more chocolate wafer of syntax. Within the realm of format strings, it's certainly more straightforward than the type conversion and padding syntax.
> That particular "=" syntax is really mostly just useful for dumping runtime state at debug time.
In scientific / ML development that's like 80% of the work.
This is honestly my favorite formatting feature. I use it a lot in debug/info logs and its honestly my first go to when debugging something trivial enough that I don't want to spin up the full debugger.
I use this regularly, combined with Wil McGugan's `rich.print` for easy fancy colorized output. f-strings are one of my favorite things by far to happen to Python in recent memory, along with the robust Unicode support and fancy new `async` stuff. :)
I'm rather curious about the "non pythonic" part of your comment. The % formatting to me has always felt like a compatibility thing with C and I've always found the {} format style much more pythonic. f strings seem like a logical extension/continuation of that formatting style into something that works really quite well with python in my personal experience.
As an example I think each iteration of formatting is more readable and arguably more pythonic:
log.info("%s is logged into service #%d" % (user_name, service_number))
log.info("{} is logged into service #{}".format(user_name, service_number))
log.info(f"{user_name} is logged into service #{service_number}")
I'm amazed at how much use I've gotten out of learning C printf format strings. A lot of these format specifiers are the same, Java also uses them, and I'm sure more languages took inspiration from them.
22 comments
[ 2.7 ms ] story [ 55.2 ms ] threadAnd in this case I think the value is really pretty low. That particular "=" syntax is really mostly just useful for dumping runtime state at debug time. And the world is filled with tools that can do that for you with even more concision.
[1] Which doesn't really correspond to general comprehension. It means something more like "readability for experts".
That statement applies to all format strings, which are by necessity a small internal DSL. For the = syntax, the input is copied directly to the output with the value of the variable appended. Within the realm of language features, sure it's one more chocolate wafer of syntax. Within the realm of format strings, it's certainly more straightforward than the type conversion and padding syntax.
> That particular "=" syntax is really mostly just useful for dumping runtime state at debug time.
In scientific / ML development that's like 80% of the work.
Space on a website is free, whats with the confusing newspaper layout??
As an example I think each iteration of formatting is more readable and arguably more pythonic:
Rather than using strftime
https://towardsdatascience.com/python-f-strings-are-more-pow...