Hacker News Reader

Comment by nojs | Hacker News Reader

> This is the first special feature of f-strings: adding a trailing equals sign lets you print out the expression and what it evaluates to.

    >>> foo='bar'; print(f"{foo=}")
    foo='bar'

Wow, never knew you could do that.

View on HN

Python release notes are really worth reading, for me there's usually some "positive surprise"

The = support was added in Python 3.8: https://docs.python.org/3/whatsnew/3.8.html#f-strings-suppor...

If you come from verbosity land C# release notes are magically good as well, always some way to reduce boilerplate while maintaining "implicit verbosity" which your proprietary LSP resolves 100% correctly.

I'd prefer writing C# if I had the Linux interaction libs Python has. I'm too dumb to write syscall wrappers

It makes me sad that the PEP for the equivalent behaviour for function keyword arguments wasn’t accepted. It’s really common to see foo(bar=bar) and I think it’s not only cleaner but would help see subtle differences if that was foo(bar=) because it would make the cases where some arguments aren’t simply being passed through more obvious: foo(bar=, …, baaz=baaz.get_id()) avoids the most interesting detail being easily missed.

Do you know why? I didn't know of the fstring one either but I've thought to myself across many languages that a way to print the expression (or just varname in my head) with the result should exist.

The PEP: https://peps.python.org/pep-0736/

The discussion: https://discuss.python.org/t/pep-736-keyword-argument-shorth...

The rejection: https://discuss.python.org/t/pep-736-shorthand-syntax-for-ke...

Grammar changes, in particular things used everywhere like function invocations, have to be worth paying the price for changing/adding new rules. The benefits of fewer characters and more explicit intention weren't enough to outweigh the costs.

There were other considerations: Do linters prefer one syntax to another? Does the name refer to the parameter or the argument in tooling? Should users feel pressure to name local variables the same as the function's parameters? What about more shorthand for common cases like func(x=self.x, y=self.y)?

I personally did not like the func(x=, y=) syntax. I think their example of Ruby's func(x:, y:) would actually make more sense, since it's syntax that would read less like "x equals nothing", and more "this is special syntax for passing arguments".

Guess I will chime in for the dissent: there is already so much Python language. The more special gotchas that are added just for these minor wins is not worth it. In fact, if I ever saw a function that was foo(bar=) I would correct that to be explicit immediately. ‘import this’ and all that.

Said as a curmudgeon that has never used a walrus.

And it seems like a bad idea because of that wow factor - it isn't really adding enough to justify having surprising behaviour. It is more likely to be a bug than a feature.

It'd be better to just let people implement their own function that prints a subset of locals(), or provide a standard function that does the same.

Incredibly common for debug output. In C++, I have made it a habit to just copy the expression, once with quotes and once without. It's informative and doesn't require thinking, or, well, I'm still working on that.

It's the kind of thing you do with macros in C++.

Yeah probably, I mean I thought of it but never went as far as actually adding something.

such a boon for print(f) debugging. :)

No more will I have to

print("foo", foo)

Reply on news.ycombinator.com