Why do f-strings exist? Why do we have the match statement? Why assignment expressions? Why ANY new feature? It isn’t because something else is being replaced. It is because this newer feature is worth adding. Multiple features can coexist happily. I don’t understand where the confusion is.
1 Like
I get what you’re saying, but personally I think that’s more a problem with a certain kind of culture that’s developed among a certain sort of programmers. If the maintainers of a project want to state that they’d like to update the code for this kind of style change but haven’t gotten around to it, or create a bug ticket tagged “good for new contributors” or whatever, great. If not, people shouldn’t be submitting drive-by PRs for no-op stylistic changes, period. That’s the case regardless of what the Python docs do or don’t recommend.
Similarly, I think sometimes people are letting the linter tail wag the code dog. Linters are for finding things you don’t want in your code but might have accidentally let slip in. If you’re fine with having % formatting in your code, then your linter shouldn’t be complaining about it, and if you can’t make it stop complaining, that’s a problem with the linter.
Basically I think it’s more helpful overall to have the docs provide the guidance that’s most useful to the most people. Making the current docs note a bit more opinionated seems like a good change on balance, and it’s more of an issue of finding the right wording than “avoiding judgment”. It’s fine to make judgments, and it’s also fine to ignore other people’s judgments. 
6 Likes
I know you aren’t necessarily advocating for this but I would just like to say that in my experience this sort of thing is not a good candidate for new contributors. It is very easy with a tool like ruff to autogenerate large PRs with say a 1000 line diff touching every part of the codebase but then the reviewer needs to go through it all manually.
New contributors should be encouraged to submit PRs that are very easy to review in full which necessarily means a small diff. If something is trivial but generates a 1000 line diff then I want it to be done by someone that I have some level of existing trust in so that I assume they already reviewed it themselves and I don’t have to comb through every line in detail (potentially multiple times).
Of course if the change being made has nontrivial value like it fixes a real problem then the situation is different and I am happy to review a large diff from a new contributor.
The problem in Python is that we have an open market for linters so everyone has a different one (e.g. in their editor). I would really like to see a consolidation around a good core set of lint rules that only covers actual problems but the open market encourages the proliferation of pointless opinionated rules.
2 Likes
In theory yes. In practice, CPython will not deprecate anything that has significant use, because it forces many people to take action. The only chance you have with such topics is that the community largely stops using the functionality by itself - e.g. they freely decide to migrate to better alternatives. And only when that has naturally grown out of the active codebase, you could decide to push the few remaining users over with a deprecation. This is something on a 10year+ timescale. IMHO it’s still worth thinking about the long-term evolution of the language and you need to set the right alternatives to stimulate natural migration.
And I don’t see that this weighting is done. Let’s be concrete. Please weight this code addition %-style formatting method - #30 by timhoffm vs. people who want %-placeholders (and there are valid use cases as discussed in the thread) have to use the quirky %-operator.
Also small improvements round off sharp edges in the language and in sum can improve the user experience substantially.
As you said, the
%operator isn’t going away, so that’s not a point in the proposal’s favor.
I said “in the foreseeable future”. As explained in %-style formatting method - #64 by timhoffm it could happen long-term via a natural migration. This proposal would open up such a natural migration route. While there’s no guarantee such a migration will happen, I count opening up the potential as a bonus to the proposal.
On a long timescale, I think it’d be great to have fewer ways to do string formatting. But introducing something like pformat would go in the wrong direction, by entrenching % formatting even more heavily.
There are reasons people prefer the style now (i.e. because they’re already dealing with lots of curly braces), but ten years is a long time and a lot of code will migrate over time[1].
It’s not obvious to me that introducing an alternative would let us deprecate % any faster, and it certainly won’t let us deprecate % formatting in general.
and perhaps new tools/libraries will enable this ↩︎
1 Like
I didn’t mean to suggest that there’s an objective answer to this question! It’s going to require a bunch of different people coming to a consensus based on varying opinions (or not, in which case the default is typically not to do it).
I’m not a core dev and I don’t have any experience maintaining CPython, so I’m not in a position to make such a fine-grained judgement call.
1 Like
I am a core dev, and I can say with confidence that the cost is not just that of adding a few lines of code. There’s the cost of documenting that new function, the cost of updating tutorials and training materials (although I concede that will be small as a lot of training materials will focus on the newer form). There’s the cost to project maintainers of handling well-meaning PRs/issues saying “you should use the new pformat method”. There’s the cost of debates about whether linters should flag the % operator and suggest pformat instead. Etc.
Heck, there’s the cost of this whole discussion - which is a sunk cost at this point, but nevertheless is not something you can dismiss.
All of that may still be justified by the benefits of the feature, but it’s really hard to get a feel for whether that’s true, when people consistently understate the costs in terms like “it’s only a few lines of code” 
7 Likes
This seems like an unnecessarily negative way of looking at things. Yes, it’s true I could be using this time to invent nuclear fusion instead of arguing on the Internet. But if you take the “sunk cost” perspective to its logical extreme, we ought to close down this website.
This is an unfair characterization. I agree: that oversimple description is not technically accurate. Implementing this feature requires more work than doing nothing, but can we agree that it is significantly less work than, say, adding a JIT or removing the GIL? While engaging in this sunk cost discussion, shouldn’t we be more focused on whether the proposed feature is a net benefit to the developer community than calculating the exact BoM?
My take on the simplest version of the argument in favor of this idea is:
printf-style formatting is (still) valuable to Python.- The
str.__mod__operator has foot-guns that frustrate users. - A new, relatively low-cost,
str.pformatmethod ameliorates those foot-guns.
IMO, this is a net benefit regardless of whether future deprecation of the str.__mod__ operator ever becomes a goal. printf-style string formatting isn’t going anywhere. The battle tested logging module uses it by default. Discussion about encouraging or discouraging its use seems misguided.
I’m not overly familiar with Python’s development process, but I suspect you can find someone willing to do most of the work for something this straightforward.
3 Likes
Maybe. But endless discussions like this one are very draining for the few core devs who still try to help people develop their ideas. There’s a reason it’s hard to get core dev attention on the ideas category - it’s got a reputation of having a pretty bad signal to noise ratio
Whether that’s a negative view, I can’t say. But it’s a reality that keeping discussions focused and short, and not endlessly relitigating the same points, would improve things for everyone.
I’m sorry if you think it’s unfair, but it’s genuinely difficult to get across to people that if they don’t represent the costs and benefits accurately, they won’t get support and their proposal will go nowhere. I can’t even tell you how often I’ve had to list all of the “hidden” costs of something that’s being claimed as “just a few lines of code”. It’s frustrating to have to keep doing so, and even more frustrating to be challenged whenever I do.
You seem to have a mistaken view of how Python development works. Generally, I’d expect the person proposing the idea to provide the implementation, including documentation and tests, in the form of a PR. It’s very rare for someone on the core team to see an idea here and go off and implement it (not unheard of, but certainly rare). So the proposer typically needs to do the work, and that means they should get familiar with what will actually be involved. For example, in this case, the str type is written in C, so a new method will need to be written in C. That’s a barrier right there - many people around here don’t know C, so the likely assumption when someone says “this is easy to implement” and shows a Python implementation is that they won’t be able to do the actual coding themselves, and they probably don’t have a good feel for the implementation difficulty of a C version.
I agree with all of this, although I’d say pformat might ameliorate the foot-guns (and I’d skip the “low cost” comment because it’s potentially controversial and will be established later in the process).
But where do we go now? Who will write the PR to implement this? As a change to a core type, it’s likely to need a PEP as well. Who will write the PEP, and do they have a core developer willing to sponsor it? Getting a sponsor isn’t always easy - it requires a core developer who’s willing to mentor the contributor through the PEP process, which is potentially a chunk of work (especially if the contributor hasn’t already shown a good awareness of the sort of issues they’ll need to cover in the PEP).
Maybe this all does sound negative. I’m sorry if that’s the case. The process is quite laborious, but that’s because we have a responsibility to the literally millions of Python programmers out there, to not break their code, and to act as careful custodians of the language. The days when a change to Python could be low-impact are long gone, I’m afraid.
Language changes can and do happen. Not just big ones like free threading or the JIT, but smaller ones as well - yes, even just adding small convenience methods. But much more often than not, they happen as a result of people stepping up and doing the work, and following the process with a good awareness of the impact of the changes they are making. Quiet changes that are offered without getting sucked into controversial debates. Discussions that quickly build consensus and then move onto implementing the agreed changes. Long, controversial threads like this one (and the one that spawned it) are much less likely to produce viable changes, in my experience.
7 Likes
This is a good place to start. If @timhoffm and I volunteer to write the PEP, and create the PR, will you sponsor it?
No.
I didn’t say I support the proposal. All I said was that I agreed with your points, not that they are sufficient justification.
Also, I’m not comfortable with guiding you through the process of writing a PEP. A PEP needs to fairly assess the advantages and disadvantages, and I don’t feel that you really accept my comments on the trade-offs - so I don’t really feel up to reiterating those same debates in the process of writing the PEP.
Sorry.
I accept your comments on the trade-offs. I’m not sure who the “you” is you’re referring to. This is only my third comment in this thread. I don’t recall disagreeing w/ you on the parent thread either. I’m seeking guidance, not conflict.
Okay.
@ericvsmith, in the previous thread, you suggested we model the PEP after PEP 616 – String methods to remove prefixes and suffixes | peps.python.org. You were the sponsor of that PEP. Would you consider sponsoring this one?
It might have been Tim, as the OP here.
Apologies, with all the threads I’m involved in, and the high rate of posting, it’s hard to keep track of which comments are associated with which individuals. My intent is always to offer guidance, and I’m certainly not looking for, or trying to start, conflict. If my advice in a particular thread/proposal is not accepted, that’s perfectly fine, if a little frustrating from a personal point of view.
@cjdrake Thanks for bringing the discussion back on track and summarizing the main argument so clearly:
This is exactly what I’ve been trying to convey!
@pf_moore Thanks for the more differentiated recent answers. I value that a lot! I’m sorry if I’ve come across uninsightful or not valueing your answers. I deeply believe this is a topic worth considering and I try to fairly collect all aspects. That‘s sometimes difficult in a written thread where multiple aspects are discussed in parallel, new people come in and people interpret the same answer differently depending on where they are coming from (no judgements). I had the impression that I wasn’t able to get across some of the major points. In hindsight I should have been better in separating the statement of tradeoffs from their judgement.
I’m aware (and have written somewhere above in the thread) that the actual work includes writing C code and documentation. It’s admittedly more than 7 lines of Python, but still a comparably small feature. I would be willing and - with all respect - claim to be capable of writing reasonable and fair PEP and the PR. @cjdrake I’d be happy to work with you together on this if you are interested and it comes to it.
3 Likes