@evhub TL;DR the implementation is as follows: at the end of f_string_handle create a copy of the current compiler and use it to parse the expressions.

However, there is a problem: since the Forwards in the grammar are defined on the class level, there can only be one active Compiler because Compiler.bind in a new compiler sets the handlers to bound methods of the new compiler. I added a call to self.bind() as soon as the new compiler is no longer needed, but this feels like a terrible hack, so I've opened this as a draft pull request.

Do you have any ideas how to do this in a cleaner way?

Thanks in advance!

Does this support fstring formats, like f"{[] |> len :#x}"?

@pavelbraginskiy Yes, all formatting specifiers are supported.

Hi @evhub, could you please give your feedback on this?

@m-burst It looks like this implementation breaks f-strings on non-3.6 versions, which is a big problem. I'd rather keep universal compilation of f-strings and not support Coconut syntax in them than break universal compilation and add Coconut syntax support.

@evhub That's certainly not what I intended (if it's true, it is a bug and I'll see what I can do to fix that).

See the code here: if the target is 3.6+, we rebuild the f-string with the compiled expressions, otherwise we generate a format call.

Also there are f-string tests in target-agnostic tests and they pass under Python 2 (see the CI run).

@m-burst Oh, no, you're right; I'm wrong! In that case, it looks good. I'll try to merge this when I get a chance.