6 ms·

I've been using python for the past 10+ years, and I've got to say that the new Syntactic formalization of f-strings (PEP 701) has got to be one of the most "hu

I've been using python for the past 10+ years, and I've got to say that the new Syntactic formalization of f-strings (PEP 701) has got to be one of the most "huh?" changes I've seen in a while. Was this such a big problem? In my experience, the GIL, faster start-up times are so much higher on the totem pole, why this now?

__s 3y ago
It's a small problem with a small solution
masklinn 3y ago
Because someone got annoyed enough to write a pep then implement it? Python is not a company and GvR is not a CEO handing out marching orders from on high. Hell, personal testimony, I don't give a rat's ass about the GIL or start-up times, but f-string limitations are a daily pain in the ass. So I'm absolutely grateful for whoever worked on this and looking forward to it.
atxbcp 3y ago
And in my experience, nesting f-strings and using quotes in f-strings is more useful than the GIL and faster start-up times, so YMMV.
jwkane 3y ago
Two reasons seem obvious. F-strings are relatively new -- the code is maturing and the edge cases are being filled in. Second, everyone can't be working on the GIL and start-up times. There is a tipping point at a relatively low head count where adding developers decreases productivity.
martinky24 3y ago
It's an open source project. If a developer wants to go out of their way to make a really cool improvement, goes through the approval process, has a clean implementation that doesn't add any backwards incompatibilities, why do you care? This isn't some private company where management tells people what to do and they have to do it. People are so out of touch with how OSS, and the volunteer maintainers that operate it, work. It's a shame. The sense of entitlement in a subset of the userbase ("Why aren't they fixing MY issues RIGHT NOW!") is mindblowing.
- 9967d2cad_askhn 3y ago
  No. You’re missing one constituent part of a for-profit corporate-backed language platform. You cannot just step in the ring with Ali because you think you can box. Politics, other forces, compellation will emerge as a stronghold barrier to your meritocratical hopes and dreams.
makr17 3y ago
"Due to the changes in PEP 701, producing tokens via the tokenize module is up to 64% faster."
- thrdbndndn 3y ago
  Performance improvement is obviously nice but I personally don't even care about it. Being able to just use any quotes in f-strings is just godsend QOL change and probably would be the biggest reason I upgrade to 3.12 (for my pet project).
gnulinux 3y ago
Makes the grammar simpler which makes new implementations to implement tokenizer much faster/cheaper. It's a simple problem with simple solution that has been causing a medium sized issue, so why not fix it?
klyrs 3y ago
Not everybody needs to work on the biggest problem, that's the "waterfall" approach to project management. If CPython was a single-developer project, that might be a valid criticism, but it's not. For me that formalization is nice because they've brought f-strings into the PEG parser which can point at the precise location of a syntax error. I'm wary of the implications of arbitrarily nested f-strings for legibility... but oh well.
mmebane 3y ago
It's a nice quality of life improvement. Most other languages I've used with some form of string interpolation allow quotes in nested expressions to be the same as the quotes on the top-level string, and this has IMO been a weird wart in Python. I'm happy to see it fixed.
h4l 3y ago
A few releases back they replaced the python parser with a more capable PEG parser. At the time nothing really changed, but it was done to enable this kind of improvement and make it practical to evolve the syntax over time. This change isn't so much done for the sake of being able to next quotes in f-strings, it's done because there was a dedicated extra parser for the python syntax inside f-strings, but with the new parser this can be parsed without this special case extra parser. It's all to manage technical debt.
serjester 3y ago
As a data scientist using dataframes, I'll often do print(f"Total for X is {df["col"].sum()}"). It's annoying to have to remember to switch the type of quotation mark to avoid a crash. I suspect, a lot of people that spend time in jupyter notebooks are in the same boat. You could argue I should be setting a variable but these are experimental scripts and it's annoying. I welcome it!
Tommstein 3y ago
> In my experience, the GIL, faster start-up times are so much higher on the totem pole, why this now? Are you aware that more than one change can be worked on at a time?
bjornasm 3y ago
Yeah, I find it a bit telling that they had to show completely ridiculous toy examples: >f"""{f'''{f'{f"{1+1}"}'}'''}"""

__s 3y ago

It's a small problem with a small solution

masklinn 3y ago

Because someone got annoyed enough to write a pep then implement it? Python is not a company and GvR is not a CEO handing out marching orders from on high. Hell, personal testimony, I don't give a rat's ass about the GIL or start-up times, but f-string limitations are a daily pain in the ass. So I'm absolutely grateful for whoever worked on this and looking forward to it.

atxbcp 3y ago

And in my experience, nesting f-strings and using quotes in f-strings is more useful than the GIL and faster start-up times, so YMMV.

jwkane 3y ago

Two reasons seem obvious. F-strings are relatively new -- the code is maturing and the edge cases are being filled in. Second, everyone can't be working on the GIL and start-up times. There is a tipping point at a relatively low head count where adding developers decreases productivity.

martinky24 3y ago

It's an open source project. If a developer wants to go out of their way to make a really cool improvement, goes through the approval process, has a clean implementation that doesn't add any backwards incompatibilities, why do you care? This isn't some private company where management tells people what to do and they have to do it. People are so out of touch with how OSS, and the volunteer maintainers that operate it, work. It's a shame. The sense of entitlement in a subset of the userbase ("Why aren't they fixing MY issues RIGHT NOW!") is mindblowing.

9967d2cad_askhn 3y ago
No. You’re missing one constituent part of a for-profit corporate-backed language platform. You cannot just step in the ring with Ali because you think you can box. Politics, other forces, compellation will emerge as a stronghold barrier to your meritocratical hopes and dreams.

makr17 3y ago

"Due to the changes in PEP 701, producing tokens via the tokenize module is up to 64% faster."

thrdbndndn 3y ago
Performance improvement is obviously nice but I personally don't even care about it. Being able to just use any quotes in f-strings is just godsend QOL change and probably would be the biggest reason I upgrade to 3.12 (for my pet project).

gnulinux 3y ago

Makes the grammar simpler which makes new implementations to implement tokenizer much faster/cheaper. It's a simple problem with simple solution that has been causing a medium sized issue, so why not fix it?

klyrs 3y ago

Not everybody needs to work on the biggest problem, that's the "waterfall" approach to project management. If CPython was a single-developer project, that might be a valid criticism, but it's not. For me that formalization is nice because they've brought f-strings into the PEG parser which can point at the precise location of a syntax error. I'm wary of the implications of arbitrarily nested f-strings for legibility... but oh well.

mmebane 3y ago

It's a nice quality of life improvement. Most other languages I've used with some form of string interpolation allow quotes in nested expressions to be the same as the quotes on the top-level string, and this has IMO been a weird wart in Python. I'm happy to see it fixed.

h4l 3y ago

A few releases back they replaced the python parser with a more capable PEG parser. At the time nothing really changed, but it was done to enable this kind of improvement and make it practical to evolve the syntax over time. This change isn't so much done for the sake of being able to next quotes in f-strings, it's done because there was a dedicated extra parser for the python syntax inside f-strings, but with the new parser this can be parsed without this special case extra parser. It's all to manage technical debt.

serjester 3y ago

As a data scientist using dataframes, I'll often do print(f"Total for X is {df["col"].sum()}"). It's annoying to have to remember to switch the type of quotation mark to avoid a crash. I suspect, a lot of people that spend time in jupyter notebooks are in the same boat. You could argue I should be setting a variable but these are experimental scripts and it's annoying. I welcome it!

Tommstein 3y ago

> In my experience, the GIL, faster start-up times are so much higher on the totem pole, why this now? Are you aware that more than one change can be worked on at a time?

bjornasm 3y ago

Yeah, I find it a bit telling that they had to show completely ridiculous toy examples: >f"""{f'''{f'{f"{1+1}"}'}'''}"""