News for hackers. Stuff that matters.
Re:Pattern matching accepted for Python by superbcarrot on Tuesday February 09, 2021 @04:09PM (#26082412)
It's difficult to balance it out correctly. F-strings were a significant improvement and I still think it was a great idea to include them and trade off some of the language simplicty for the added convenience. This new pattern matching... I'm not convinced yet.
Re:Pattern matching accepted for Python by roelschroeven on Tuesday February 09, 2021 @04:26PM (#26082575)
Personally I don't feel f-strings are an improvement at all, but I think I can see why people prefer them. But a significant improvement, that I don't see at all. Can someone explain why e.g.

    f'gcd({a}, {b}) = {math.gcd(a, b)}'
is so much better than

    'gcd({}, {}) = {}'.format(a, b, math.gcd(a, b))
In the .format() version, the formatting and the values are separate and that makes it more clear to see both the formatting and the values. I really like that separation. When the expressions get more complex, .format() doesn't really lose any clarity while f'' gets pretty unreadable quite fast IMO. Yes, you can simplify by assigning the expressions to variables, but .format() doesn't even need that.
Re:Pattern matching accepted for Python by superbcarrot on Tuesday February 09, 2021 @04:32PM (#26082629)
I find the f-string version better because I read from left to right and find it unnatural when my eyes need to jump around several times over the same expression in order to parse it. In your example that effect isn't too strong because there isn't a lot of additional text in the string and it's very clear what's going on either way.
Re:Pattern matching accepted for Python by contravariant on Tuesday February 09, 2021 @06:19PM (#26083861)
Sometimes you just want to quote something in a string real quick. In some cases you want to do something slightly more complicated.

And I really dislike format where the arguments are given by position. For short strings it's not going to matter but for long strings you're bound to mess something up sometime. Just imagine writing some kind of long email template and ending up with something like:

    '''Dear {}{}
    

    I write you on the {} to inform you...

    Kind Regards,
    {}'''.format('Mr. ', 'President', '1st of April', 'Ohio', '12', ..., 'Automated mail bot')
Okay it's a bit contrived but any long multiline formatted string is going to be hard to read without using keywords.

And once you insist things are named then f-strings look a lot neater since you get:

    f'gcd({a}, {b}) = {math.gcd(a, b)}'
v.s.

    f'gcd({a}, {b}) = {gcd_a_b}'.format(a=a,b=b,gcd_a_b=math.gcd(a, b))
Of course sometimes a template is the appropriate tool, but usually because it's going to be used more than once.
Re:Pattern matching accepted for Python by cjohnson318 on Tuesday February 09, 2021 @05:33PM (#26083344)
Once you get over five arguments in str.format(), it gets weird. I reverse engineered a product that required a lot of string formatting, and f strings made things more readable and debuggable.
Re:Pattern matching accepted for Python by marcinzm on Tuesday February 09, 2021 @08:38PM (#26084871)
As I see it the less cognitive overhead I have when reading code the better. The more I have to think about the code I am reading the more likely I am to make a mistake because my brain is not a machine. With f" I simply read the code left and right and understand the output as I go. When I see the output I'm interested in I stop and see the context instantly. With .format() I read left and right, stop once I get to what I'm interested in, go back to count the {}s, remember the count, and finally count the arguments. Multiple places to make a mistake. And doing this when refactoring code is how you get bugs.
Re:Pattern matching accepted for Python by IanCal on Tuesday February 09, 2021 @04:34PM (#26082646)
> In the .format() version, the formatting and the values are separate and that makes it more clear to see both the formatting and the values.

It makes it harder to see which values actually go where though. I really dislike the separation.

Re:Pattern matching accepted for Python by roelschroeven on Tuesday February 09, 2021 @04:49PM (#26082805)
> I really dislike the separation.

That's obviously a pretty fundamental difference in point-of-view. And it looks like your point-of-view is shared by a large majority.

"The reasonable man adapts himself to the world. The unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw

I try to be reasonable, so I guess I should try to come to terms with f-strings. In any case please don't depend on more progress.

Re:Pattern matching accepted for Python by thaumasiotes on Tuesday February 09, 2021 @05:02PM (#26082963)
> It makes it harder to see which values actually go where though.

You can name the variables in the format string and then pass the expressions as keyword parameters.

Re:Pattern matching accepted for Python by aidos on Tuesday February 09, 2021 @07:06PM (#26084259)
You can do that with f-strings too... but you don't need to because they're generally already clearer.
Re:Pattern matching accepted for Python by ju_sh on Tuesday February 09, 2021 @04:41PM (#26082709)
Thank goodness we still have both ;)
Re:Pattern matching accepted for Python by scarygliders on Tuesday February 09, 2021 @08:40PM (#26084893)
Thank you!

Like you - and I just learned about the existence of f-strings tonight - I find .format() to be much more readable and logical than f-strings.

My first impression reading about f-strings was "ew."

It's not a case of "I don't like it because it's new". To my jaundiced and admittedly subjective eyes, I'm still finding .format() better, precisely because it doesn't lose any clarity in exactly the way you stated.

In other words, I just don't get the point.

Furthermore! f? Really? What the f does f mean? The str() function is the str() function. As well as print(). As well as .format().

f? please

Re:Pattern matching accepted for Python by nuclear_eclipse on Tuesday February 09, 2021 @06:10PM (#26083760)
Just wait until you get Python 3.9 and can do:

    >>> a, b = 2, 4
    >>> f"{math.gcd(a, b) = }"
    'math.gcd(a, b) = 2'
Re:Pattern matching accepted for Python by mixmastamyk on Tuesday February 09, 2021 @07:02PM (#26084231)
The first is more readable and performant, the second is much more error prone. One of the things folks complain about in Python is runtime errors, this is one part of the solution.

Is that enough?

Re:Pattern matching accepted for Python by roelschroeven on Tuesday February 09, 2021 @08:47PM (#26084929)
I don't know about performant. If the difference is significant, that can be something to take into account, depending on the situation. Otherwise readability is more important.

So we come to readability, and I have to say that to me .format() is more readable. Honestly.

Regarding runtime errors, I presume you mean .format() doesn't prevent mismatches between the number of placeholders and the number of arguments, as in '{} {}'.format(42)? That's indeed a point in favor of f'', that I hadn't previously considered.

Re:Pattern matching accepted for Python by mixmastamyk on Tuesday February 09, 2021 @09:14PM (#26085061)
The eff string uses a special instruction that makes it not need to do expensive function lookups at runtime. These are costly in Python. Better in loops.

Readability is a win in my book. You mention too much is happening in your example string. Ok, perhaps it is. But remember, just because the interpolation supports expressions, doesn't mean you have to put them in there. I'd argue your function call would be better done on the line above, with only the result put in the string. This is the most readable version so far I think:

    c = math.gcd(a, b)
    f'gcd({a}, {b}) = {c}'
Syntax highlighting helps out as well.

Yes about placehoders. Also that in some cases of format() each variable is repeated a number of times:

    'hello {name}'.format(name=name)
When this is changed it is a bug magnet. DRY in a nutshell. Rarely is a feature a home run like this one. Not to mention I was using it in batch files, shells, and perl twenty-five years ago.