That would not be a traditional function, because you want {a} to be evaluated in the context of the caller, rather than the context of f.

As I understand it, print() was created not from a sense of consistency, but because a few awkward cases could be simply solved by turning print from a statement into an expression. Use in lambdas would be one example.

I don't like the extra parens, but I made an editor shortcut to alleviate that.

Other cases such as redirecting to a file, and changing the line ending are handled much more intuitively with the print function.

In order to implement `f` as a plain function with same behaviour as g-strings, you would probably have to do some stack trickery to properly capture locals.

In fact, I don't think it would be possible to write such a function in the general case, because it's ambiguous what environment you would need to use.

For example:

def call(func, arg):

    a = 2

    return func(arg)

a = 1

print(call(f, "{a}"))

Does this print 1 or 2?

> I’m curious actually why an f-string syntax is considered OK when a print-statement is not.

One reason might be that f-strings work in expressions, while statements do not. Even with the BDFLs apparent distaste for functional programming constructs, syntax that works within expressions has lots of practical advantages over statements.

The prefix isn't new, there were already u, b, and r strings.