Hacker News Reader

Comment by airstrike | Hacker News Reader

The expansion of f-strings is a welcome addition. The more I use them, the happier I am that they exist

https://docs.python.org/3/whatsnew/3.8.html#f-strings-suppor...

I saw that and was like "Oh, that'd be a handy feature for a lot of other programming languages too." But the more I think about it, the more I'd rather have a feature that takes a list of expressions and converts it into a dict where the keys are the expression text and the values are the values of those expressions. Basically, syntactic sugar for this:

  { k: eval(k) for k in ('theta', 'delta.days', 'cos(radians(theta))') }

This would trivially subsume the f'{user=}' syntax for the example given: just print out the dictionary. But it'd also be useful for: filling template dictionaries; printing out status pages for HTTP webservers; returning multiple variables from a function; flattening out complex data structures; creating dispatch tables out of local functions.

You could even have a syntax like locals('theta', 'delta.days') and keep it familiar.

Pretty trivial to do with proper macros in a language. Julia has macros for printing variables and values, like `@debug(var)`.

There's an Elixir library with macros to make a map (dictionary) using the variable names passed in [1]:

    iex> import ShorterMaps
    ...> name = "Chris"
    ...> id = 6
    ...> ~M{name, id}
       %{name: "Chris", id: 6}

Though wether its a good idea or not is another question. ;) If you want to do the type of programming you're talking about you should try Elixir/Julia/Clojure(/Rust?)... or any number of other languages with macros.

1: https://github.com/meyercm/shorter_maps

Can't you build your own function using format()? f-strings are just syntactic sugar for format() so presumably you can

This makes clean string interpolation so much easier to do, especially for print statements. It's almost hard to use python < 3.6 now because of them.

One thing I vastly dislike with them is that they are still expanded in logging, while they are not expanded when logging is using "the old way".

What do you mean the old way?

Will it print what foo is if I type logger.info("{foo=}")?

Logging.info(“%s %s”, name, country”) the string isn’t expanded if the logging is set to warn. While with your example the string is expanded then discarded

How would you fix the issue without breaking existing semantics?

The way I see it, it's a necessary price to pay, and I just continue to use c-style forming strings in logging.

The clean way would be to introduce laziness. But yeah, can't do that in Python.

Why didn’t Python ship with the opposite functionality as well? Parsing instead of formatting. Given a string and a format string, return a list of variables (or a dictionary).

It did! https://docs.python.org/3/library/string.html#string.Formatt...

I think this is what you want:

https://github.com/r1chardj0n3s/parse

Are you talking about parsing f-strings? How would that look like?

As far I understand the following:

    print(f"your name is {name}")

is roughly equivalent to:

    print(f"your name is " + format(name))

What is there to parse?

For example, to checkpoint a model, I would save it as “ckpt-{epoch_number}-{val_loss}”. Given this file name and the original format string, I would like to recover the epoch number and validation loss variables back.

From: ckpt-8-0.300 To: epoch=8, val_loss=0.300

Reply on news.ycombinator.com